Web Services: A Bridge between CORBA and DCOM

Transcription

1 Web Services: A Bridge between and DCOM Mohammed Mohsen AL-Khawlani Abstract In today s market, there are many distributed systems technologies and each technology has its own strengths and weaknesses. Each technology may work better than the others under some circumstances and it will work worse than the other technologies under other circumstances. Hence most of these technologies will survive, and new mechanisms should take place to allow the different technologies to work together. This paper provides a comprehensive comparison between the three most common distributed systems technologies, DCOM, and Web Services; it introduces the /DCOM interoperability problem, explains the OMG s specification to solve the problem, and outlines the existing methods for bridging and DCOM and their abilities and limitations. It explains why and how Web Services can be used to solve the /DCOM interoperability problem and demonstrates that by implementing a simple /DCOM bridge using the Web Services techniques SOAP, WDSL and UDDI. 1. Introduction In today s market, there are several distributed system technologies. The two most popular, widely accepted and implemented are the Common Object Request Broker Architecture () by the Object Management Group (OMG) and the Distributed Component Object Model (DCOM) by Microsoft. Recently, the Web Services technology promises to overcome the limitations, complexity and interoperability problems of and DCOM. It takes the strengths of the existing component based technologies and the Web. Although the three technologies do the same work and all of them manage the communication between the clients and the remote server objects through a well-defined interface, every technology has its own architecture, strengths and weaknesses. Each technology will be more suitable for some environments and for some business and technical reasons than the other technologies. Because each technology has its own underlying components, which are incompatible with the components from the other technologies and many interoperability problems appear when a developer attempts to mix them in one enterprise. Due to the unique characteristics, the ease of use and implementation of the Web Services technology, it can be used as integration technology between the other technologies. This paper argues and supports that by implementing a simple /DCOM bridge using the Web Services techniques SOAP, WSDL, and UDDI. 2. / DCOM Bridging Overview 2.1 A Comprehensive Comparison on, DCOM and Web Services Table (1): compares the basic characteristics of, DCOM and Web Services technologies. Table (1): The basic differences of, DCOM and Web Services Characteristics DCOM Web Services Support and Development Organization Object Management Group (OMG) Microsoft SOAP and WSDL specification from World Wide Web Consortium(W3C) Department of Electronical and Computer Engineering, Faculty of Science and Engineering, University of Science and Technology Sana'a, Republic of Yemen.

2 Characteristics DCOM Web Services Specification Specification Implementation/specification Specification Mainly Windows, but it can Platform- Platform Support support other platforms with Platform independent Independent some efforts Data model Client-Server coupling Language Support Wire Protocol Object Oriented model Object Oriented Model message exchange model Tight-Coupling Tight-Coupling Loose -coupling any language with an IDL binding Internet Inter- ORB Protocol (IIOP) any language with an IDL binding Object Remote Procedure Call (ORPC) any language SOAP and Hyper Transfer Text Protocol (HTTP) Internet friendly No No Yes Table (2) compares the architectural and programming characteristics of, DCOM, and Web Services technologies. Table (2): The core differences of, DCOM and Web Services Characteristic DCOM Web Services Interface Definition IDL MIDL WSDL Server-side stub Skeleton Stub Stub Client-side stub Stub Proxy Proxy Object class and interface Identification Object References Dynamic Invocation Activate the object Implementation locating an object implementation Object Storage Type information for methods Format for payload On demand code shipping Error Handling Firewall traversal Identification through Object and Interface Names. Reference through an Object Reference (OR) Dynamic Interface Invocation (DII) By an Object Adapter (OA) Identification through objects and interface IDs. GUID and CLSID. Reference through an Interface Pointer (IP) Dispatch interface By a Service Control Manager (SCM). WSDL Reference through an Uniform Resource Locator (URL) UDDI/WSDL UDDI ORB SCM UDDI Implementation Repository Interface Repository The binary format Common Data Representation (CDR) Registry Type library The binary format :Network Data Representation (NDR) UDDI Repository UDDI/WSDL The Unicode format (SOAP) No Yea,as ActiveX Controls No IDL exception not firewall friendly HRESULT or Error Objects (of type IErrorInfo) not firewall friendly SOAP fault messages firewall friendly

3 2.2 The Needs for Bridging and DCOM Both and DCOM share many characteristics and both of them allow clients to invoke remote objects as if they were local. However, the underlying components, object identification method, object storage, and protocols are incompatible. The similarities disappear when a developer attempts to mix both technologies in one application. 2.3 OMG s COM/ Interworking Specification The OMG understood the needs for bridging and DCOM and decided to include the Interworking Architecture, which is the specification for bridging the two technologies as a part of the specification. The specification for bridging COM and is called part A of the Interworking Architecture and the extension of this specification for bridging DCOM and is called part B. According to [1] and [2] the Interworking Architecture steps can be summarize as follows. 1. Interface Mapping: both technologies use IDLs to define the objects interface by which the objects can be exposed. For a object to be viewed as a DCOM object and vice versa there must be a mapping between their interfaces. 2. Interface Composition Mapping: While supports single interface with multiple inheritance, DCOM supports multiple interfaces with single inheritance. For successful /DCOM bridging there must be a mapping between the two mechanisms 3. Identity Mapping: While uses the interface name to identify the object, DCOM uses a global unique ID (GUID). Hence, the mapping between the different Interface IDs that are used by and DCOM is required. According to (part B) [3] of the OMG s COM/ Interworking specification the / DCOM bridge can be like what is shown in figure (1) below. On the left side of the figure, a DCOM client wants to send a request to a target object on the right side. On the right side a client wants to send a request to a DCOM target object on the left side. The goal of the /DCOM bridge is to map and deliver any request from the client transparently to the target. To achieve this goal, an object in each side called a View is provided. The View is an object on each side that presents the identity and interface of the target on the other side. COM Client DCOM COM View Object ORB Target Object COM Target Object View Object Client Fig. (1) Bridging /DCOM The View in system exposes an interface, called the View Interface, which is isomorphic to the target s interface in the DCOM system. The methods of the View Interface convert requests from the clients into requests on the target s interface in the DCOM system. The View is a component of the bridge and the bridge may be composed of many Views. Part A and Part B of OMG s COM/ Interworking Architecture specify six configurations of the bridge, as shown in Figure (2) below.

4 Client Side Intermediate Machine Server Side COM Bridge Bridge COM DCOM Bridge DCOM Bridge Bridge DCOM Bridge DCOM Fig. (2) /DCOM interworking configuration models Figure (2) above shows that the /DCOM bridge can be local (the modes1, 2, 3, 5) or remote (the modes 4, 6). While the local bridge uses and extends the existed ORB in the local machine to connect the and DCOM objects, the remote bridge enables the connection between the and DCOM objects through separate machine that executes the bridge components. The first and second modes in figure (2) are for bridging and COM and the rest of the modes are for bridging and DCOM. 2.4 The Existing /DCOM Bridges The OMG provides a specification for and DCOM bridging, but it does not provide any implementation. Different companies have provided many bridge implementations, which are supposed to be compliant with OMG s specification. Some of these commercial products are OrbixCOMet from IONA Technology [4], ObjectBridge from Actional Corporation [5], and COM2 from PeerLogic [6]. Although those bridges performed reasonably well for most of the six possible configurations, they are suffering from the following problems: 1. Their functionality and performance still limited. 2. Some of them are not bi-directional and can only map the objects to the COM/DCOM objects, or vice versa. 3. Some of them satisfy part A of the OMG s specification only and they don't support the interworking between the objects and DCOM objects. 4. All of them add overhead processing time. This overhead is unreasonable and unacceptable for the complex and real-time applications. 5. All the bridges are not Internet friendly. 6. All of them impact the performance of DCOM and application.this is due to the additional complexity that results from the complete two-way translation from Internet Inter-ORB Protocol (IIOP) to DCOM Object Remote Procedure Call (ORPC) 7. Any changes to s IIOP or DCOM s protocols will affect the bridges.

5 2.5 Why Web Services can solve the Problem? Web Services technology can be used to integrate the existing distributed technologies like and DCOM. This role can be argued by considering the following arguments: 1. The Nature of Web Services (XML, SOAP and HTTP based): while XML provides a platform and language independent mechanism for data encoding and formatting, SOAP defines a simple way to format and bundle the information for exchange across the distributed computing environments. SOAP works above HTTP protocol to define a platform and language independent way to make remote procedure calls between systems. Hence, if XML and SOAP work together, the problem of making systems at two companies compatible with each other will be solved and the integration and interoperability problems can be simplified in layers. [7] 2. Web Services Support: Web Services technology has unprecedented industry backing. All the major computing companies and organizations provide fully support and endorse to the specification, implementation and developing of SOAP and WSDL. "The industry remains unfragmented with respect to these efforts, something that never happened for COM/DCOM, or any other distributed computing technologies. This fact puts it into the front when it comes to being able to integrate the other technologies " [8]. 3. Technologies Integration, not Replacement:, DCOM and the other technologies have proven their ability to provide high performance, dependability, and scalability solutions for a variety of distributed computing problems. Hence, the coming role of Web Services technology should be the integration for these mature technologies and not to replace them [8]. 2.6 How Web Services can solve the Problem? As described in section 2.5 above, Web Services are more likely to be the most suitable way to integrate the existing distributed computing technologies. The direct way to do that is by exposing the other technologies applications as Web Services. There are two levels where the other technologies objects can be exposed as Web Services, the first is at the binary level and the second is at the source code level Bridging and DCOM with Web Services at the Source Code Level This is not a trivial process, for example, directly exposing a object requires that the Naming service where it's registered also be exposed as a Web Service, and a client of such a Web Service must know enough about Naming to be able to navigate it and find its target service. Protocol translator, gateway, should take place to be responsible for translating SOAP data into data and translating the object's IDL definition into WSDL. This gateway should also be responsible for mapping IIOP/GIOP messages to SOAP requests and responses. The role of the gateway is to receive the SOAP requests from the Web client, forward them to the required object as request, and return the result to the client as a SOAP response. According to [9] the steps that are involved in the processing of the client request are as follows. 1. The gateway receives the client SOAP request. 2. The gateway extracts the WSDL description from the SOAP request. 3. The gateway extracts the IDL description of the required object. 4. The gateway builds A dynamic request and send it to the object 5. The gateway builds a SOAP response out of the response.

6 Figure (3) shows how objects can be exposed to web clients. Fig. (3) objects exposed as Web Services. [9] To bridge and DCOM with Web Services at the source code, the developer needs to understand the three technologies at the same time. This type of integration will be harder if the applications are not open source or if they are coming from third party. Figure (4) shows a proposed /DCOM bridge using Web Services at the source code level. Web Service Client SOAP/HTT IIOP to SOAP Mapping CDR/IIOP Object IDL UDDI Repository IDL to WSDL Mapping Web Service Client SOAP/HTT ORPC to SOAP Mapping NDR/ORPC DCOM Object IDL Fig. (4) /DCOM Bridge using Web Services at the source code level Bridging and DCOM with Web Services at the Binary Level Bridging at binary level does not require any mapping between the different protocols of the different technologies. Basic structure for the binary level bridge can be shown in figure (5). Application Web Service Client UDDI Repository Web Services to wrap DCOM and Binaries Fig. (5) Bridging and DCOM with Web Services at the binary level DCOM Application

7 The main benefits of this type of bridging can be summarized as follows: 1. Delivers fast, easy application integration. 2. No changes to applications or the way users typically access their data. 3. Even if the applications are not open source or they are from a third party, they can be integrated rapidly and cost-effectively. 4. The additional complexity and overhead that results from the complete translation between the different protocols will be eliminated. 5. Any changes to s IIOP or DCOM s ORPC protocols will not affect the bridges. 3. The Implementation of a /DCOM Bridge with Web Services It has been discussed in section 2.5 and section 2.6 that the Web Services technology is complementary to distributed technologies such as and DCOM and it will not replace them. In addition, Web Services can give a simple and Web-friendly way to integrate and DCOM. This part will extend that discussion by implementing an application that demonstrates how Web Services can be used for bridging the gap between and DCOM. Bridging and DCOM using Web Services can be implemented in two levels. The first level is at a binary level, which means that the pre-compiled and pre-built and DCOM objects will be exposed as Web Services.The other level is at a source code level, which means that the mapping between the different technologies protocols is required. This part implements a /DCOM bridge at the binary level. 3.1 The Implementation Steps of a /DCOM Bridge with Web Services at a Binary Level To implement a /DCOM bridge at the binary level, the following programs have been implemented. 1. A client/server application in which the object has two methods. 2. A DCOM client/server application in which the DCOM object has two methods. 3. A Web Service that invokes the and DCOM methods. 4. A UDDI registry to publish the Web Services object. 5. A Web Services client The Implementation of the Application Figure (6) shows that the object SIDE has two methods which are: 1. public double get_triang_area( float a, float b, float c) that calculates the area of a triangular according to the equation area = s * (s-a) * (s-b)* (s-c) where a, b and c are the lengths of the triangular sides and s = 0.5 * a * b * c 2. public String get_opposite_cases (String inputstr) that takes a string in the lower case from a text input file, produces the same string in the upper case as output, and writes it to a text file.

8 Fig. (6) The object implementation. The client initializes the ORB by making a call to ORB.init (). Then it gets the root naming context by using NamingContextExt. After that, it resolves the object reference in naming. Finally it gives the user to choose one of the available methods. Depending on the user choice it invokes the suitable method from the server object. Figure (7) shows the client implementation. Fig. (7) The client implementation The Implementation of the DCOM Application Figure (8) shows that the DCOM object has two methods which are: 1. public float get_circle_area(float radius) that calculates the circle area.it takes the radius as input and return the area as output. 2. public String get_reverse (String orgstring) that takes a string from a text input file, produces the reverse order of the string as output,and write it to a text file.

9 Fig. (8) The DCOM object implementation. The DCOM client gives the user the ability to choose the method that is needed. As soon as one method is chosen, the client acquires a pointer DCOMSide to the IDCOMDIDE object's interface, then it starts calling the object's method through the interface pointer as if the object is local Exposing DCOM and Objects as Web Services To expose the DCOM and objects as Web Services, the exec () method of the Java Runtime class is used in the Web Services object. In order to do that a new process object is instantiated and is used to execute the specified command in the Web Services client. The Bridge Web Service Java code can be shown in figure (9) Fig. (9) The Bridge Service implementation. The Bridge Service WSDL is shown in figure (10). The WSDL file contains six major elements: 1. Definitions: define the name of the web service server.bridge, and declare multiple namespaces. 2. Types: describe all the data types that will be exchanged between the client and the service. server.bridge service uses only the XML Schema built-in simple type string. The service has one string variable p0. 3. Message: describes two one-way messages. The first is a single message request with the name Bridge_get_bridge_1_Request and contains one part called p0.the second is a single message response with the name Bridge_get_bridge_Response. 4. PortType: defines the above two one-way messages that are combined to form a complete round-trip operation called get_bridge.

10 5. Binding: provides specific details on how the defined porttype operation get_bridge will actually be transmitted. 6. Service: defines the URL address for invoking the specified service. 7. <soap: address location=" /> Fig. (10) The Bridge Service WSDL definition The Implementation of the Web Service Client The client class must import the package org.systinet.wasp.webservice.registry which allows runtime publishing and finding of Web Services. This package provides the simplest way of service lookup by creating dynamic proxy bridge for the service Bridge which is located on the location serverurl + servicewsdlpath. The serverurl variable can be returned as a string by using the System.getProperty method. By using the dynamic proxy bridge the client can invoke the method get_bridge and the suitable command is passed as input to the method. The Web Services client has three options. The first option is to directly expose the DCOM methods. The second option is to directly expose the methods. The last option invokes the DCOM get_reverse method to get the reverse order of the input string that is read from a text file, then the result is passed to the get_opposite_cases method to get its opposite case, and finally the final result is returned to the Web Services client in a file. Fig. (11) The Bridge Web Services client implementation.

11 4. System Testing and Results 4.1 System Requirement A computer running the Microsoft Windows 2K. Systinet WASP Server 4.51 for Java. Sun Java Platform J2SDK Microsoft Visual J to build the application. However, there is no need for Visual J++ if the exe files from previous build will be used. 4.2 Running the Application and Sample Results 1. Run WASP Server for Java, 4.51 by running the serverstart.bat file on the bin directory of the WASP package. Fig. (12) Run the WASP for Java server 2. Run the Bridge Web Service client by using the command run run_client.this gives the three options that are shown in figure (13). Fig. (13) Run the Bridge Web Service client options 3. To expose the DCOM methods the first option will be chosen Fig. (14) Invoke the DCOM get_cricle_area method by the Web Service client

12 4. To expose the methods the second option will be chosen Fig. (15) Invoke the get_traing_area method by the Web Service client 5. Choosing the third option gives the following results Fig. (16) Invoke the option 3 of the application by the Web client.

13 5. Conclusions This paper has achieved the following objectives. 1. Distributed computing technologies such as, DCOM and Web Services are complementary and each technology has its own strengths and weaknesses. By working together, distributed computing technologies can solve problems that cannot be solved with a single technology. 2., DCOM, and Web Services technologies will survive, and the need for new mechanisms that allow them to work together is necessary. 3. While is the most mature technology to integrate legacy systems and heterogeneous networks, DCOM is the most suitable technology for Windows-based networks. 4. Compared with and DCOM, Web Services is still less powerful but it is more impressive in its simplicity and extensibility. Also Web Services have huge industry backing, which did not happen to any other technology before. 5. Web Services technology is still immature, and their specifications are still under working, but the main principles behind them are stable. 6. The implementation processes for client/server applications with the three technologies are nearly the same.the most important part in developing these applications is how to define a suitable interface for the object. 7. Although the current /DCOM bridges try to fill the gap between the two technologies, they are not good enough to provide a true bi-directional communication between and DCOM objects. Until now the use of a single technology is more reliable, stable and better than using both technologies in one application. 8. The main strength of Web Services lies on its ability to integrate the existing distributed applications, which are based on and DCOM. For Web Services it is better to work as integration and bridging technology rather than working to replace the mature and powerful technologies and DCOM. 9. At the moment the Web Services can provide the basic level of connectivity between different technologies easily, however for full connectivity some real challenges remain due to the incompatibility between the underlying services of the different technologies. 10. Web Services can be used for bridging and DCOM at two levels, the binary level and the source code level. Bridging at the binary level is useful in many cases and it is easy to implement.however, this does not eliminate the need for bridging at the source code level. 11. At binary level bridging, even if the applications are not open source or they are from third party, they can be integrated rapidly and cost-effectively. 12. Many organizations and commercial companies understand the role of Web Services in integrating the other distributed computing technologies and start to release advanced Web Services platforms that provide the required mapping between, DCOM, and Java RMI and Web Services.

14 6. Future Work The work in this paper can be extended and developed in the following areas: 1. Because the implemented bridge was at the binary level of legacy and DCOM applications, the next step is to build the bridge at the source code level where the mappings from IDL to WSDL and from IIOP/ORPC to SOAP are needed. 2. The methods in the object and DCOM component that were published as Web Services in this paper are simple methods and all of them use basic data types. Methods that use more complex date type like array of arrays and array of structures can be used in the future work. 3. The discussion about the similarities and differences between, DCOM and Web Services technologies can be extended to cover all the possible aspects. 4. More investigation and tests can be done to evaluate the existing /DCOM bridges. 7. References [1] K. Raptis, D. Spinellis and S. Katsikas, Java as Distributed Object Glue, University of the Aegean, August 2000, [2] OMG, COM- Interworking Part A, OMG TC Document ORB/ , January 1996 [3] OMG, COM/ Interworking Part B, OMG TC Document orbos/ September 1997 [4] IONA Technology, OrbixCOMet, [5] Actional Corporation, ObjectBridge, [6] PeerLogic, Inc., COM2, [7] Microsoft Corporation, UDDI Technical White Paper, September 2000 [8] Douglas C. Schmidt and Steve Vinoski, Object Interconnections: and XML: SOAP and Web Services, C/C++ users Journal C++ Experts Forum, October 2001, [9] A. Gokhale, B. Kumar and A. Sahuguet, Reinventing the Wheel. vs. Web Services, Bell Labs and Lucent Technologies, June 2002