Scalable E-Business Integration Thang N. Nguyen California State University Long Beach (
[email protected]) Abstract: This paper presents a scalable Business Service Model (BSm) for the client/server environment. The model architects and embodies solutions to a rather large class of common enterprise-level e-business integration problems involving message exchange and field-level message handling. The model and its prototypical solutions are based on a distributed (control) execution concept (without the need of IDL compilation process) with global (centralized) knowledge of the enterprise application information suing LDAP, with configurable DLL inline services to add specific functionalities, and with connectors and adapters to extend services to connect disparate worlds. These include legacy systems, object-oriented systems (e.g. COM/DCOM-CORBA), shrink-wrapped package applications (e.g. SAP R/3, PeopleSoft), financial network (e.g. SWIFT) and others application systems (e.g. native IBM MQSeries applications), to keep the enterprise e-business application connected, operational, alive and well. Keywords: Business Service, Service-oriented architecture, e-business integration. Introduction Application-to-Application communication concepts and mechanisms have been developed since the day there was a need for programs to communicate with one another. Concepts such as shared memory, named or unmade pipes (FIFO), and others, initiated the name of IPC (InterProcess Communications) using a predefined communication area (in S/360 assembler language or IBM transactional CICS system) or a linkage section (in COBOL) have been used for many decades (Linthicum, 2000). The Remote Procedure Call (RPC) used in various original client/server models and the newer schemes based on RPC concept such as OSF/DCE, Microsoft COM/DCOM, CORBA, and Sun Java RMI have appeared and become widely accepted (Zahavi et al. 1999, Altman et al. 1999)). All these schemes however require a pre-compilation step using a language generally called Interface Definition Language (IDL) to set aside work areas in each machine (stub and skeleton) for storage of data fields to be sent/received between applications to resolve the difference between data types and formats, and to publish the caller/callee interface between different applications (Wallace, 1999). Advanced concepts for client/server models beyond the basic model of one client-one server helped the creation of concepts such as object factory, directory, dynamic library and the like (Software Technology Review 2002). This paper presents a rather different line of concepts pertaining to client/server model (Nguyen, 2002) and extends the model to meet e-business scalability requirements both horizontally and vertically. With this model, the paper argues that for a large class of common problems in enterprise application integration in particular and in e-business integration in general, the concept of the model and its implementation will be found to be powerful, fast, with ease of use and maintenance, with high flexibility in reusability and scalability.
Scalable client and server application program (basic) structure The application structure discussed here consists of 4 major layers: on the top is the application logic layer where business logic is coded. The API layer consists of basic API calls in a Client/Server (C/S) system such as get connected (or initialization), put request (or put response, if server), get response (or get request, if server) and get disconnected (or termination). These APIs are mapped to the transport layer API at the bottom level for sending and for retrieving messages from the input queue associated with the application. The transport layer may or may not offer asynchronous messaging. In the context of this paper, we assume the underlying communication scheme is asynchronous (e.g. message-queuing, IBM MQSeries). The middle layer called exchange connector with configurable inline services (selected DLLs) is the heart of the structure. The exchange connector’s primary function is to route the message to the intended application server via the translated API calls which then place the message in the input queue (if asynchronous communication) of the target server. The configurable inline services are to provide specificity in required services that each client or server application may require. (Figure 1, Application program structure). By inline services, we mean specific prepackaged, function-specific DLLs that can be dynamically called and loaded to provide a particular service such as encryption/decryption, conversion, etc. All queues are input queues. The message from an application (e.g. client) will be placed in the input queue of the target receiver (server) by the underlying transport mechanism. Application logic
Application logic
Application logic
APIs
APIs
APIs
Exchange connector (configurable inline services
Exchange connector (configurable inline services
Exchange connector (configurable inline services
Transport
Transport
Transport
Application program structure
Client and Server program structure
Figure 1: a 2-tier Client-Server application program structure
The above four layers of the model are packed together as a single application module to be executed at the client side or at the server side. Note the similarity in structure of the client and server applications in the 2-tier C/S model (Figure 1, C/S program structure). This 2-tier architecture can be extended to an n-tier architecture where all participating applications are structurally the same. The servers do not need to be up before the client to listen to the client’s request since the transport mechanism is asynchronous (like e-mail). The program structure shows that the difference between a client and a server is in the business logic, the types of API calls and the configurable inline services only. This structure simplifies the common client/server model using previous IPC schemes in a couple of many ways:
• •
•
There is no need for a pre-compilation step as in the case of RPC, DCE or CORBA using IDL language to build a stub or skeleton for the application For sending and receiving messages, the APIs calls are initialize, put, get and terminate. The whole message will be sent to the server application for subsequent processing. At this level, there is no need for the declaration of the differences in data types and data formats such as little endian at client side and big endian at the server side. Options can be specified for the get or put to further taking care of any particular need that may be necessary such as in a request that may not require a response (fire and forget scheme) or a request that requires notification in case of error, confirmation of arrival or confirmation of delivery of message. The APIs, by their functions, are mapped to the asynchronous transport APIs, thus hide the complexity of the latter from the developers. Each and every application in the client/server model has the same basic exchange connector codes. It is where the messages are prepared for exchange and delivery to the target queue. The inline services provide function-specific services. They are configurable to provide specificity to the application in terms of requested or required functionalities. For example, the application may want its message encrypted for security reason. The inline services are dynamically linkable to the program structure.
Business Service Model: the concepts of distributed control of message exchange, centralized knowledge of business processes and extended connectivity to different worlds At this point, there are at least two obviously unresolved basic issues: • •
How the client will find the server program? How a 2-tier or n-tier client/server application is specified and executed? How the difference in sent/received message formats and field-level data formats is resolved?
In fact, by answering the above questions, we will show that the exchange connector illustrates the concept of distributed control given to each of the application participating in the client/sever system, using the knowledge (more than just name and address) stored in a directory is a realization of the concept of centralized knowledge of the system, and capable of accessing different and disparate server applications with connectors and adaptors implementing the concept of extended connectivity. The answer to the first question lies in a concept called Business Service-Component-Element concept. A business service is considered and defined as a structure consisting of a number of serial steps defined as business components where each business component is associated with an executable program carrying out the actual task of the step, called business element. The business elements may be written in different languages, running in different platforms at different locations. Each business element has the same program structure of Figure 1. A web online order application server example is shown below. Business Service A (e.g. Web online order) Business Component1 (e.g. request order) BusinessElement11 (e.g. program written in VB script and HTML) Business Component2 (e.g. check credit)
BusinessElement21 (e.g. program written in Java servlet with DB access) Business Component3 (e.g. place order) BusinessElement31 (e.g. program in C++)
Although shown as a hierarchical structure (Business Service, Business Components, Business Elements) the model is linear in the sense that a service is conceived as a series of successive business elements. Thus, a business service is an aggregate of consecutive steps carried out by business elements. The notion of business component is to separate the e-business layer (business service) from IT implementation layer (business element). Business analysts only have to think about a service and its successive business components (steps of the business process). This allows IT professionals to equate business components (in business terms) to actual executable program modules that carry out the execution. The BSm structure embodies the information of the business service and its business rules (e.g. the order of execution of the steps) governing the participating applications. The BSm can contain any number of steps. A client will do a putRequest to the business service (continuous arrow). The message from the client will be directed to the first business element (dotted arrows) of the business service according to Figure 2. The response form the last business element will be sent to the intended client (continuous arrow). Client
Business Service
Business Component1
Business Component2
Business Element1
Business Element2
Figure 2: Business Service Model
Exchange connector as the heart (engine) of the BSm with distributed control for the routing of messages. The exchange connector of the client involves a putRequest by the client’s application logic to the input queue of BusinessElement1. The exchange connector of Business Element1 then does a getRequest from its queue, processes the message and subsequently does a putResponse to the input queue of BusinessElement2. The exchange connector of BusinessElement2 subsequently does a getRequest from its own queue, processes the message and does a putResponse to the input queue of the client. Finally, the exchange connector of the client maps the getResponse of the client’s application logic to retrieve the message from its queue. The execution as described is of request/response type. The client does not need to be tied in with any particular business service. Any client can specify at run time any business service described in the directory. The sequence of server applications (the business elements corresponding to the business components of the business service) is transparent to the client. The change to the business process execution order can be
made in the directory independently to the client. The association between business components and elements can be dynamically modified in the directory according to business needs. The business process can be extended or shortened. The steps within the series of business service can be bypassed, inserted or removed by addition or deletion of business components and business elements in the business flow definition or specification. Since the client program and each and every participating business element has the same program structure in which the exchange connector is responsible for the placement and retrieval of messages from the associated queues, the exchange connector plays the role of a control program that is distributed to all participating elements. The message (request or response) is passed along the business service structure by the corresponding exchange connector with a complete routing information it carries. LDAP directory as a centralized knowledge accessible by the exchange connectors To answer the second question, we notice that the difference between message formats and their internal data structures must also be known, described and handled. The message could be of XML format or in any message formats generated by any old and/or newly created applications. The difference, if any, between data types and formats, i.e. field-level of the messages might be handled by conversion or transformation maps. Thus, the name of sending and receiving message and their format names, as well as those of the client, business service, its component and corresponding elements, and the characteristics of each participating application such as queue name, queue manager name, channel name, the host name in which it resides, and other information must also be known, stored and accessible by the exchange connectors since these pieces of information specify the application and some are needed for the underlying transport layer. A LDAP directory is used for this purpose. The directory stores the information of the participating applications, their hosts, their interface, as well as the complete information on the messages between a client and the servers, their name, their formats, their structures to the field level. The directory maintains the complete knowledge of all components involved in this n-tier client/server model. The directory is accessible by the exchange connectors and can be in any host (machine) or platform. The LDAP directory in a BSm is a network-based central repository of information on all objects including the business process and business rules. Extended connectivity to include disparate applications So far, we have not paid much attention to the nature of the server applications. These applications may already exist and can be as complex as commonly found in today's multithreaded, load-balanced, load distributed, disparate destination-based, n-tier client/server applications and/or enterprise-level process-based systems. The systems and applications may run on a structured world with mainframe legacy applications and databases. They may belong to different object-oriented worlds consisting of COM/DCOM or CORBA-compliant applications. They have different data structures, message types and formats. They use different transport protocols and use a wide range of different technologies and architectures (mesh, hub-and-spoke,
bus or pipe). The result is that the applications can be isolated, disconnected, inconsistent, incompatible, duplicated, unstructured, and/or mismatched. We need an extended connectivity to provide access to these applications. This is done by a collection of different connectors and adaptors. Thus, a connector to SAP R/3 will provide access to SAP R/3 application. A connector to mainframe will allow distributed applications (Windows and/or Unix, any flavor) to communicate at the application level to mainframe applications. Proof-of-concept example client
“look”
repeatString
“look:look”
reverseString
“kool:kool”
Figure 4: Message exchange Configuration record example in LDAP Business Service (TestCombo2) Business Component1 (RepeatStringStep) Business Element1 (Repeat String, queueName, queueManagerName, etc..) Business Component2 (ReverseStringStep) Business Element2 (Reverse String, queueName, queuManagerName, etc.) Client (ClientGroup1, queueName, queueManagerName, messageFormatName, etc..)
An example is shown below with a client named c_client.exe (written in C language), the first server called java_server.exe (written in Java) to repeat the string and the second server called vb_server.exe using VB/ActiveX to reverse the received string from java_server according the “business process” in Figure 4.
Figure 5: The client program sends the message “look” and receives the message “kool:kool” as expected
Figure 6: The first server (BusinessElement1) repeats the message received
The actual execution of this client-server application is shown. The MS Command prompt window simulates the client program (Figure 5). Figures 6 and 7 simulate two server programs that correspond to components #1 and component #2 of the business service TestCombo2. The string sent by the client is “look”. The string is converted by each of the server component and received as “kool:kool”.
Figure 7: The second server (BusinessElement2) reverses the string receives and sends back the reply
Solving e-business messages exchange problems In the above example, the message is a simple string. In reality, the message can be anything. Between a client (or a server acting as a client to the next server such as java_server in the example) and its server, there are three possibilities: (1) matched: the message formats at the sending end and at the receiving end match perfectly, (2) mismatched: there is mismatch between them, e.g. “first name, last name” in the sending message and “last name, first name” in the receiving end, or change of zoned field to decimal field, and (3) gap: there is a gap such as the expected message at the receiving end includes a field newly created, a combined field or a calculated field. The last two possibilities call for some manipulation of the message content. If there is mismatch, the mismatch can be converted using a simple map that involves only re-arrangement of the order of data fields, or simple, implicit conversion. In the case of a gap, then there is definitely a need for a more involving transformation. The conversion map or transformation map needs the logic for changing the input fields to the intended output fields. To solve this difference due to mismatch and gap, there is the notion of message descriptors and message formats associated with the client and the need for a conversion map when the format of the sending message is different from that of the receiving. If the default option of the server is to receive any message format then the message will be received as-is (binary or string such as in File Transfer Program). If the receiving end specifies a particular message format expected that is different from the message sent, then a conversion is called. For example, if the client expects a message with format xmlReply and the server expects message format xmlRequest defined in the directory’s client and server records, and the format
of the sending message is different from the expected message then conversion map is called. We will discuss conversion and transformation in the next sections. It places the conversion outside of the participating programs, therefore give more flexibility to the conversion task when there is a need for change or modification. The conversion can be done at the client or at the server side. Additional inline services such as compression before sending the message out to the communication network to reduce byte transfers can also be specified and performed. Solving field-level message handling problems via conversion with XML The key issue of message conversion with XML is the capability to allow disparate applications to be integrated without rework, modification of current application or application development. Messages can be dynamically converted as required from any format to any other format. All this can be done via a configurable inline service called Conversion with XML. The conversion can be XML-to-XML or between XML and non-XML (raw) format. This implies that the BSN can be XML-based for XML-XML conversion between applications of BSN, and XML-raw and raw-XML conversion are used only when needed such as when involving with legacy applications. The fundamental concept that triggers the conversion relies on the detection of the difference between the message sent and message received in terms of message formats. The trick simply specifies the name of the expected message format that is different from the message format sent. The message format names are defined in a particular area of the directory (called the MetaData Repository) or MDR associated with the source and target objects as well as a conversion map between the source and target. For each message format, a message descriptor must be defined in the directory. To address message handling at the data field-level (types and formats), the model must have a set of APIs to allow the client and server application programs to create and access to message buffers without prior knowledge about the structure or layout of the messages, and without knowledge about the data types. Moreover, the message handling APIs should handle XML and non-XML (raw) messages in exactly the same way with the same APIs. Scalable Business Service Model as solutions to meet e-business integration challenges Scalability is a big issue for e-business applications (Bhattacharjee, 2002). To live up to enterprise e-business integration challenges, the BSm model must be able to scale out horizontally and up vertically. In this section, we argue that the BSm model is mappable to service-oriented architecture, therefore the scalability is inherent. The very simple nature of Business Service-Component-Element provides a capability for horizontal scaling. When a component is specified as composed of more than one business element, a load balancing scheme can be implemented if all business elements associated with the business component are functionally equivalent. These business elements can be different programs running on different platforms at different locations as long as they are functionally
equivalent, i.e. offering the same manipulation of messages and providing the same output messages. Any minor differences in message formats and structures can be resolved by conversion routines at the sender or receiver site. Vertically, the scalability appears to pose some level of difficulty since one might argue that the business service model is linear (restricted to a series of business components) therefore can’t handle nested enterprise business services that are both in series and in parallel for all practical purposes. Let’s define business flow as a collection of business services that are conditionally related. In a typical flow, two business services may be executed in parallel before conditionally triggering a third business service. A particular business service may want to conditionally send its messages to different business services. These issues may be addressed by message handing capability at the field-level of the BSm. One or more conditions can be inserted in the message structure so that their contents can be retrieved and valuated for subsequent distribution to other servers. From the centralized knowledge (directory) point of view, the LDAP can be also replicated to provide scalability and fail-safe operations. In the following we will consider a BSN (Business Service Network) as a collection of BSm’s. Business service model and Gartner Service-Oriented Architecture As shown in Figure 8, the model is mappable to SOA suggested by Gartner (Natis, 2000). The C API handles traditional procedural programs with fine granularity. The BSN object model for object-oriented languages (Java or C++) map well to the object level of SOA. Both C API and object model relieve the developers from the complexity of MQSeries APIs. The BSN provide access to COM/DCOM of Microsoft and OMG CORBA specifications as implemented in Orbix or VisiBroker to link the BSN world to other worlds. XML capability of BSN not only link Web front-end applications to back-end legacy applications but also provides an elegant way of transformation with no or minimum changes to legacy systems. The transformation can be at the message exchange level or at the simple field-level of message. The transformation uses a consistent Message Handling APIs. Thus, BSN is adaptable to the concept of e-business service of SOA. Scope
E-business services Services
HTTP+ Workflow, hierachical BSNs
Components Objects
MOM, BSN ORB, Object model Traditional programs
C APIs Coupling
Granularity
Figure 8: SOA-mappable
Within a BSN, it is scalable either vertically or horizontally. In fact, a BSN is capable of providing the connectivity of components across all platforms (Windows, UNIX of many flavors
and S/390), across all shrink-wrap systems (SAP R/3, Peoplesoft), across all major schemes of asynchronous messaging (IBM MQSeries, MSMQ, TBBCO pub/sub), whether they involve integration broker or message broker (IBM MQSI, Mercator), different object models and systems (MS COM/DCOM, CORBA). The delivery of messages across the boundary of BSm’s and BSN requires proper configuration and definition (channels, queue managers, etc.) of the underlying transport mechanism (e.g. IBM MQSeries). Concluding remarks In this paper, we have presented a model for client/server, for current and future open message-based computing environment, in particular for e-business integration. The model is based on the concept of business-service-component-element called business service model (BSm). The BSm model is defined with three powerful and simple concepts. First, the distributed control concept with exchange connector playing the role of the heart (engine) preparing and pumping messages through connecting applications of the C/S system, just like the blood is prepared for being pumped in and out of the heart to reach different organs and organ systems in the circulation system. The collection of exchange connectors and their paths across all applications appears as an artery for message circulation. Next, the directory (using LDAP protocol) as a centralized store of information and business rules, acting as a brain storing business rules and complete knowledge on its environment (memory). Third, we present the concept of extended connectivity acting as the limbs to provide directional access to disparate applications from and to other worlds: object-oriented, CORBA, COM/DCOM, Brokers, mainframes, workflow, and others. The BSm provides an easy interoperability among disparate MOMs and computing platforms. APIs are defined at both message exchange level and field-level message handling, therefore BSm is destination-based and content-based. Developers can write applications for portability among different transport mechanisms. With the BSm, applications and services of a wide range are mappable to service-oriented architecture in the sense of Gartner. We extend the concept of BSm to that of BSN that is capable of sacalability, flexibility and re-usability, load balancing and fail-over operations. Thus, BSm and BSN constitute a working architecture for a large class of EAI and e-business integration problems as well as e-business interoperability. References Altman R., J. Hill, J. Klein, B. Lheureux, Y. Natis, M. Pezzini, R. Schulte, S. Varma (1999). Middleware: The Glue for Modern Applications, AIMS Strategic Analysis Report, R-082601, Gartner Group, 1999 Bhattacharjee D., 2002, http://www.intelligententerprise.com/020613/510feat3_1.shtml?/scalability C/S Software Architecture (2002). Software Technology Review, online, www.sei.cmu.edu/str/descriptions/clientserver_body.html CORBA (19xx). CORBA Overview, online. www.infosys.tuwien.ac.at/Research/Vorba/OMG/arch2.htm DCE (2002), online, www.sei.cmu.edu/str/descriptions/dce-body.html Dogac, Asuman, Cevdet Dengi and Tmaer Oszu (1998). Distri buted Object Computing Platforms, Communications of the ACM, Vol. 41, No.9, September 1998
Linthicum, David (2000). Enterprise Application Integration, Addison Wesley. Murphy, Eamon, Steve Hayes and Matthias Enders, (1995). TCP/IP Tutorial and Technical Overview, 5th edition, Prentice-Hall. Natis, Y. (2000). The birth of e-business platform, Gartner Symposium ITxpo 2000 Nguyen, Thang (2002). CandleNet Application Service Pac (CASP) from the bottom up, Candle Internal document. Oracle (2001). Oracle8i Integration Server Overview, online www.oradoc.com/ora817/a83729/adois01.htm OS/390 Guide to e-business Connectors: 2nd Edition, online, www.s390.ibm.com/marketing/gf225124.html Raj, Gopalan Suresh (19xx). A Detailed Comparison of CORBA, DCOM and Java/RMI, online, www.execpc.com/~gopalan/misc/compare.html RPC (2002), Software Technology Review, online, www.sei.cmu.edu/str/descriptions/rpc_body.html Wade, Andrew (1997). The Challenge of Scalability, Distributed Object Computing, July 1997 Wallace, Nathan (1999). COM/DCOM Blue Book, Coriolis. Wallnau, Kurt, Nelson Weiderman and Linda Northrop (1997). Distributed Object technology with CORBA and Java: Key Concepts and Implications, Techincal Report CMU/SEI-TR-97004 Windows API Guide (2000). Introduction to the Windows API, www.vbapi.com/articles/intro/part01.html Zahavi, Ron and Linthicum, David. (1999). Enterprise Application Integration with CORBA Component and Web-Based Solutions, John Wiley & Sons.
