WEB Service Interoperability Analysis and Introduction of a Design Method to reduce non Interoperability Effects

Size: px

Start display at page:

Download "WEB Service Interoperability Analysis and Introduction of a Design Method to reduce non Interoperability Effects"

Paul Walker
6 years ago
Views:

AmirHasan Darvishan CT Department, IRAN Telecommunication Research Center, Tehran, IRAN Summary WEB service is a new phenomenon in distributed applications.

1 IJCSNS International Journal of Computer Science and Network Security, VOL.8 No.9, September WEB Service Interoperability Analysis and Introduction of a Design Method to reduce non Interoperability Effects Nasrin HezareMoghadam,Masoumeh Khoshbakhtian, Hassan Yeganeh, AmirHasan Darvishan CT Department, IRAN Telecommunication Research Center, Tehran, IRAN Summary WEB service is a new phenomenon in distributed applications. In addition to IT region, it is also gradually used in communication applications like service creation in Next Generation Networks (NGN). Appropriate interoperability between different elements of WEB service in various software platforms is one of the WEB service problems; which means the existence of interoperability between Server and Client when their codes are implemented in different executive environments. In this paper some problems related to interoperability of various WEB service platforms are reviewed. Moreover; new solutions are proposed to reduce interoperability problems, based on "Contract-First" design method and WS-I tests. 1. Introduction Before current internet development, concept of distributed softwares was limitedly used in application implementation. Due to TCP/IP development and networks globalization, distributed services in different servers can be used via internet. Hence, producing concept of distributed application, with the purpose of utilizing current codes and services, and also simultaneously executing of services in various servers, has been developed more than before. The WEB service description by Universal Description, Discovery and Integration (UDDI) consortium is: WEB service contains Independent and Modular applications with openstandard interfaces in internet. It includes collaboration among distributed software agents in various internet servers to provide a special application. Connection of agents is through XML-based messages. In recent years, several methods have been designed for distributed softwares, such as CORBA and JAVA RMI servers which include multiple software complexities and are suitable just for professional programmers. The latest innovated method in this regard is the WEB service which has increasing popularity because of its perfect compatibility with internet and also using of common internet protocols. Hence, many large companies like Microsoft and IBM have produced platforms in order to provide and execute WEB service applications. By these platforms, WEB service use is as simple as a connection to the internet. However, various platforms for WEB service applications cause interoperability problems between Servers and Clients; of course when they use different platforms. On the other hand, implemented language and code of Server or Client are dependent on properties of used platform. In this paper, problems existing in interoperability of WEB service platforms, are considered when a.net Client and a J2EE Server are used. Moreover, different WEB service designs are considered and some suggestions are presented in order to solve interoperability problem. 2. WEB Service Technology Figure 1 shows WEB service architecture. Figure 1: web service architecture In this architecture 3 important parts are described, i.e. WEB Service Producer (WEB-SP), WEB Service Consumer (WEB-SC), and UDDI Registry (UDDI-R). WEB-SP implements a service and presents it via an internet WEB. WEB-SC uses presented service as a Client. UDDI-R acts as a Data Base and contains service identification data in internet. First, in WEB service application mechanism, WEB-SP registers its service in UDDI-R. The service registration includes location information data, behavioral and parametric properties of service (Step 1). WEB-SC looks for its desire application Manuscript received September 5, Manuscript revised September 20, 2008.

150 IJCSNS International Journal of Computer Science and Network Security, VOL.8 No.9, September 2008 in UDDI-R and receives its data from Data Base (Step 2).

A) contract-first design method b) code-first design method Figure 3: web service design methods 2.1.

XML Messaging layer which performs Encoding and Decoding in XML format by means of SOAP protocol. This protocol defines a standard between WEB-SP and WEB-SC to transmit XML data in the network.

2 150 IJCSNS International Journal of Computer Science and Network Security, VOL.8 No.9, September 2008 in UDDI-R and receives its data from Data Base (Step 2). By this data, WEB-SC makes contact with WEB-SP and calls for the mentioned service from WEB-SP (Step 3) [1], [2]. Figure 2 illustrates protocol stack, used in WEB service [3], [4]. A) contract-first design method b) code-first design method Figure 3: web service design methods Contract-First Method Figure 2: web service protocol stack This protocol stack has four layers: Service Transport Layer which usually handles the sending/receiving of messages typically over HTTP. XML Messaging layer which performs Encoding and Decoding in XML format by means of SOAP protocol. This protocol defines a standard between WEB-SP and WEB-SC to transmit XML data in the network. Service Description Layer which specifies the interface of the web service to the end user, usually handled by WSDL. WSDL is a XML format standard for description of the structures of SOAP messages and its documents Service Discovery Layer which uses UDDI directory, a standard for storage and retrieval of related data to WEB services. In using of WEB services, WEB-SP implements its desired service with any language in any executive platform. Then WEB-SP stores its WSDL description (WSDL file) in UDDI-R which is available in numerous sites, such as Microsoft site. Furthermore, WEB-SC or Client receives WSDL file of its desire service by referring to UDDI stations and finding that service. Subsequently, it communicates with WEB-SP through its executive platform and uses the requested service WEB Service Design Method There are essentially two ways of designing web services, the contract-first and the code-first way. These two methods are shown in figure 3. The first step in this method is to define different SOAP messages, that should be used, in other words specify a WSDL file. The next step is to be certain that Server and Client generate accurate SOAP messages based on WSDL file. In this method, "Stub Codes" of Server and Client are automatically generated from WSDL file. "Contract-First" method has high interoperability level, since both Server and Client use the same reference which is WSDL file Code-First Method The first step in this method is to design WEB service code and its interface. Then WSDL file is generated from this code. In this method designer has no control on SOAP messages. Client codes could be written from scratch; but generation of correct SOAP messages has low chance in this situation. The better procedure is to generate "Client Stub" immediately from WSDL file. However, "Code-First" method generally makes more interoperability problems in comparison with "Contract- First" method. Regardless of type of design method, Server and Client must understand each other. As it is shown in the next section, "Contract-First" method improves the interoperability level, while the latter increases the productivity Interoperability Problems in WEB Service As mentioned in section 2, WEB-SP and WEB-SC are enabled to employ any desired platform, where this variety may cause interoperability problems in WEB service applications. One of the most common problems in both methods of WEB service design is that the generated code in Server/Client is unable to understand and manage exceptions. Therefore, by an exception taking place program would halt. Although error management in WEB service is approximately similar to that of other programs like JAVA, exception

3 IJCSNS International Journal of Computer Science and Network Security, VOL.8 No.9, September management is more difficult due to transparency of SOAP messages. For example suppose an error occurring in server. In this situation a "SOAP Fault Message" is sent to the Client. If Client application cannot parse and understand this error message, application is ended because of unhandable exception. This problem mostly happens when multi-vendor Client and Server are used; for example Server uses J2EE platform and Client uses.net. To solve the problem a "custom SOAP Message Parser" is required which must parse "Detail Field" in received SOAP message and generate a proper exception. "Detail field" in SOAP fault messages contains adequate information about occurred fault. In this case, client receives a correct exception and processes it properly. the interoperability problem in contract-first method is only this SOAP fault problem. Because in this method WSDL files are validated, then Server and Client codes are generated from these files. "Code-First" method has additional problems, since Server and Client codes are generated in a different manner. One of the most important problems is "Encoding Style", depending on the structure of the SOAP messages and encoding. As an example, "Missing Array Structure" fault may occur in which generated code for Client is unable to parse the received data properly. Another problem is the conversion of various types of data to each other. There is no "One-to-One" map for different types of data. Although WEB service design is independent of software/hardware, some interoperability problems may appear especially when multi-vendor Server and Client are used. To solve these problems, WS-I (institute established by renowned companies like Microsoft and IBM) provides a standard named "Basic Profile that proposed Solutions to Decrease WEB Service Interoperability Problems. In this paper different WEB service design methods are compared in terms of interoperability. Based on the results, a proper design method and some solutions to reduce interoperability problems are suggested. 3. comparison/analysis In this section WS-I tools are employed in order to compare various design methods in terms of interoperability and present appropriate solutions. The purpose of WS-I is to discover interoperability problems and provide new solutions to prevent them. For this purpose, some factors are defined by this institute: Basic Profile: defines protocols, versions, and recommendations which must be considered in WEB service interoperability. Samples: indicate interoperability problems, taking place in different platforms of WEB service Guidelines: include implementation scenarios and conditions, making problems. Test Tools: contain a set of test tools which facilitate validation according to "Basic Profile", since handy validation of a WEB service is too time-consuming [5]. In fact validation of a WEB service is the test of WEB service requirements in order to prevent interoperability problems, where this test is on the basis of "Basic Profile". For this purpose WS-I has defined a series of test tools, divided into two groups of "Monitor" and "Analyzer". In "Monitor", transmitted messages between Server and Client are monitored saved in a "Log File". "Monitor" acts as a proxy for SOAP messages and the all communication traffic between Server and Client passes through "Monitor". So, user must reconfigure the application in a manner that all SOAP messages are sent to the "Monitor" address. In "Analyzer", "Log File" which is generated by "Monitor", is analyzed by WSDL in order to indicate whether WEB service may perform in compatible with WS-I Basic Profile standard or not. "Analyzer" output is a "Conformance Report" which describes WEB service compatibility with "Basic Profile". In case of having a failed validation, a "Detailed Description" illustrates which test is unsuccessful in "basic Profile". On the other hand, "Detailed Description" shows which recommendations are not observed in these unsuccessful tests. In a perfect validation of a WEB service, its WSDL file must be firstly validated based on "Basic Profile" standard. The next step is to validate SOAP messages, stored in "Log File", based on WSDL file and "Basic Profile" [6]. To have a better comparison between "Contract-First" and "Code-First" methods in terms of interoperability, both of them are tested by WS-I test tools; while Client and Server use.net and J2EE platforms, respectively. 3.1 Test Assumptions A simple WEB service is considered for the test, in which a Client with.net platform and a Server with J2EE platform are connected to do SMS application. This application includes capabilities of "SMS transmission" and "delivery status reception" by the Client. In this service, Client and Server have unidirectional connection. This simple WEB service is designed with both "Code-First" and "Contract-First" methods and these two methods test results will be presented in the next sections. 3.2 "Contract-First" Test Results Since WSDL files are predefined in "Contract-First" method, validation of them is expectedly successful.

4 152 IJCSNS International Journal of Computer Science and Network Security, VOL.8 No.9, September 2008 Therefore, it is possible to compare SOAP messages with WSDL files, based on "Basic Profile". Some of these messages which are stored in "Log File" have failed validation. "Conformance Report" indicates which of the "Basic Profile" requirements is not considered in these failed tests. This report is shown below: WS11011-failed Result failed Assertion Description The content of the message matches the definition in the WSDL document. In case of a doc-lit binding, the child element of soap:body is an instance of the global element declaration referenced by the corresponding wsdl:part. If the message has parts, the order of the part elements in the soap:body of the wired messages, is same as that of the wsdl:parts in the corresponding wsdl:message. Failure message the content of the request message did not match the wsdl:message definition. The order of parts in soap:body does not match the order of wsdl:parts in wsdl:message, or the child element of soap:body is not an instance of the global element declaration referenced by the corresponding wsdl:part. Failure Detail Message Message validation failed WS11013-failed Result failed. Assertion Description The content of the message matches the definition in the WSDL document. In case of an rpc-lit binding, the body contains a wrapper element that matches theoperation name. in case of a doc-lit binding, the child element of soap:body is an instance of the global element declaration referenced by the corresponding wsdl: message. Failure Message the content of the response message did not match the wsdl:message definition. The order of parts in soap:body does match the order of wsdl:parts in wsdl: message, or it has a doc-lit binding but the child element of soap: body is not an instance of the global element declaration referenced by the corresponding wsdl: part, or it has an rpc-lit binding but no wrapper element. Failure Detail Message could not validate message. This report shows R2712 and R2301 recommendations of "Basic Profile" are not supported in these invalidated messages. These recommendations are about the arrangement of elements in "soap: body" of SOAP messages. Based on these recommendations, these arrangements must be equal to that which is defined in "soap:bodys" in WSDL file. While this recommendation neither in request messages, sent by Client, nor in response messages, sent by Server, is considered. These recommendations are shown below: R2301- the order of the elements in the soap:body of an ENVELOPE must be the same as that of the wsdl:parts in the wsdl:message that describes it. R2712- A document-literal binding must be serialized as an ENVELOPE with soap: body whose child element is an instance of the global element declaration referenced by the corresponding wsdl: message part. Since in this method "Stub Codes" of Server and Client are generated from WSDL file, they have proper interoperability with each others. Results show this test has negligible errors. 3.3"Code-First" Test Results In this method, WSDL files are not validated and scheme validation is failed. Failing in validation of scheme which is the most important part of a WSDL files causes failure in many tests. Due to failing in validation of all WSDL files, validation of SOAP messages is not necessary. On the other hand, the comparison of SOAP messages with definitions available in an incorrect WSDL file is not possible. As a result, WSDL files of this method which are generated from WEB service code are not standard and must not be used in a WEB service. 4 proposed Solutions According to the above tests, we suggest solutions to decrease interoperability problems: 1. "Contract-First" method would be used in WEB service design. It means design would be started with definition of required SOAP messages or WSDL file. 2. Only simple data structure which has "One-to- One" map in all environments could be used in data transmission. Obviously, processing of complex data structures may be difficult for receiver and may cause some interoperability problems. 3. WSDL file would be validated based on WS-I "Basic Profile". This may solve most of the interoperability problems. On the other hand, it would better to be certain about validation of WSDL files firstly, and then compare SOAP messages with these files. 4. Server and Client codes would be generated based on WSDL file. 5. SOAP traffic is validated on the basis of WSDL file and WS-I "Basic Profile". "Monitor" must be used in order to save messages in a "Log

If SOAP messages are incorrect and have failed verification, the causes lead to errors could be discovered by detailed description in "Conformance Report".

5 IJCSNS International Journal of Computer Science and Network Security, VOL.8 No.9, September File", and then these messages must be compared with the definitions in WSDL file, based on "Basic Profile". 6. If SOAP messages are incorrect and have failed verification, the causes lead to errors could be discovered by detailed description in "Conformance Report". Then SOAP messages must be corrected and the errors must be solved. 5 Conclusion Since WEB service is a new phenomenon in distributed applications field, it may have various problems. The most significant one is the interoperability between elements, which is quite obvious when multi-vendor Client and WEB service are used. In general, WEB service design has two methods, "Contract-First" and "Code-First". Analyze of possible interoperability problems has shown that the former method has better interoperability level in comparison with the latter. Moreover, some solutions have been proposed in order to reduce the mentioned problems. References [1] Graham, S et al (2001). Building Web Services with Java. Sams publishing. ISBN [2] Bray, T et al (2004) Extensible Markup Language (XML) (third edition) from [3] Gudgin, M et al (2003). Soap version.2 from [4] Christensen, E et al (2001). Web Services Description Language (WSDL) 1.1 from [5] Brittenham P (2003). Understanding the WS-I test tools from works/web services/library/ws-wsitest/ [6] Balinger, K et al (2004). Basic Profile version 1.1 from services implementation Nasrin Hezare Moghadam has BS degree in computer engineering from Amirkabir university of Tehran (Iran) and Master degree in computer architecting from Amirkabir university of Tehran (Iran). Since 2004, she has been working for ITRC as a researcher in ITRC; important fields in her work are NGN Networks, communication protocols implementation and testing, network Masoumeh khoshbakhtian holds a hardware computer engineering degree from Esfahan University of technology in Iran. She has been working as researcher at Communication Technology Institute of Iran Telecommunication Research Center since Her important expertise is based on IP- Multimedia Subsystem (IMS) and services, design of Next Generation Networks in IRAN, implementation and testing of communication protocols

This presentation is a primer on WSDL Bindings. It s part of our series to help prepare you for creating BPEL projects. We recommend you review this

This presentation is a primer on WSDL Bindings. It s part of our series to help prepare you for creating BPEL projects. We recommend you review this presentation before taking an ActiveVOS course or before