SCORE® Composition Manager™ is the central tool of SCORE Adaptive Bridges that the developer uses to create and maintain adaptive services. Information on legacy applications and data stores are discovered. New services are then composed following the OMG EDOC-ECA/CCA standard. The final step is the automatic production of everything needed to implement the service on the client, middleware and server platforms:

• Discovery – The first step in MDLI is to discover PSMs for the interfaces to your legacy applications and data stores. These are then automatically transformed into PIMs for composition into your adaptive services.
• Composition – In the second step of MDLI you create your service-based composition model from the various PIMs of the legacy applications and data stores.
• Production – In the final step of MDLI your adaptive services, as defined by your composition model, are transformed by SCORE Adaptive Bridges into PSMs and then into code for the application adapter (on the server side) and the adaptive proxy (on the client side).

Composition Manager gives you the flexibility to work the way that you want. You can start with your legacy applications and data stores and “work forward” to your new adaptive services. Alternatively you can start with the new adaptive services and “work backwards” to the legacy applications and data stores. You can even start in the middle and “work outwards”. Composition Manager allows you to work the way you want. The composition repository ensures that your model remains consistent irrespective of where you start and in which sequence you decide to work.

Discovery

The first step in MDLI is to discover PSMs for the interfaces to your legacy applications and data stores. These are then automatically transformed into PIMs for composition into your adaptive services.

In vertical integration scenarios you will also discover the PSM for the target platform, for example when using Web services discovering the PSM from the WSDL tell SCORE Adaptive Bridges the interfaces you want to build for your adaptive services.

This is often the most effective way of proceeding as the interfaces of the services that you need to produce have already been defined, for example by an XML-based standard for your specific industry or market. If such interface definitions are available then you can discover and reuse them from within SCORE Adaptive Bridges – you do not need to define then a second time.

Depending on the amount of metadata available from the PSM it might be necessary to augment the PIM, for example to include information about the way that the legacy application functions are to be invoked. Details added at this stage include details of function codes, calling sequences, parameter mapping, data structure mapping and other physical details of the legacy application. The objective is to encapsulate all of these physical details of the legacy application and to present a clean and reusable interface for composition.

A full object model is available for accessing data stores independently of the underlying implementation technology. Service consumers can access all data stores using a simple collection of standard services. SCORE Adaptive Bridges includes sophisticated tools that handle all of the physical details of accessing a wide range of relational databases and flat-file systems. In each case the same object model is presented for composition. The result is that the developer does not need to be considered with any of the storage or physical navigation details of the database.

Discovery is also the process whereby you can reuse full or partial composition model elements. If you have a common set of interfaces, data structures, method descriptions etc then you can define these in a shared composition repository. You can then refer to these central definitions from the concrete composition models for your real adaptive services. The dependency and reference tracking features of the composition repository allow you to keep control of what is being used where. When a shared object is updated you can easily find out where it is used and then roll the changes through your application in a controlled and manageable way.

Discovery adapters are available for an extensive range of both legacy and current implementation technologies and databases.

Additional discovery adapters are easily created, for example to support project-specific requirements. For a list of currently available discovery adapters please see Supported Platforms.

Composition

In the second step of MDLI you create your service-based composition model from the various PIMs of the legacy applications and data stores.

Composition involves describing the adaptive services to be created, as well as mapping between the services providers (the legacy systems) and that of the service consumers (the new application or client).

The composition model implements the OMG EDOC-ECA/CCA standard. You are working with at least two components – the legacy application function or data store that you are reusing, and the component that represents the adaptive service that you are making available to your client platform.

Composition involves both static and dynamic information. The static view is the structure or composition of the service in terms of other objects at a lower level of granularity. The dynamic view represents the choreography of the composition – how the different components work together to implement a specific business transaction.

The more information you can define about the way in which the external interface of your adaptive service should work, then the more opportunities SCORE Adaptive Bridges has to optimize the runtime behavior. It is also then possible to generate additional code to ensure that the sequence of expected messages is being respected. If the expected message flow sequence is broken then the adaptive service can recover from this and take a sensible recovery action.

Choreographies are also defined for the internal behaviors of the adaptive service. In this case the choreography defines the internal process used to implement the service. This includes invoking operations from legacy applications and/or data stores, checking results, combining and transforming data and general processing control.

It is within Composition that you declare additional information that Production requires to produce optimal code for the selected deployment platform.

Production

In the final step of MDLI your adaptive services, as defined by your composition model, are transformed by SCORE Adaptive Bridges into PSMs and then into code for the application adapter (on the server side) and the adaptive proxy (on the client side).

The application adapter and adaptive proxy are created independently of each other. This allows additional proxies to be generated for new platforms, for example, without affecting your legacy applications.

The way in which the application adapter and adaptive proxy are generated is very dependent on the deployment platform. For more information on the way in which the runtime architecture is created for the different deployment platforms please see the Runtime View.

A key objective of SCORE Adaptive Bridges is to create a “win-win” situation for both legacy and client developers. An important contribution towards this goal is to produce an adaptive proxy that is 100% compatible with the client development environment. This means not just generate correct code, but also to be consistent with the cultural conventions of the client platform. For example, a Java developer expects a Java class to have a certain way of working, to be documented with JavaDoc, to fit into standard Java development environments such as NetBeans etc. SCORE Adaptive Bridges produces adaptive proxies that follow all of these conventions so that the Java developer is happy to use the generated Java classes and not be at all concerned with what is happening behind the scenes.

The composition repository keeps detailed information on the dependencies between the different elements of the composition model. This allows SCORE Adaptive Bridges to optimize the production of code components. Only the minimum set of code is regenerated consistent with what you have changed in the composition model. This concept is also applied to changes in deployment platform, middleware etc – the clearly separated logical layers of the runtime architecture means that not everything needs to be regenerated. In many cases the amount of code that has to be regenerated is minimal.

Platform adapters are available to produce native, non-invasive, optimised implementations of your service for your chosen machine, operating system, language, TP monitor, middleware and databases. Changing to a new deployment platform is literally “only a click away”.

Additional platform adapters are easily created, for example to support project-specific requirements. For a list of currently available platform and technology adapters please see Supported Platforms.

Where to Go Next?

The next section introduces you to the SCOUT² Development Platform, Delta’s extensible development platform for project teams using multiple platforms, toolsets and change control environments.