Seamless Application Integration Through Transparent Shaping
Total Page:16
File Type:pdf, Size:1020Kb
Seamless Application Integration through Transparent Shaping S. Masoud Sadjadi Philip K. McKinley School of Computer Science Department of Computer Science Florida International University Michigan State University Miami, Florida 33199 East Lansing, Michigan 48824 Email: sadjadi@cs.fiu.edu Email: [email protected] Ironically, the difficulty of application integration, once Abstract alleviated by middleware, has reappeared with the prolifer- ation of heterogeneous middleware technologies [36]. As a Test!!! The difficulty in integrating existing applications, result, there is a need for a “middleware for middleware” to due to the heterogeneity of programming languages and enable Internet-wide and business-to-business application platforms, was to have been solved by middleware. How- integration [36]. Successful middleware technologies such ever, the problem has reappeared with the proliferation of as Java RMI [20], CORBA [27], and DCOM/.NET Remot- heterogeneous middleware technologies such as Java RMI, ing [9, 25] have been able to integrate enterprise-wide ap- CORBA, and .NET Remoting. As a result, there is a need for plications. However, such middleware technologies failed a ”middleware for middleware” to enable integration of ap- in the integration of applications managed by different en- plications developed using different middleware technolo- terprises connected through the Internet. Two reasons be- gies. Recently, Web services have been successfully used to hind this failure were (1) different enterprises chose differ- integrate such applications. However, the integration task ent middleware technologies, which were more appropri- typically requires direct modification of the source code ate to integrate their own applications; and (2) middleware of the constituent applications. In this paper, we demon- packets could not pass the Internet firewalls. strate how heterogeneous applications can be integrated Web Services [3] offer one approach to addressing this with one another transparently using a new programming problem. A Web service is a program delivered over the In- model called transparent shaping. Although originally in- ternet that provides a service described in the Web Service tended to enable dynamic adaptation in existing programs, Description Language (WSDL) [7] and communicates with transparent shaping mechanisms provide an effective solu- other programs using the SOAP messages [18]. WSDL and tion to the application integration problem. A case study SOAP are both independent of specific platforms, program- demonstrates the use of transparent shaping to integrate ming languages, and middleware technologies. Moreover, 1 CORBA and .NET applications. SOAP leverages the optional use of HTTP protocol , which allows bypassing firewalls, thereby enabling Internet scala- bility in application integration. Although Web services have been successfully used to 1. Introduction integrate applications, they do not provide a transparent so- lution to integrate existing applications. The challenge is to To integrate heterogeneous applications, possibly devel- integrate existing applications without the need to modify oped in different programming languages and targeted to their source code directly. In this paper, we show how trans- run on different platforms, we need to convert data and parent shaping can be used to support transparent applica- commands between the applications on an ongoing basis. tion integration. Transparent shaping is a new programming The advent of middleware in the 1990’s – which hides dif- model, which was originally intended to enable dynamic ferences among programming languages, computing plat- adaptation in existing programs. Transparent shaping mech- forms, and network protocols [2, 5, 13] – mitigated the dif- anisms provide an effective solution to the application inte- ficulty of application integration. The maturity of middle- gration problem. ware technologies resulted in several successful approaches to enterprise-wide application integration [17, 35], where applications developed and managed by the same enterprise 1 The hyper text transport protocol that is used to request and transmit are able to interoperate with one another. files over the Internet or an Intranet. The rest of this paper is organized as follows. Section 2 Requester Program Provider Program provides background on web services. Section 3 introduces Application Layer Requester Provider application integration through Web services. Section 4 Component Component overviews transparent shaping mechanisms and describes Middleware WSDL WSDL how they can be used to enable transparency in application Layer SOAP SOAP integration. Section 5 presents a case study, where we use System Network the transparent shaping mechanisms to integrate two exist- Platform ing applications, one developed in CORBA and the other in process boundaries the .NET platform. Finally, Section 6 discusses related work Program component Flow of service request A2A Interaction and Section 7 summarizes this paper. Figure 1: A simplified Web service architecture. 2. Web Services Background change among interacting parties. As a result, SOAP can be used as a layer of abstraction on top of other middleware A service-oriented architecture, as depicted in Figure 1, technologies; essentially providing a “middleware for mid- is composed of at least a provider program, which is a pro- dleware.” gram capable of performing the actions associated with a A SOAP message is an XML document with one ele- service defined in a service description, and a requester pro- ment, called an envelope, and two children elements, called gram, which is a program capable of using the service pro- header and body. The contents of header and body elements 2 vided by a service provider. In this model, we assume that are arbitrary XML. Figure 2 shows the structure of a SOAP a program is executed inside a process, with a boundary dis- message. The header is an optional element, whereas the tinguishing local and remote interactions, and is composed body is not optional and there must be exactly one body of a number of software components, which are units of defined in each SOAP message. To provide the developers 3 software composition hosted inside a program process . A with the convenience of a procedure-call abstraction, a pair component implementing a service is called a provider com- of related SOAP messages can be used to realize a request ponent and a component requesting a service is called a re- and its corresponding response. SOAP messaging is asyn- quester component. chronous, that is, after sending a request message, the ser- Figure 1 also shows that the application-to-application vice requester will not be blocked waiting for the response (A2A) interaction is accomplished through the use of a mid- message to arrive. For more information about details of dleware technology over a network. The network can be the SOAP messages, please refer to [4, 10, 18]. Internet, an Intranet, or simply an inter-process communi- cation (IPC). In the case of Web services, the middleware is composed of two layers: a SOAP messaging layer governed 1 ≺?xml version=“1.0” encoding=“UTF-8” ? by a WSDL layer (described below). Web services are soft- 2 ≺soap:Envelope xmlns:soap= 3 “http://schemas.xmlsoap.org/soap/envelope/ . ware programs delivered over the Internet that are accessi- 4 ≺soap:Header ble by other programs using the service descriptor of the 5 ≺!– Header contents in defined in arbitrary XML. – Web service defined in WSDL and through the SOAP mes- 6 ≺/soap:Header 7 ≺soap:Body saging protocol. 8 ≺!– Body contents in defined in arbitrary XML. – 9 ≺/soap:Body SOAP. SOAP [18] is an XML-based messaging proto- 10 ≺/soap:Envelope col independent of specific platforms, programming lan- guages, middleware technologies, and transport protocols. SOAP messages are used for interactions among Web ser- Figure 2: SOAP message structure. vice providers and requesters. Unlike object-oriented mid- dleware such as CORBA, which requires an object-oriented model of interaction, SOAP provides a simple message ex- WSDL. Web Services Description Language (WSDL) [7,8] is an XML-based language for describing valid message ex- changes among service requesters and providers. The SOAP 2 We use the terms “provider program” and “requester program” in- stead of the terms “provider agent” and “requester agent” used in [3] messaging protocol provides only basic communication and to avoid the confusion with agents in agent-based systems. does not describe what pattern of message exchanges are re- 3 The example programs provided in this paper are all developed in quired to be followed by service requesters and providers to object-oriented languages. For simplicity, the terms component and perform a successful interaction. WSDL addresses this is- object have been used interchangeably. However, this does not im- ply that a service-oriented system must be either implemented us- sue by describing an interface to a Web service and pro- ing object-oriented languages or designed using an object-oriented viding the convenience of remote procedure calls (or even paradigm. more complicated interactions such as back-and-forth in- teractions). For more information about details of WSDL, The single-point-of-failure and the bottleneck problem are please refer to [7, 8, 10]. other disadvantages of this approach. Shaping the requester and provider programs. To avoid 3. Application Integration using Web Services the overhead of the extra level of process-to-process