By Chung Yeung Pang. The Cases to Tackle:

Size: px

Start display at page:

Download "By Chung Yeung Pang. The Cases to Tackle:"

Cecil Johns
5 years ago
Views:

1 The Design of Service Context Framework with Integration Document Object Model and Service Process Controller for Integration of SOA in Legacy IT Systems. By Chung Yeung Pang The Cases to Tackle: Using Service Oriented Architecture (SOA) offers a mechanism of building "plugcompatible" software components that will reduce the costs of developing software systems while increasing the capabilities of the systems. Heavily promoted by almost all major software vendors, organizations are led to believe that SOA would revolutionize enterprise environments by leveraging advancements in Web services technology and raising hopes of federation, agility, and cross platform harmony. Despite all the promises, introducing SOA into an existing enterprise IT system is far from simple. Most existing enterprise IT systems still have mission critical applications programmed in legacy languages such as COBOL and PL1 running on host systems. These applications in general do not fit into SOA structure. Many software vendors provide tools to build wrappers for existing software modules to integrate into SOA. Such integration does not naturally fit into the nature of SOA and imposes a lot of constraints. Traditional transactional based programs are generally Remote Procedure Call style (RPCstyle) and support the transmission of a single data context. SOA on the other hand fully leverages the XML and Web services initiatives. It standardizes the use of a document style messaging that can bundle data related to more than one data context. When a service is provided by a legacy transaction wrapped with a service interface, it imposes an RPC style of messaging. Composition of a number of services with wrapped legacy transactions into a single service would require multiple instances of cross platform communication. The performance of such services may turn out to be unacceptable. Examples of Business Services: For SOA to really take off in an enterprise, we need a framework, a toolset and programming patterns for the integration of legacy applications without imposing constraints into the architecture. To see the problems and the proposed solutions into proper perspectives, consider the following examples of business services. Assume that a service mediator is used to handle the incoming service requests. This service mediator would parse the input XML and render the output XML. It carries out the service process by resolving the business domain service and invoking it. In general, all services are registered in a service repository. The service mediator needs to resolve the physical object from the service name in the service repository and activate it. The following examples show three different service requests: 1. Get Account Information: Consider the case that a service is requested to get the account information of a given account number. The service mediator invokes a service in the account component to retrieve the account information. The body of the output XML has the following form: <Output> <Account no='' type ='saving' > <AccountInfo> </AccountInfo>

2 </Account> </Output> 2. Get Customer Accounts Information: Consider the service request to retrieve information of all accounts of a customer. Now the service mediator would first invoke the service in the customer component to retrieve the customer information. Then it will invoke the service in the account component to fetch all the customer s accounts. Using the account number from each account, the service mediator invokes the same service as mentioned in the previous case to retrieve the account information. The body of the output XML has a slight complicate hierarchy like: <Output> <Customer id=''> <CustomerInfo> </CustomerInfo> <Account no='' type ='saving' > <AccountInfo> </AccountInfo> </Account> <Account no='' type ='custody' > </Account> </Customer> </Output> 3. Get Customer Asset View: A service request is made to get the asset view of a customer. The first set of business domain services required in the service process is the same as the second example. It goes further. For each account depending on the type, the account movements are retrieved through the account position keeping component. The complexity increases because normally there are different account position keeping components for different types of accounts. These components belong to different business domains. For example, normal account position keeping may handle movements of current and saving accounts. Custody account position keeping is in general a service provided by the business domain for stock exchange. Foreign Exchange account position keeping belongs to treasury product business domain. The services from different business domain components to be invoked depend on the types of accounts the customer has. If the information of the accounts is kept in service context during the service process, the services to be invoked are context dependent. The output XML has a more complex hierarchical structure like: <Output> <Customer id=''> <CustomerInfo> </CustomerInfo> <Account no='' type ='saving' > <AccountInfo>

3 </AccountInfo> <Movements> </Movements> </Account> <Account no='' type ='custody' > <AccountInfo> </AccountInfo> <Movements> </Movements> </Account> </Customer> </Output> The above examples show that a pure composition of autonomous domain services to form a compound service for a complex service request does not really work. The compound service requires a certain intelligent to combine the output of various business domain services to build up the document style output message. This service can be complex. It is coupled to all the domain services that can get involve in the service process. The concept of service statelessness and autonomy in SOA does not really apply in this case. In the last example, if the main service to get the customer asset view has to interact with business domain services that are legacy transactions with wrappers in another platform, the overhead of multiple cross platform communication can be very high. The performance of the service is likely to be unacceptable. Proposed Solutions: To optimize the potential of SOA in an Enterprise IT system, design solutions to meet the following requirements are necessary: 1. Support document style messaging across all new and legacy platforms. 2. Allow composition of services to form a compound service across all platforms. 3. Provide a mechanism to invoke the correct services depending on the content in the service context. 4. Provide a mechanism so that each service would be able to retrieve its required information from the input document and insert its output into the output document without the concern of the hierarchy tree structure of the documents. In addition to the functional requirements, the solutions must be supported by a proper toolset to build new services and service adaptors to existing programming modules easily. The proposed solutions involve a service context framework containing the following elements: 1. An integration document object model (IDOM) framework with the following features: Support single parsing and rendering of XML in a compound service. Allow the construction of a document styled service message in IDOM as part of the service context that can be transmitted across platforms.

4 Provide an implementation of the IDOM framework in different programming languages such as Java, COBOL and PL1 for the integration of services across different platforms. Provide a standard DOM (e.g. org.w3c.dom in java library) and XPath APIs for IDOM. Facilitate the marshaling and unmarshaling of data objects in different languages into and out of the hierarchical tree structure (XML style) in the IDOM, based on the metainformation contained in generated data object descriptors. Allow software components to insert, access and remove data objects in IDOM as part of the service context for the collaboration of different software components across different platforms in a business service. 2. A service process controller within the context with the following functions: Compose and invoke services of different software components to fulfill the contract of the business service depending on the context. Control the flow of the process based on a table with entries of pre defined state, event and action. Handle the events triggered by each domain service. The toolset to support the building of services and service adaptors is a UML CASE tool that provides the following functions: 1. Generation of data object descriptors to provide meta information of data objects in IDOM. 2. Generation of service process control tables (i.e. service process control descriptors) from UML state models. 3. Generation of service adaptors for existing programming modules. Figure 1 shows a diagram of Use Cases that summarizes the requirements of the proposed framework and toolset.

Figure 1. Use Cases of IDOM and UML Case Tool. Functions and Structure of IDOM: In the Java platform, DOM functions are provided by standard java libraries such as org.w3c.dom class.

5 Figure 1. Use Cases of IDOM and UML Case Tool. Functions and Structure of IDOM: In the Java platform, DOM functions are provided by standard java libraries such as org.w3c.dom class. XPath supports can also be found in libraries like XLAN from APACHE. IDOM provides similar APIs. To be transported and used in legacy COBOL or PL1 transactions, the dom object must be serialized into a form that can be mapped into a COBOL and PL1 structure. Figure 2 shows the (somewhat simplified) design of the class structure IDOM in serialized and expanded form. As shown in this class diagram, IDOM contains a set of nodes. Each node has all the information (like its parent and children) required that make up a hierarchical tree structure of an XML document. In serialized form, IDOM contains a list of relative address displacements of all the values of the nodes in the serialized stream. The information can be expanded with pointers to these node values. The pointers can be stored in a link list. Adding or removing a node can be done by manipulating the link list.

6 Figure 2. Simplified Design of the Class Structure of IDOM. Data Objects in IDOM: In the COBOL and PL1 worlds data objects are just data records. In Java, they are normal objects containing attributes. Data objects can be marshaled or unmarshaled to or from XML structure. To do so meta information for mapping of one form into another is required. This meta information is given in the data object descriptor. The design of the class of data object descriptor is also shown in figure 2. Data objects are not just used for XML transformation. They form parts of the service context and allow inter communication between activities of a component and across all the components involved. Data objects are attached to nodes in the hierarchical tree structure in the process tree of IDOM. This overcomes the static context nature of conventional transactions and provides a document style dynamic data context. Each data object has an associated data object descriptor. The data object descriptor can be summarized as follows: 1. Provide meta information of a data object for marshaling and unmarshaling of input and output XML structure to and from IDOM. 2. Allow the access of data from a field within a data object via XPath. 3. Instantiate data object (i.e. in Java, create instances of data object and, in COBOL, allocate memory for the data record). 4. Used in the IDOM for locating the associated data object in the hierarchical tree structure of the IDOM.

7 Service Process Controller: The service process controller is used to control the composition and invocation of the domain services. A stack of control nodes is provided in the IDOM. The service process controller behaves as a finite state machine. The function of the service process controller is as follows: 1. Pops up the last entry of the control node in the stack in IDOM. 2. Resolve the next action based on the state and event in the control node: If an error event, handles the error and terminate the process. If the stack is empty, terminate the process. Otherwise proceed to Search for the domain service that matches the state and event of the control node If no match, handles no match error and proceed to 1. Otherwise proceed to Invoke the domain service. 5. Proceed back to 1. For each business service request, there must be an associated service process control descriptor. This descriptor is a table containing entries with state, event, the next state, and the domain service. The service process controller looks up the domain service using the service process control descriptor for a given state and event. The service process control descriptor can be a view of a database table or a generated program with a hash table containing the state event entries. The table should be based on an UML model and it should be generated by the UML case tool. Service Process Scenario: How does the example of a customer asset view service request function when using the service process scenario? The state transition model and the generated control table would look like the illustration in figure 4. Ignoring error handling, the service service process has the following steps: 1. The service mediator retrieves and parses the input XML. 2. The IDOM is built analogous to the input XML structure. 3. The service mediator resolves the service request and loads the proper service process control descriptor. 4. The service mediator pushes the first control node with "Service Initialization" as state and "Customer Asset View Request" as event. 5. Assuming that the whole service has to be handled in another platform with a different programming language, the service mediator would serialize the IDOM first. Then the transaction from the other platform would start and the serialized IDOM data stream will be transmitted. 6. On the other platform, an instance of the service mediator is instantiated. This service mediator would expand the IDOM and start the service process controller. 7. The service process controller pops the first control node out. It looks up the process control state event table and resolves the information concerning the next action. The next state is "Customer Info Processing". The data object descriptor required for the state is "Customer Info". The XPath specifying its hierarchical position (i.e. its parent node) in the XML tree is "/Intput". Unmarshalling is done before the processing action of the state takes place. The domain service to be called is "Customer Info Service". It then resolves

and activate the physical objects from the logical names registered in the service repository. 8. The "Customer Info Service" is called. Customer data will be inserted into IDOM.

8 and activate the physical objects from the logical names registered in the service repository. 8. The "Customer Info Service" is called. Customer data will be inserted into IDOM. At the end, a control node with state "Customer Info Processing" and event "Customer Info Retrieved" will be pushed into the control stack. The service process controller will take over the control again. 9. Similar control process is applied to the next state "Account Info Processing". This state involves the "Account Info" data object descriptor. At the end of the process in this state, a number of control nodes can be inserted into IDOM depending on types of accounts the customer has. 10. The service process controller will pop up the last control node entered in the control stack. It may lead to a next state such as "Custody Account Position Keeping Processing". 11. When "Custody Account Position Keeping Processing" state is completed, a new control node is pushed into the control stack. In the process control table, there is an entry of this state with blanks in the event and service columns. It shows that no following action is required. The control node will be discarded and the next control node will be popped out. The next control node can lead to a state such as "Normal Account Position Keeping". Hence the process will carry on until the stack is empty. 12. When the service is completed, the service mediator regains control. IDOM will again be serialized and be passed back to the original service mediator. Data objects will be marshaled into XML tree structure and the output XML be rendered. The output XML is returned to the service requestor. Figure 3. Generation of Data Object Descriptor from Class Diagram.

9 Figure 4. Generation of State Event Table from State Model for Service Process Control.

10 UML Case Tool: Building programs that contain meta information such as required by the data object descriptor or service process control descriptor is a tedious and error prone job. These programs should be generated from models by a Case tool. Data object descriptor can be generated from a class diagram, which contains a hierarchical structure that can be mapped to an XML structure. However more information is required to provide mapping between an attribute in data object to a node in the XML. In the class diagram, properties like node name, attribute name in the data object (e.g. COBOL physical name), node type (i.e. element or attribute) must be provided. In most cases, the class attribute name would probably be the same in XML and in the data object. Default node type can also be used. The Case tool must provide the possibility of property specifications. Figure 3 provides an illustration of an example of COBOL code generation for a data object descriptor from a class diagram. Fundamental to the service process control descriptor is a table with state, event and service to be activated. It also contains the names of data object descriptors and their XPath information for each active state. All information required for the service process control descriptor can be modeled in a state model as illustrated in figure 4. A program or SQLs for the table can be generated from such a model. To include or exclude a domain service is rather straight forward. One only needs to add or remove the state in the state model and re generate the service process control descriptor. In order to use the IDOM framework and service process controller, a certain programming pattern is required for all the domain services. Existing legacy programs do not conform to this pattern. Hence adaptors must be developed to wrap the existing programs. The adaptors carry out the mapping between the existing data structure and the data objects. They also build the control nodes and push them into the control stack. Usually the data objects match the signature of the modules to be called. They can also be modeled in class diagrams. The extra logic for control nodes can be modeled using activity diagrams. Figure 5 shows such an example. The generation of service adaptor thus requires a combination of class and activity diagrams.

11 Figure 5. Generation of COBOL Adaptor from Class and Activity Diagrams.

12 Summary of the Proposed Solutions: The problems with integrating legacy programs into SOA in an Enterprise IT system can be solved using a service context framework with the following elements: 1. An Integrated Document Object Model (IDOM) that can be serialized and expanded in different platforms. The IDOM provides the full facilities of a DOM so that services across the different platforms can fully support document styled messaging. The IDOM forms a container for the service context. 2. Data object descriptors that provide meta information for the marshaling and unmarshaling of XML style tree structure in the IDOM into native data objects as well as inserting, accessing and removal of data objects in the IDOM. 3. Service process controller is used to compose and invoke the domain services depending on the content of the service context. 4. Service process control descriptor provides the state event table required by the Service Process Controller. 5. Control node stack in IDOM to which a domain service can push the outcome events of it process. The control nodes in the stack will be popped out and handled by the service process controller one by one. The toolset to support the building of services in SOA using the proposed framework is basically a UML case tool with the following features: 1. Generation of Data Object Descriptors based on class diagrams. 2. Generation of service process control descriptors (or state event table for the service process controller) based on state models. 3. Generation of service adaptors for existing programming modules based on class and activity diagrams. Document style messaging across all new and legacy platforms can be fully supported by the use of IDOM. Composition of services in different platforms can be achieved by using the IDOM and service process controller. The control node stack in the service context by the service process controller provides a mechanism to invoke the correct services depending on the content of the service context without overhead. Data object descriptors with their XPath information for their hierarchical position in IDOM provide a mechanism for services to retrieve the required information from the input document and insert data into the output document without the concern of the hierarchy tree structure of the documents. The problems integrating SOA with legacy systems are completely removed using the techniques described in our proposed solutions.

Appendix A - Glossary(of OO software term s)

Appendix A - Glossary(of OO software term s) Abstract Class A class that does not supply an implementation for its entire interface, and so consequently, cannot be instantiated. ActiveX Microsoft s component