This section explains the way in which SCORE Adaptive Bridges generates the functionality of your adaptive services into a series of layers that are deployed on the client and server platforms. The objective of this section is to help you to understand the code we generate with a broad overview of what goes where.
The purpose of having a clearly layered architecture is to obtain a clear separation of concerns. Each layer is responsible for a clearly defined set of functionality. This keeps things simple, flexible and improves the stability of the overall application. Changes tend to affect only a single layer and do not “ripple” across the complete application.
Here are the logical layers in the runtime architecture:
- 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.
- Technology Adapter – Is generated for both the client and server sides and is responsible for communications and interfacing with the selected middleware (if any). The technology adapter is very platform specific.
- Adaptive Proxy – Is generated for the client side and is responsible for exposing the external interface of the adaptive service to the client application. The adaptive proxy is unaware of how the client and server communicate. The adaptive proxy is optimised to integrate seamlessly in the client development environment, both at the technical and cultural levels.
Development Platform Integration
A valuable benefit of SCORE Adaptive Bridges is that the generated client and server layers can be directly used by the standard development tools and platforms. For example, client-side code will be generated with the appropriate project files to allow the client developer to work directly with the adaptive proxy. This allows both client and server developers to maximize the value of their existing skills and technology when building and using adaptive services.
Depending on the selected deployment platform it may be necessary to supply supporting information that will be used to deploy the generated layers into the runtime environment. SCORE Adaptive Bridges has fill knowledge of the services and their interfaces from the PIM in the composition model – it is therefore possible to generate deployment information as required, for example the deployment descriptors used with Enterprise Java Beans.
Mapping of Layers to Modules
It is important to understand that the layers we are talking about here are logical layers in the runtime architecture of the generated adaptive services. The way that these layers map into compiled and linked components is very much dependent on the selected target platform.
Each platform, and especially middleware, comes with its own restrictions. SCORE Adaptive Bridges knows about these rules and restrictions and works with them when generating the platform specific code for each layer.
Independent Layer Generation
A further advantage of the layered architecture is that the layers are generated separately and independently from each other. This means that a change of client platform, for example, does not impact at all on the application adapter.
Depending on the restrictions of the selected platform it might even be possible to swap out one or more of the layers dynamically at runtime. This separation gives you a high level of flexibility when you start to support additional platforms or deployment technologies.
As the layers are generated from the composition model it is possible for the code to be generated in a sophisticated but flexible manner. Leading edge concepts such as Code Weaving and Aspect-Oriented Programming are used by the SCORE Adaptive Bridges generators when creating optimised code for each layer.
The layers are generated as native code and so can be managed and administered using the standard tools and utilities for the client and server platforms.
No Central Broker
Adaptive services are a logical concept that is defined within your composition model. When SCORE Adaptive Bridges generates the client, server and middleware code for your adaptive services there is no “central node” or “broker” in the generated architecture.
The client and server speak with each other directly using the selected communications technology and/or middleware. By avoiding a central node or broker the generated code is efficient and avoids the bottlenecks and system management problems that so often occur with other approaches.
The direct communication model makes it much easier to support a multi-grained approach to interfaces. Each consumer of a service can have the interface that best suits its own needs. In few cases will this service interface be the same as that offered by a legacy application and/or data store. The adaptive service absorbs the mismatch in interface specifications.
What Goes Where?
The runtime implementation of the adaptive service is mostly generated for the server side in the application adapter, with the remainder being generated into the technology adapters and the adaptive proxy. The exact allocation of logical functions to physical code and source components depends on the selected deployment platforms and/or the selected middleware products. Please refer to the Deployment Scenarios for more specific information on “what goes where” for specific deployment platforms.
Where to Go Next?
Now that you have an overview of the overall runtime layer architecture, please continue to the next section Application Adapter for details of the code generated for the server side to interface with the legacy application.