TOWARDS INTEROPERABILITY OF WIRELESS SERVICES A DESCRIPTION MODEL OF SERVICE INTERFACES

Transcription

1 TOWARDS INTEROPERABILITY OF WIRELESS SERVICES A DESCRIPTION MODEL OF SERVICE INTERFACES Anne Immonen, Jarkko Holappa, Päivi Kallio, Jarmo Kalaoja VTT Electronics, Embedded Software Kaitoväylä 1, Oulu {Anne.Immonen, Jarkko.Holappa, Paivi.Kallio, Jarmo.Kalaoja}@vtt.fi ABSTRACT Web services are evolving quickly in terms of standardization. Technology and additional wireless networks exact requirements upon web services used via wireless connections, such as mobile networks. The interoperability of services is essential in wireless networks because cost effective development and deployment of new wireless services for a user requires maximum utilization of service infrastructure. At the moment, constraints of service interface description models and implementation of services restrict interoperability between services. To achieve interoperability and composability, a standardized way to describe services and service interfaces is required, and for this reason standardization bodies are promoting the set of Extensible Markup Language (XML) technologies as the basis for a set of common standards. To respond to the challenges concerning service interoperability, this paper illustrates three widely known web standards that promote interoperability between web services - SOAP (Simple Object Access Protocol), WSDL (Web Services Definition Language) and UDDI (Universal Description, Discovery and Integration) and proposes an interface description model for wireless Internet services. The proposed model takes into account architectural level service description in a novel way and presents its implementation using XML. Key words: web services, interface description and wireless. 1. INTRODUCTION During the last years, the World Wide Web (WWW) has become the forum for delivering and sharing all kinds of information and services. Current dilemma with the web-services is that they were not originally developed to be interoperable with each other and therefore their interoperability is still low. This research defines web services as self-contained, self-describing, modular applications that can be published, located and invoked across the web (ISM Web service team 2000). A stricter definition presents that web services are based on the SOAP over HTTP (Simple Object Access Protocol-over-HyperText Transfer Protocol) technology and use XML to create machine-readable documents. Wireless Internet services are web service applications that interact over the open Internet using standard protocols and which are used by clients that are connected to the Internet utilising some wireless networking technology (such as General Packet Radio System - GPRS). To enable interoperation of services, standard interfaces are needed to determine how services can be interconnected and used with other services. Especially within wireless services, the lack of open interfaces and common standards makes service design very challenging. Nowadays, operators tend to have proprietary solutions and interfaces for their operating service systems and no interoperability between operators exists (Kallio et al. 2003). The end-users are thus limited to the services that their own operator provides and gives access to. Whilst being a novel and evolving area, web services and their adaptation to the wireless world has been the subject of numerous studies. Most of the work is done using the existing Internet and WWW-standards (e.g. the Internet Engineering Task Force - IETF and the World Wide Web Consortium -W3C). Standardized

2 interface descriptions and description of web services have been handled also in the papers of Patil & Newcomer (2003), Roman et al. (2000), Curbera et al. (2002), Wales (1999), Merz et al. (1994). The model driven architecture (ISO/IEC 2001) defines a normative model that guides the specification of IT systems. The traditional description formats of interfaces are still not adequate for service s interface description for several reasons. Some of these challenges are mentioned the following: The description format should allow express variability in the interface. The format should allow an effective information search when retrieving information from the service or the interfaces. The format should enable the presentation of different information, i.e. different views of the information. Therefore, a more powerful description technology for interface description is required. Taking into account architectural design of the service interface: so far none of the service interface description methods take architectural design of the interface into account. To respond to the above challenges this paper proposes an interface description model that includes two levels that are directed to different purposes and different stakeholders: the architectural and transformation level. The software architecture of a program or computing system is the structure or structures of the system, which comprise software components, the externally visible properties of those components, and the relationships among them (Bass et. al 1998)and it includes the principles that guide the design and evolution of the architecture (IEEE 1992, Perry & Wolf 1992, Shaw & Garlan 1996). From architectural perspective, a service is the capability of an entity to perform, upon the request of another entity, an act that can be perceived and exploited by the client (Niemelä et. al 2002), whereas service architecture is the architecture of applications and middleware. Software architecture includes the application, middleware and, in a broader sense, also system levels. Additionally this paper discusses three technologies used for improving interoperability of web services: SOAP, WSDL and UDDI. 2. WEB TECHNOLOGIES AND INTEROPERABILITY This chapter presents three technologies defined by W3C that have been trying to solve the dilemma of interoperability between web services: SOAP, WSDL and UDDI. Figure 1 depicts the responsibilities and relationships between the illustrated technologies. Packaging Management Workflow language Security Conversations Reliability Transactions Service Characteristics Caching Routing Choreography Inspection Asynchrony Security XML Schema Registry SOAP Messages & Headers WSDL UDDI Transport (Wire) Description Discovery Figure 1. Relationship of the web technologies SOAP is a lightweight protocol for the exchange of information in a decentralized, distributed environment. SOAP offers basic communication for Internet services but it does not define what messages must be exchanged to successfully interact with the service. SOAP is an XML based protocol that consists of three parts: an envelope that defines a framework for describing what is in a message and how to process it, a set of encoding rules for expressing instances of application-defined datatypes, and a convention for representing remote procedure calls and responses. SOAP can potentially be used in combination with a variety of other protocols. Message structure is an XML element with two child elements, one of which contains the header and the other the body. The header contents and body elements are themselves arbitrary XML. Furthermore, SOAP specification defines a model that determines how a recipient should process SOAP messages. In addition to this, the message model has defined actors which define who should process the messages. (W3C 2000, Curbera 2002) WSDL describes the web service s interface (the vocabulary, the message and the interaction) and provides users with a point of contact. In other words, it provides a formalized XML-description of client-

3 service interaction. WSDL enables one to separate the description of the abstract function offered by a service from the concrete details of a service description such as "how" and "where" that function is offered. WSDL can be used to describe practically any networked service: SOAP over HTTP and in addition to that, non XML-based protocols like DCOM (Distributed Component Object Model) over UDP (User Datagram Protocol) (W3C 2001a). WSDL describes web services starting with the messages that are exchanged between the service provider and requestor. The messages themselves are described abstractly and then bound to a concrete network protocol and message format. A message consists of a collection of typed data items. An exchange of messages between the service provider and requestor are described as an operation. A collection of operations is called a port type. A service contains a collection of ports, where each port is an implementation of a port type, which includes all the concrete details needed to interact with the service. For interoperability and platform neutrality, WSDL prefers the use of XSD (XML Schema) as the canonical type system. UDDI creates a standard interoperable platform that enables companies and applications to quickly, easily, and dynamically find and use web services over the Internet. The focus of UDDI is to define set of services supporting the description and discovery of 1) business organizations and other web service providers, 2) web services that are made available by the service providers, and 3) the technical interfaces which are used to access those services. UDDI is based on industry standards (e.g. HTTP, XML, XML Schema and SOAP) (Uddi.org 2002). Although SOAP, WSDL and UDDI combined provide a standardized technology platform to transport, describe and discover services, the lack of architectural-level service description reduce flexibility and possibility of reuse the existing descriptions. Next chapter proposes an interface description model which pays attention to architectural design of the service while maintaining extendibility and consistency with existing standards presented in this chapter. 3. INTERFACE DESCRIPTION MODEL This section describes a model for service interface description and its implementation by using XMLtechnology that is the W3C s recommendation for a meta - mark up language (W3C 2001b). The interface description model described in the following has two levels. The first level illustrates the interfaces from the architectural point of view, describing the responsibilities of the interface. The second level is a detailed description of the transformation of the interfaces, i.e. how the interfaces are mapped to the implementation. The interface description is intended to be used as a part of formal architectural level service description showing the relevant information about the service for a software architect considering the interoperability. To formalise the description, XML-implementation of the proposed interface description is also presented. The transformation level description reveals the alternative implementations of the interfaces at design level. The interface description model supports flexibility; in other words, it can be modified according to the individual interface. However, the basic rules for the model are defined exactly. The architectural level interface description is a specification for the architectural level of the service. Graphically, the interfaces can be described using the external component diagram that illustrates both the required and provided interfaces of the service. However, the graphical presentation is not informative enough, so a more detailed description is required. The interface description of the architectural level consists of the following elements: the interface s name, bundle, communication type, a list of implementations, its responsibility and operation. The interface name should be well defined and it should describe the use or the purpose of the interface. An interface may be a part of an interface bundle that is a collection of interfaces, and provides a mechanism to compose the interface from several other interfaces. A bundle can be a multilevel element, i.e. a bundle can consist of several bundles. Interface communication describes the type of communication that occurs via the interface. Implementation in this context means the technology that the interface supports. There may be several implementations for the interface, so the technologies used are listed here. Responsibility describes the assignments that the interface is responsible of. Operation introduces a list of named operations that the interface enables. A more detailed description for them is given in an interface transformation description. Table 1 displays the introduced elements of the interface s description. The interface field in Table 1 can also include a reference element that is an optional element is used to make a refer-

4 ence to an architectural design document, where the interface or the interface bundle is described along with behavioural models etc. The reference should also name the architectural view is used to define the design. Table 1. Architectural level interface description. Interface Responsibility Operation Name of the interface (the name of the possible interface bundle) Communication type List of implementation technology (i.e. variants) Reference (reference to the architectural design document) Description of the interface s responsibility Operation name The transformation level interface description describes how the interfaces are transformed from the architectural design level to the implementation level. Each interface is described separately. In addition, there may be several variants for each interface. In this context, a variant is an alternative implementation of the interface. Each variant should be described using the following table (Table 2). Table 2. Transformation level interface description. method s responsibility Interface name: technology Method Responsibility Parameter Return Exceptions Method name: transmission primitive Description of Parameter name: type The returnvalue of the method Description of exceptions in communication The interface description at the transformation level consists of the following elements: implementation, method, responsibility, parameters, return and exceptions. The name of the interface is the caption of the table; also the implementation technology supported is named in the caption to identify the variant. A method element must always correspond to an operation from the architectural level description. In this context, a method is an implementation of an operation. The primitive for the method is one of the message transmission primitives defined in WSDL: one-way, request-response, solicit-response or notification. Responsibility elements describe the purpose and responsibilities of the method. Parameter accords with the "part name" in WSDL. Messages consist of one or more logical parts. Each part is associated with a type from some type system using a message-typing attribute. Thus, a parameter type is a data type definition that is relevant for the exchanged message. The return element imposes the return-value of the method. The exceptions element describes the possible exceptions in communication. Table 2 displays the introduced elements. XML was chosen as interface description language because of its extensibility and application independency. It also provides mechanism for describing the document s content, structure and meaning in a machinereadable format. It enables platform-independent data exchange between applications (Walsh 1998). It is a non-proprietary format that is not encumbered by any sort of intellectual property restriction and this also enforces interoperability, as proper documentation is an important way of verifying the capabilities of the third party components and services (Taulavuori 2002). Any tool that understands the XML format can be used to handle XML documents that consist of semantic tags (elements) that divide a document into parts and identify the different parts of the document. The extensibility and self-describing nature of XML means that users can define their own set of mark-up tags. These tags must be organized according to certain general principles of a Document Type Description (DTD), which specifies the rules for the structure of a document. It does not include any formatting instructions, but the formatting can be added into documents with style sheets. It allows for easy data retrieval from the whole service description. Separate XSL (Extensible Style Language) style sheets allow for the creation of different views from the XML data. XSL is a style language for presenting structured content - i.e. styling, laying out and paginating of the source content into some presentation medium (Harold 1999). With the help of a style sheet, the interface description can be easily viewed in a desired format and the unnecessary information can be filtered away when needed. The XML based interface description consists of an interface model and the description of both provided and required interfaces. The interface model is usually a picture of external component (or service) interfaces using UML2 notation. The model element includes the name attribute, and has a child element designated image. The image element also has the name attribute for the name of the image and a src-attribute for the source of the image. The image element may also have a child element designated a caption for inserting the caption for the image. Interfaces, provided and required, are described by the interface element that has the name and bundle attributes and child elements, such as responsibility, communication, reference, operations and variant. The reference element has a child element called target that has an href attribute for the loca-

5 tion of the referenced document. The operations element can have child elements designated operation one to many. The interface element may have one to many variant elements, depending on the amount of the different interface implementations. The variant element has an attribute designated technology and a child element designated methods. The methods element can have one to many child elements designated method. The method element has a name attribute and the child elements, such as type, responsibility, parameters, return and exceptions. The parameters element can have as many as possible child elements designated within parameter. The parameter element has the name and type attributes. 4. CASE EXAMPLE In this chapter, the interface description model is demonstrated by using an example service - a Service Management Component that addresses the following functional areas: the authentication and authorization of users, user profile management, self-subscription management and accounting and mediation/rating. The Service Management Services are accessible through an interface that is a façade between the service management server and the application servers. Figure 2 shows how the XML template is applied to describe elements of the interface of the sample service and the resultant document viewed via a browser using a style sheet that formats the XML data e.g. to the table format. Figure 2. The XML description of an interface of the sample service and viewed with XSL styleshteet. 5. CONCLUSIONS To enable interoperation of services, standard interfaces are needed to determine how services can be interconnected and used with each other. The description of interfaces is an essential part of the description of the service, and the interfaces should be described alongside the service using the same standardized technologies. This research presented a model for describing wireless service interfaces that has two levels directed to different purposes and different stakeholders: the architectural and transformation level. The archi-

6 tectural level description presents the interfaces from the architectural viewpoint of the service and thus it is possible to include it in the whole service description. It describes the responsibilities of the interface in the context of the surrounding environment. The transformation level of the description model gives more detailed information on the functionality and the accuracy of the interface s operations or methods. Each interface is defined separately in the model. The presented interface description model supports a flexibility of approach. It can be modified according to the individual interface. The basic rules for the model are defined exactly to enforce consistency between the two levels and standards. XML was chosen for the implementation of the interface description model, because of its extensibility and independency of application. In addition to the presented interface description model this paper illustrated three web service technologies: SOAP, WSDL and UDDI. REFERENCES Curbera, F., Duftler, M., Khalaf, R., Nagy, W., Mukhi, N., Weerawarana, S., Unraveling the Web services web: an introduction to SOAP, WSDL, and UDDI. IEEE Internet Computing. Vol. 6, Issue 2, March-April Pp Harold, E., XML Bible. Foster City, USA: IDG Books WorldWide, Inc. ISBN: p Bass, L., Clement, P., Kazman, R., Software Architecture in Practice. Addison-Wesley, Reading MA. ISBN p. Niemelä, E., Honka, H., Jormakka, H., Kalaoja, J., Koivisto, J. Kyntäjä, T., Latvakoski, J., Näyhä, T., Rannanjärvi, L., Valtanen, K., Vaskivuo, T Services architectures. In: Communications Technologies. The VTT Roadmaps. Sipilä, M. (ed.), VTT Research Notes Espoo pp Garlan, D., Allen, R., Ockerbloom, J., Architectural Mismatch or Why it's hard to build systems out of existing parts. IEEE Software, Vol. 12, Issue 6, Nov Pp IBM Web service team, Web service architecture overview The next stage of evolution for e-business. September Available on-line at: www-106.ibm.com/developmentworks/web/library/w-ovr [ ] IEEE, IEEE Std : Standard for Software Quality Metrics Methodology. New York: Institute of Electrical and Electronics Engineers. ISO/IEC, Standard ISO/IEC :1996, (2001), Model Driven Architecture (MDA), OMG Architecture Board, 31 p. Kallio, P., Matilainen, A., Boggio, D., De Matteis, G., Proceedings of the 2nd International Workshop on Wireless Information Systems, WIS 2003 in conjunction with ICEIS 2003, Angers, France, April Setubal: ICEIS Press ISBN Pp Merz, M., Muller, K., Lamersdorf, W., Service trading and mediation in distributed computing systems. Proceedings of the 14th International Conference on Distributed Computing Systems, 1994, June Pp Patil, S., Newcomer, E., ebxml and web services. IEEE Internet Computing. May-June Pp Perry, D., Wolf, A., Foundation for the Study of Software Architecture. SIGSOFT Software Engineering Notes, Vol. 17, no. 44. Pp Roman, M., Beck, J., Gefflaut, A., A device independent presentation for services. 3 rd IEEE workshop on Mobile Computing Systems and Applications (WMCSA 00). Pp Shaw, M., Garlan, D., Software architecture. Perspectives on an Emerging Discipline, Prentice Hall: Upper Saddle River, N.J. ISBN: p. Taulavuori, A., Component documentation in the context of software product lines. VTT Electronics, Espoo. VTT Publications: 484. ISBN ; p. Uddiorg, UDDI Version 3.0, Published Specification. Available on-line at: published htm [ ] Wales, M.G., WIDL- Interface Definition for the Web. IEEE Internet Computing. January- February Pp W3C, Simple Object Access Protocol (SOAP) 1.2. Available on-line at: [ ] W3C, 2001a. Web Services Description Language (WSDL) 1.1. Available on-line at: [ ] W3C, 2001b. Extensible Markup Language (XML). Available on-line at: [ ] Walsh, N., A Technical Introduction to XML. InterCHANGE, Vol. 4, Issue 2. Pp * Acknowledgements. This work was done in the WISE (Wireless Internet Service Engineering)-project, funded by the European Union, and the four participating European companies and three research institutes.