Continuing our discussion from last month, click here to read part one: http://www.ebizq.net/topics/scm/features/6192.html.

Creating an integration strategy for service providers (or software as a service or on-demand applications [ODA]), not to mention an SOA for this type of domain, is not as hard as it appears. Indeed, many if not all of the same SOA and application integration principles apply, including:

• Definition of interfaces
• Schemas and records
• Common transactions
• Transformation and mapping
• Security principles and governance
• Process construction and extension

This month, I’ll address the first two principles.

Definition of Interfaces

Not all service-provider application interfaces will provide all of the functionality required to create and operate service-oriented service provider interfaces (e.g., Web services) for the service provider integration, and service provider interfaces are always limited by the capabilities of the interfaces that the source or target systems provide. You need only look at how you interact with Salesforce.com or RightNow to determine that the interfaces are very different and special attention needs to be given to their functionality. To this end, when dealing with services providers it’s helpful to define interface types that applications and databases provide that fit with service- or information-oriented service provider interfaces.

They are:

• Static data.
• Dynamic data.
• Function return data.
• Function return service.
• Function return abstraction.

Static data-type application interfaces refer to those application interfaces that return simple information within a static record that is difficult if not impossible to change. These old types of application interfaces only provide fixed data with visibility into an application and do not provide opportunities for service-level access due to the data-only limitation of this interface.

Dynamic data-type application interfaces also provide only data, but they provide data within a dynamic structure that can be defined through the interface call, or within the application or database itself. This means that all types of information can be extracted using this type of interface in a single gulp, and you can define the data that is extracted. Databases are the best example of interfaces that provide dynamic data-type interfaces, but many applications, including PeopleSoft, do some of this, as well. This type of interface also works best with information-oriented-type service provider interfaces.