The Application Adapter is generated for the server side and provides paradigm mapping between the procedural and functional approach of legacy applications and the service-based architecture exposed to clients.

The application adapter is language specific but is not aware of how the client and server communicate – that is the responsibility of the Technology Adapter.

Object-Relational Mapping

When accessing legacy data stores the application adapter handles the relational-object mapping between the relational or flat-file data store and the object-model with its factories and navigator methods as used in composition models. It is the application adapter that also provides the controlled and managed access to existing data stores.

Internal Choreography

The Composition Manager is used to define the choreography for the internal processing of the adaptive service. In other words, the details of allocating and using data, calling functions in the legacy applications and evaluating the results. The choreography is also responsible for standard functionality such as mapping the session logic of the service with the transaction logic of the legacy application and/or data stores.

Interface Rightsizing

Existing applications were typically not designed for use in a distributed service-based architecture. One aspect of this is that the interfaces to the existing functions are often very large, with 150K or more of data being passed on each and every function call. This is clearly too large to be passed to a networked ore remote client on each call.

On the other hand, a client developed with an object-oriented approach tends to create a very large number of fine-grained set/get methods, each of which passes very little data. The end result is that there is a clear mismatch between the granularity of the required services and the existing application.

The solution to this problem is to define multiple interfaces in the PIM composition model and then use the most appropriate interface in each case. The application adapter contains the code generated to support this interface rightsizing.

State Management

When the interfaces to the existing application and the exposed service interfaces have different granularities then an issue arises as to who is taking care of state management. If the existing application requires 150K of data on each function call, and only the 2K which is actually required is passed from the client, then it could be necessary to save some of the 150K somewhere and make sure that it is presented back to the existing application on each function call.

In situations such as this the application adapter contains the code necessary to save and restore the state data for the existing application. The application adapter only handles the state data at the logical level – the technology adapter manages the physical storage of state data.

Multiple Interface Versions

Integration is a process and not a one-time event. It is often the case that a change needs to be made to a service interface once the application has been deployed. In this situation SCORE Adaptive Bridges freezes the existing interface to maintain stability in the deployed application. A new version of the interface is then created in the composition repository to accept the change.

The application adapter is generated with support for both the old and new interfaces. This allows the server to communicate with both “old” and “new” clients at the same time, allowing a managed deployment of the updated clients. This is a real benefit where there might be many thousands of deployed clients and it is impossible to update them all at the same time.

Where to Go Next?

Now that you have looked at interfacing with the legacy application, please continue to Technology Adapter to see how we interface with the middleware and communications platforms that connect client and server.