Interface Types

Not all application interfaces will provide all of the functionality required to create and operate service-oriented adapters, and adapters are always limited by the capabilities of the interfaces that the source or target systems provide. To this end, it's helpful to define interface types that applications and databases provide that fit with service- or information-oriented adapters.

They are

  • Static data

  • Dynamic data

  • Function return data

  • Function return service

  • Function return abstraction

Static data 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. SAP's RFC is an example of a static data application interface. This type of interface works best with information-oriented-type adapters.

Dynamic data 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 interfaces, but many applications, including PeopleSoft, do some of this, as well. This type of interface also works best with information-oriented adapters.

Function return data application interfaces provide access to many internal functions, such as an inventory check, but only return responses to those functions; they do not make those functions "remotable" to other applications. This is a bit different from the information-oriented types, such as static and dynamic data, in that you do have access to internal application services, and can even make those services available to other integrated applications. However, you can only extract information as responses to those internal services. SAP's BAPI is a good example of a function return data interface.

Function return service application interfaces provide the adapter with the ability to abstract a static service to the integration server or connected composite application. This is another level over function return data interfaces in that you not only get an answer back from the invocation of a function, you can also bind the remote static function to another application, making it appear as if it were a local function. Any RPC-based application is a good example of a function return service application interface. Web services are another example; indeed, more SOAI products will leverage function return service interfaces, if they are available.

Function return abstraction application interfaces provide the adapter with the ability not only to gain access to a remote service or function, but also to alter that remote service or function to meet the needs of another application or applications. What's unique here is that we can inherit remote services, tossing away what we don't need and adding what we do. What's more, we can do this without changing the code in the serving application. In essence, this is very much like, if not exactly like, object-oriented programming mechanisms.



Next Generation Application Integration(c) From Simple Information to Web Services
Next Generation Application Integration: From Simple Information to Web Services
ISBN: 0201844567
EAN: 2147483647
Year: 2005
Pages: 220

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net