WSMX Adapter Framework

From Wsmx-WIKI
Jump to: navigation, search

WSMX Adapter framework

Abstract The problem of syntactic adaptation from one language format to another is a current problem that exist in all integration applications, where different systems needs to interconnect. The present work addresses the syntactic adaptation problem in a global manner, providing a framework where users that wish to interconnect can design their own adapter and register it with the framework. In particular, WSMX is considered the middleware for which adaptation is done for. The adapter framework is an ongoing work and the current document will be updated as the work progresses.

Glossary


Table of Contents

1. Introduction

1.1. General Considerations

1.2. Overview of the Document

2. Problem Definition and Scope of syntactic adaptation

2.1. Problem Definition

2.2. Addressed languages formats

2.3. Scope of syntactic adaptation in WSMX

3. Adapter framework

3.1. Adaptation principles

3.2 Adapter framework architecture

3.3. Syntactic mappings implementation

3.4. Adapter example – How to build one?

3.5. Adapters registration

3.6. Execution

4. Prototype Implementation

5.1. Design-time Component

5.2. Run-time Component

10. Conclusions and Further Directions

References

Acknowledgements

Appendix A. Change log


1. Introduction

The adapter framework is a common platform for enabling communication between systems that use different data formats. It provides public interfaces for developing and invoking adapters. An adapter is an application specific software component and transforms data from its source to target format or vice-versa. The adapter framework provides adapter skeleton and allows external developers to register (plug-in) their adapters. Registered adapters can be unregistered (plug-out), subject to security policy. Additionally, it allows applications to invoke target application through one of the registered adapters. Direct invocation is also possible if input message (goal) is described in target format.


2. Problem Definition and Scope of syntactic adaptation

3. Adapter framework

3.1. Adaptation principles

3.2 Adapter framework architecture

The adapter framework architecture consists of several components that allow flexible development and easy implementation. The architecture is shown in Figure 1. In the figure, dotted arrow head line represents indirect communication whereas the solid arrow head lines indicate direct communication. The functionalities of the ‘major’ components shown in Figure 1 are briefly described below.


Figure 1 WSMX Adapter framework

Communication Manager – is a gateway to the adapter framework which can be accessed via WSDL interface. It provides message listener awaiting for any new message incoming from the network. Once requested by back end application, the Communication manager interprets the request and and invokes either the adapter manager or the update manager. If the invocation is successful, it returns a response message which contains either a ‘success’ message or the ‘response’ returned from the target application.

Adapter Manager is the core of the adapter framework which schedules job between adapters and data format validators. It updates and refreshes the list of the registered adapters as they are registered and unregistered.

Data Format Validator – is a responsible for validating the data format as claimed by the back end application. A XML message, for example, sent by back end application should pass the XML data format validation process.

Adapter Pool – is the ‘repository’ of all registerd adapters.

3.3. Syntactic mappings implementation

3.4. Adapter example – How to build one?

3.5. Adapters registration

4. Prototype Implementation In this section we introduce the implementation approach and interfaces of the adapter framework. It follows the component based implementation approach and separates the concerns of external developers. This means that the adapters can be developed independent of the internal structure of the adapter framework provided that the development guidelines are followed.

4.1. Design-time Component

4.2. Run-time Component

For the adapter framework to work implementation of all the interfaces have to be provided. In the following adapter framework implementation structure is shown and communication interface and operations are described.

MessageListener – is the interface exposed to the external world for communicating with the adapter framework. It is implemented by the communication manager. At the current implementation stage, it supports both synchronous and asynchronous communication while testing and using adapters, deployment and undeployment of the adapters. Following is the brief description of the supported operations.

  • getDeployedAdapters– returns an array of adapter names that are registered with adapter framework.
  • getRequest (Document)– takes Document as an input and returns Document, where Document is any document.
  • getRequest (Document, adapterName)– takes Document as an input and synchronously returns a Document in source format using an adapter specified by adapterName.
  • getRequest (Document, adapterName, callBack)– takes Document as an input and asynchronously returns a Document in source format using an adapter specified by adapterName.
  • getRequest (WSMLDocument, adapterName)– takes WSMLDocument as an input and synchronously returns a Document using an adapter specified by adapterName.
  • getRequest (WSMLDocument, adapterName, callBack)– takes WSMLDocument as an input asynchronously returns a Document using an adapter specified by adapterName.
  • getRequest (WSMLDocument)– takes WSMLDocument and returns a Document using default adapter.
  • deployAdapter (adapterName, adapterBytes)– takes adapterName and the source of this adapter in the form of a byte array and deploys to the adapter framework and returns a security key. That is the adapter is stored in adapter framework. The security key is required to undeploy the previously deployed adapter.
  • undeployAdapter (adapterName, secirityKey)– takes adapterName and a securityKey and undeploys an adapter associated with this name and securityKey.
  • getResponse (WSMLDocument)– takes WSMLDocument and returns ContextID. ContextID is used for monitoring the progress of request associated with this ContextID.

Adapter – is an abstract class provided by the adapter framework as an adapter skeleton. It provides an abstract method getTranslated that takes a source document and returns a WSML document. All adapter implementations should extend this abstract class. Designers are free to define logic for transforming the source document to the WSMLDocument, however, the transformation results should be made available through getTranslated method.

5. Conclusions and Further Directions

References

Acknowledgements

Appendix A.

Changelog