Web Services: An Architectural Overview
Roseli Persson Hansen Cassia T. Santos Sérgio Crespo C. S. Pinto Guilherme L. Lanius Fernando Massen Email:{roseli,cassiats,crespo,speka,ferhr}@exatas.unisinos.br Post-Graduation InterSubjective Program in Applied Computing - PIPCA UNISINOS
Abstract ture are described, such as some development plat- forms that are being deployed today. Then the Sec- Web Services represents an architectural structure tion 4 ends with an comparison between architecture that allows communication between applications. and platform proposals. The use of eXtensible Markup Language (XML)- based Technology allows exploitation of services without needing to know what platform or language 2 What is Web Services? was used to create those services. This document aims to offer an overview of the main Web Services are modularized applications that can approaches about Web Services architecture, stab- be described, published and invoked under a net- lishing what are the common points between them. work, commonly being WEB-based. I.e., Web Ser- vices are interfaces that describes an collection of operations that are accessible through the network 1 Introduction by throwing standard XML messages. Web Services allow serivce integration in an fast, effective way Web Services represent an architectural structure ([21, 8]). that allows communication between applications. A Web Service is a software component that in- An service can be invoked remotely or be used to depends on the implementation and platform. It can employ a new service together with another ser- be described using an service description language, vices. Beyond the basic Web Services structure, this published in a registry and discovered by an stan- paper will be presenting some standard technolo- dard mechanism. Thus, it can be invoked from a Ap- gies to build Web Services, such as: Web Services plication Program Interface (API) through the net- Description Language (WSDL) [10], Simple Object work, built in round of another services. Access Protocol (SOAP) [6] and Universal Descrip- Web Services contain the best accomplishments tion, Discovery and Integration (UDDI) [11]. These of the Web-based component development. Like technologies are based in eXtensible Markup Lan- its software components counterparts, Web Services guage (XML) [3], and they allow service reutiliza- contains black-box functionalities that can be reused tion and invocation, without needing to know the without caring in what language it will be used underlying language or platform. This article ap- ([12]). proachs yet the main Web Services architectures, The Web Services terminology describes spe- proposed by Microsoft, HP, Sun and IBM. cific functionalities of the exposed business, usu- Section 2 presents an brief concept of Web Ser- ally through Internet connections with the purpose vices, such as the components that make part of an to provide some way to exploit this service. basic structure: Service Register, Service Requestor The exposure of services enrolls: and Service Provider. Setion 3 describes the main standard technologies employed in Web Services. In • Identify or define value functions in the process the Section 4 the main approaches of the architec- or business.
1 • Define a service-based interface to the pro- Service Description cesses. Service Registry • Describe these interfaces in a Web-based form. Discover Publish WSDL, UDDI To make a service available in the Web is commonly WSDL, UDDI necessary: Service Service Service • Publish the service interface, allowing users Requestor Bind Provider Service find and use it. Description • Accept requests and send responses using the XML message protocol. Figure 1: Web Services roles, operations and crafts • Stablish a binding between external requests ([21]) and business functions implementation.. By using a message-form document, a program • Service Requestor: it is an application that in- sends a request to a Web Service through the net- vokes or initializes some interaction with the work and (optionally) receives some response, also service. It could be a web browser or even in a XML-based message-form document. The us- a non-user interface program such as another age of XML raises the importance of provide such Web Service. By using the service description extensible mechanism to describe the messages and it’s possible to discover and invoke Web Ser- its contents. Furthermore, Web-based services stan- vices. dards define the format of the message and mech- • Services Registry: it’s the place where ser- anisms to publish and discover Web Services inter- vice providers publishes their service descrip- faces. tions. Service Requestors search the Registries, Web Services are not accessed via specific object- fetching binding and description information - model protocols such as Distributed Component both during the development time (static bind- Object Model (DCOM), Remote Method Invocation ings) or run time (dynamic bindings). (RMI) or Internet Inter-ORB Protocol (IIOP); ac- tually they are accessed through transport protocols As mentioned early, there is the Service Descrip- like HTTP, FTP, etc. ... tion whose contents describes interface and imple- mentation details, including data structures, oper- 2.1 Web Services Architecture ations and network binding informations. Also it contais data to easy Service Requestors’s search- In a Web Service architecture a service description ing process. The Service is the software deployed covers all the necessary details to grant the service through the network by the Service Provider. interaction, including messages’s format, the trans- Afterwards, there are common operations used in port protocols and physical location. that architecture, such as: This interface hides service implementation de- tails, allowing that the same service can be used • Bind: when a service must be accessed, this independently of the underlying hardware or lan- operation invokes and initializes interaction guage, thus making Web Services-based applica- within its caller in runtime, using binding in- tions component-oriented, making those compo- formation provided by the service description nents available for reuse. to both locate and contact it. The Web Services architecture presented in Figure 1 is built upon a three-role interaction: • Publish: a service must be published in an Service Registry to be accessed. The Service • Service Provider: this is the service’s owner Provider thus contacts the Service Registry to from the business perspective. From the archi- publish the service. tectural approach, this is the platform that is ac- cessed in the service request. It is also the en- • Discover: A Service Requestor finds a de- tity that creates the Web Service, being respon- scription of the service or queries a Service sible to make its description in some standard Registry for the required service type. A Ser- format and publish its details in a central reg- vice Requestor can find a service interface istry. description in both run time or development
2 time. Then, the necessary information regard- 3.1 The Web Services Description Lan- ing bindings and locales to invoke a service are guage (WSDL) found and contacted. The WSDL is a XML-based language to describe services as a collection of accessible operations 2.2 Web Services Conceptual Layers through messages ([10]). Defines interfaces and ser- The Picture 2 presents the Web Services conceptual vice interaction mechanisms, binding protocols and layers, described below ([21], [17]): network services details. It presents additional de- scriptions such as context, Quality of Service and • Network Tier: it’s the base layer that rep- service-to-service relationship. By using its meth- resents protocols such as HTTP, FTP, SMTP, ods, it’s possible describe a object in a transparent, POP, etc. ... This tier is used accordingly to the implementation-independent way. needs of the application: security, availability, performance and reliability. Service Service • XML-Based Message: this layer uses the Implementation SOAP protocol as the message exchange tech- Definition Port nology standard, which stands for exchange of information in a distributed, decentralized en- vironment. Binding Service • Service Description: the description of the Interface Port Type service is done using the Web Services Descrip- tion Language (WSDL), which defines the in- Definition Message terface and interaction mechanisms of the ser- vice, further describing additional informations Type such as context, Quality of Service and service- to-service relationship. Figure 3: Service Description Layer ([21]) • Service Publishing and Discovery: these two layers use the UDDI standard to discovery and The usage of WSDL also allows a basic service publish information regarding Web Services. description in two parts as shows the Picture 3. This basic definition is separated in both service Standard Technology Requirements interface and implementation, allowing these parts UDDI Service Discovery Q to be reused separately. A brief description of the u M a layers from the Picture 3 ([21, 10]) is explained be- l i a S
UDDI Service Publishing t n y e a
low. c o g u f e r
m S WSDL Service Description i t y e e r n v t i XML− Based Message c Service Interface Description Layer
SOAP e HTTP, FTP, em a il.. Network A service interface contains a WSDL service defi- nition. This definition allows that a interface can be used, instantiated and referenced by multiple service Figure 2: Web Services Conceptual Layers ([21]) implementation definitions ([4]). The WSDL:binding directive describes the proto- col, data format, security and other attributes to a particular service interface (WSDL: portType). The 3 Standard Technologies Used WSDL: port Type tag informs the Web Service oper- in Web Services Architectures ation elements. The WSDL:message tag is used to define data in- Three technologies were previously mentioned re- put and output regarding a operation. garding Web Services structure. Lying between Also the WSDL:type tag defines the complex data these technologies WSDL, SOAP and UDDI are ad- types inside a message. dressed in a most proper form in the subsections that A interface file describes the Web Service, includ- follows. ing the methods that are invoked, parameters that are
3 sent and codification that’s being utilized. • RPC SOAP: specifies how encapsulate remote procedure calls and responses inside the mes- Service Implementation Description sage, thus invoking remote procedures; Layer • Binding Framework and SOAP Transport: De- It is a WSDL document that describes how a ser- fines a abstract framework to exchange SOAP vice interface is implemented by a service provider. envelopes between applications using a simple A WEB-based service is modeled as a WSDL el- transport protocol. ement which contains a WSDL: port elements col- In the SOAP specification, another concepts are also lection (associated port and service searching) with important ([15, 6]): a WSDL: binding interface-definition element. A implementation file describes where the Web • SOAP Client: it’s a program that creates a Service is installed and how it could be accessed. XML document containing the necessary infor- Likewise the interface and implementation defi- mation to invoke remotely a method within a nitions, the WSDL specifies extensions for proto- distributed system (it could be a WEB or appli- col bindings and message formats, such as SOAP, cation server); HTTP GET/POST and MIME ([10]). • SOAP Server: it’s responsible for executing a 3.2 Simple Object Access Protocol SOAP message and acts like a interpreter and (SOAP) distributor of documents; It is a protocol for exchanging information in a de- • Mensagem SOAP: it’s the basic communica- centralized, distributed environment, thus allowing tion form between SOAP nodes; communication between various applications ([6]).
4 SOAP Envelope WEB Service SOAP Header Application Application SOAP Block 2 1 4 3 SOAP SOAP SOAP Block Network Network Response SOAP Body Requisition SOAP Block
SOAP Block Figure 7: XML Message using SOAP ([21])
XML message arrives at the requisitor, is converted to a programming language, being shipped then to Figure 5: SOAP Envelope Structure ([6]) the application. To use a service, it’s mandatory to the client to
SOAP Nodes find it. This search can be done through UDDI, which will be presented in the next section. Message Path
SOAP Message SOAP Message 3.3 Universal Description, Discovery and Integration (UDDI) SOAP SOAP Initia l La st Receiver Sender SOAP SOAP Sender Receptor The UDDI specification is a common effort to define Interm edia te SOAP Nodes and create a standard service registry. This registry can be accessed by clients and these can locate all the services that they need ([2, 11]). The central component, called UDDI Project ma- Figure 6: Message’s Path Througth SOAP Nodes nipulates a public, global registry called UDDI busi- ness registry. All the information maintained in the public registry are available to general queries. A The picture 6 shows how the message navigate private registry can add security controls to provide through the SOAP nodes. Once SOAP doesn’t guar- data integrity and prevent non-authorized access. By antee routing, it knows which SOAP sender created that way, it only can store private information, con- the message and knows who’ll be the last receptor tain a subcollection from the public registry, even a of the message through zero or more intermediary combination of both. The information that’s offered nodes. by business registry consists of three components: When a SOAP node receives a message, it must execute a process, generate success or fail messages • “white pages” - address, contact and identifiers or, if necessary, return additional messages. that are known; The invocation of the service using SOAP occurs • “yellow pages” - industrial categorization; likewise Picture 7. The Application (1) requests a SOAP message and invokes the service opera- • “green pages” - information. tion through a Web Service provider. The Service Requestor presents the message including the net- The UDDI implementation is a Web Service registry work address of the Web Service provider. The net- server that provides a mechanism to publish and work infrastructure (2) ships the message to a SOAP locate Services. A UDDI registry server contains server. This SOAP server redirects the requested categorized information about businesses, services message to the Web Service Provider. The WEB that the lasts offers, and associations with Web Ser- server (3) is responsible to process a request mes- vices specifications. These specifications normally sage and then build a response. The message (4) is are also done in WSDL through a UDDI registry redirected through the SOAP infrastructure. When a ([24]).
5 The main information model used by UDDI reg- The businessService istry is defined through a XML schema, which de- Represents a logical classification of the service. fines four types of information: The element’s name contains the term “business” • business information; aiming to describe the purpose of this hierarchy level in service description. Thus, each busi- • service information; nessService structure belongs to an only busi- nessEntity structure. • bindings information; • service-specific information. The bindingTemplate
The information that concludes the registry of a ser- The bindingTemplate structures are technical de- vice consists of four types of data structures. ([11]). scriptions of Web Services that are stored via indi- This division in a information-type fashion offers vidual bindingTemplate instances. These structures simple partitions to help in the fast search and com- provide support for one access the services remotely. prehension of the different data that builds the reg- The support for technology-specific parameters of istry. The five structures are shown in Picture 8. the application and configuration files are encoun- tered also. Then, it describes how the businessSer-
business Entity: Information vice uses various technical information. regarding the group which publishes information about the service The tModel tModel: Services and Taxonomies specification business Service: Descriptive description The tModel structure is represented through meta- information about a particular technical service data (data about data). The purpose of a tModel in- side a UDDI registry is to provide a reference sys- tem. bindin g Template: Technical information regarding service’s entry− point and constructions’s specifications The publisherAssertion
publisherAssertion : Information about an Conta ins tModels Many business aren’t effectively represented by relationship between two references. These only one businessEntity. As a consequence, many parts. references ca ll the interfa ce' s specifica tion businessEntity structures can be published. Even rega rding its service then, they continue to represent an simple group- ing and could demand that one of its relationships Figure 8: UDDI Structure ([11]) should be visible in their UDDI registers. In this matter, two related businesses use publisherAsser- The businessEntity supplies information about a tion messages, as a way to publish declarations on business, containing one or more businessServices. how they relate with each other. One or more pub- The technical and business descriptions for a spe- lishers should agree that the relationship between cific Web service are defined in its businessService them is valid. Both should publish exactly the same and bindingTemplate elements. Each bindingTem- information, rendering their relationship visible. plate contains a reference to one or more tModels. An UDDI registry, for this matter, runs inside One tModel is used to define the technical specifica- a UDDI server. That registry is an WEB applica- tion of a service. tion that can be accessed via browser or by an pro- grammable API, through SOAP protocol. The businessEntity 3.4 Publishing and Finding WSDL Ser- This structure represents all the whole information vice Descriptions in the UDDI reg- known from an specific business or entity which istry publishes descriptive information about the entity, likewise its supplying services. From the XML The UDDI data entities provides support to describe point of view, the businessEntity is the top-level information about business and services. The in- data structure whose information regards descrip- formation about a service description inside WSDL tion about an business or entity. complements the information found in the UDDI
6 registry. UDDI provides support also to various • From a existing JavaBean is possible specify kinds of service description, althought it doesn’t which methods should be exposed as a Web supports WSDL or another mechanism of service Service. The wizard then generates the WSDL description directly ([4, 5]). files accordingly. A complete WSDL service description is a com- bination of a service interface and its implementa- • The wizard also creates a ISD file, that’s the tion document. This implementation describes ser- SOAP development descriptor for an specific vices’s instances; each instance is defined using a Web Service (dds.xml). WSDL service element. • It is also mandatory to specify the SOAP codifi- A service implementation is published in a UDDI cation, which tells to the runtime how to trans- registry as a businessService or within one or more late data structures written in Java to SOAP- bindingTemplates. The businessService is pub- XML and vice-versa. lished by the service provider. Once the service interface represents a reusable • It is possible to create a Web Service proxy class definition, this interface can be published inside a likewise the 5th step. This class contains code UDDI registry using a tModel. Such operation must to cofigure the parameters regarding input and be done before the service implementation is pub- output’s codification styles. Also this is the lished as a businessService. class that does the SOAP requisition accord- The standard technologies are putting the efforts ingly the 6c step. of some companies to offer development architec- tures targeting Web Services. • It allows generate a JSP application which in- vokes Web Service methods and return its re- sponses (step 6b). 4 Web Services Development Ar- • The wizard adds two servlets to the application: chitectures and Platforms the Apache RPC SOAP and the Apache Mes- sage SOAP. These servlets receives SOAP re- From the basic Web Services architecture, some quests coming from a SOAP client (step 6c), companies are offering their proposals such as their invoke a Web Service (step 6d) and returns its own development platforms. The following subsec- SOAP response. tions presents the IBM, HP, SUN and Microsoft pro-
1: Defines posed platforms. 1: Develop 2: Java Server to WSDL Java sp.wsdl Provider 2: WSDL to Java Server 4.1 IBM’s Web Services Model 5: WSDL to Java Client 3: Implements 4a: Publish 6d: Invokes Client 4b: Discover The IBM proposal is based upon the general Web SOAP Proxy SOAP UDDI Services architecture presented in the Picture 1. dds.xml Client Server Registry IBM developed the WebSphere family of server- Application Server 6a: discover 6b:Invoke based tools, mainly aimed to raise the functionalities 6c: Transport− level calls (optional) (http− Post,...) of the standard WEB server. That platform also ex- Java tends a development environment adding Internet- Request 5: Develop based development standards such as Java2 Enter- prise Edition (J2EE), CORBA, XML and Web Ser- vices. Figure 9: Web Services Development Process. ([27]) The WebSphere Studio Application Developer presents the Java language as the technology of choice to Web Services development. The Ap- plication Developer uses “Web Services Wizards”, Web Service Client Wizard which makes the development of Web Services eas- • The Web Service Client Wizard allows gen- ier ([27]): eration of a Java proxy class from a existing WSDL file (step 5 - Picture 9). Web Service Wizard • The Java proxy class encapsulates the code in The Web Service Wizard starts at the step 2 of the order to make a SOAP requisition and call the Picture 9: Web Service.
7 • This assistant is part of the Web Service Wizard. Service It can generate, deploy and run a WEB sample Registry
application to test the Web Service. P e u t b ca l o is L h Web Service Skeleton JavaBean Wizard
This wizard creates a JavaBean from a WSDL doc- Service User Interact Service Provider Service ument. The JavaBean contains method definitions Composite Service accordingly the WSDL described operations. With Component Application Application this resource, it’s possible to implement various Processing Processing methods from a basic structure, thus finishing the Interaction Conversa tion Flow Interaction Web Service implementation process. Control Control Message Message Passing RPC & Docum ents Excha nge Passing
Web Service DADX Group Configuration Company A Wizard Company B The wizard allows create a Document Access Defini- tion Extension (DADX) group. A DADX file spec- Figure 10: HP Web Services structure ([18]) ifies how create a Web Service using a collection of operation that are defined through SQL declara- Through these elements, the HP platform supports tions or DAD files. The DAD files describes a XML Web Services interactions, partitioning the architec- document element mappings and, also specifically, ture in three key areas such as: message transfer- the columns of a DB2 database query. It’s used by ence, interaction control and application processing. DB2 XML extender to store and retrieve XML doc- Based in this structure, the HP model provides stan- uments inside a DB2 database ([9]). dards to create, deploy and access WEB services. The main HP Web Service core technologies are UDDI browser (import, export) XML and Java. It also uses emerging standards like UDDI, SOAP and WSDL, also supplying support The Application Developer contains a WEB appli- and development tools ([18]). cation that compounds the IBM UDDI explorer. It allows the following functionality: Application Processing Security (WorkFlow, Servlet/EJB, JSP, Cocoon, etc.) • Find a businessEntity (step 4b); Transactions Availability • Publish a businessEntity (step 4a); Interaction Control Scalability (Envelope Processing, Sending Components to Application) • Find a service interface and implementation Monitoring Management (step 4b); Message Transference (Transport, Contents, Format Manipulators) Tools • Publish a service interface and implementation.
4.2 Hewlett Packard’s Web Services Figure 11: HP Web Services 1.0 Platform ([18]) Model The HP model supports Web Services interactions From the known standards applied to the Web Ser- via a modular architecture that can be seen in Picture vices architecture, the Picture 10 presents already 11 and will be briefly described below: known components such as: • Message Transference: support low-level • Registry Server that provides mechanisms to communication protocols between participat- publish and locate Web Services; ing Web Services. Supplies morphing and • Service User that uses the available services; sending of component-processing messages to alternative formats (non-XML formats, • The Service Provider providing an application for instance). It enables SOAP-RPC sup- as a service and possibly publishing the ser- port based on asynchronous messages over vice. HTTP/HTTPS, such as XML messages pro-
8 cessing and content translation, even including Final Client Directory Server up (Service Broker) ok lo L SAX, DOM and XSTL support. SD I/W D D U
Controller • Interaction Control: manages the message Web Service Business Foreign Intermediate Interface Logic / Services Services Context & exchange in the business context, generating SOAP / HTTP Interface Integration Systems Building Request Service Publishing & Adaptive Processing Adaptor the whole high-level processing in the pro- Presentation
tocol. It also manages messages validation Service Shipping Service Repository (Service Provider) and exchanging. Its characteristics includes (Service Requestor) SOAP, version 1.1 envelope processing, includ- ing sending support, J2EE-based logical com- Figure 12: Interaction between components ([29]) ponent adaptors and workflow communications systems. • Application Processing: enables the business services, thus serving both agents and clients re- logic that’s the Web Service’s core. This logic quests. The Service Container can verify the Di- can be contained inside databases and corpora- rectory Service (Service Broker), which contains tive systems. The application processes, thus, metadata about registered Web Services regarding extends the J2EE’s basic functionalities, inte- service interface bindings and service invocation grating the service with legacy systems and bindings. databases. It also enables the using of Co- All these activities can be modeled through a in- coon21-based services to other Web Services. terface called Service Processor or in an abstract module, within various useful processors such as: Afterwards, regarding this architecture, develop- e-mail processor, search processor, print processor, ment, shipping and configuration tools are presented etc., aiming access to search/bind/invoke basic ser- below: vices ([29]). In addition to the components shown above, there • UDDI Registry navigation and Web Service de- is also the Controller component. It’s used to co- scription publishing in UDDI registries tools. ordenate the various interactions and service invo- cations, and it’s responsible to general process man- • It supplies a private UDDI Registry for devel- agement regarding these operations. opment use. From this architecture perspective, Sun presents, • It provides SOAP messaging support and through the Java 2 Plataform, Enterprise Edition Cocoon2-based UDDI registry that enables (J2EE) platform, Web Services building compo- component development regarding another nents. The Picture 13, shows the Web Services de- Web Services. velopment cycle using J2EE, where one can see some forms used by clients to access services. • Provides a proxy generator which offers These accesses are made through an Web Browser remote-client Web Services invocation. (HTTP), from some application or within applets • Supports Integrated Development Environment (IIOP). Clients can connect to databases using Java (IDEs) use, commonly used to develop Web Database Connectivity (JDBC) thorught SQL, for Services components. example. Services can also be accessed through SOAP, UDDI, WSDL and ebXML ([1]) technology- • Supplies scripts and configuration tools that en- based clients. ables the adoption of the platform regarding To make these relationships possible, the J2EE customer’s needs. development model concentrates its efforts in XML and Java technologies. Accordingly to this, Sun of- 4.3 Sun Microsystems’s Web Services fers a development platform - Java Web Services Model Developer Pack (JWSDP), which contains a set of Java and XML APIs, also including its own version Sun Microsystem’s Web services architecture is di- of Tomcat JSP and servlet container, and a WSDP vided in three logical components, presented in Pic- Registry Server as well. through its APIs it’s possi- ture 12. The Service Requestor is capable to ship ble access XML documents and use their operations. Their APIs are briefly described below ([1, 19]): 1Cocoon2 it’s a framework to process XML documents. The HP platform uses this framework to deliver the results to the browser in HTML, WML or another specific format. • Java API for XML Processing (JAXP) - this
9 Client Request Clients Web Browser PDA Business Partners Applets, or Another System Applications
Web services Technologies IIOP HTTP HTTP (SOAP, UDDI, WSDL, ebXML) Firewall Servlets/JSPs Container Locate Services and XML JAXP Session Bean Service Descriptions JAXR Transform (WSDL and/or CPP) Servlets JSPs Receives Response Request Flow SOAP/ebXML Web Service Container EJBs JAXM, JAX/RPC
Connectors Firewall XML/HTTP XML/HTTP Proprietary Protocol SQL Web services Technologies Proprietary Protocol (SOAP, UDDI, WSDL, ebXML) Business Partners Registers Service in UDDI Registry Existing Systems or Programs Intermediate Business Partners Legacy Systems (in development Systems or Another System ERP Systems time) UDDI Registry Repository Databases
Figure 14: Using JAX* APIs for Web Services invo- Figure 13: J2EE Web Services Development ([19]) cation ([19])
API’s objective is create, access and mod- 4.4 Microsoft Web Services Model ify XML documents via Java programming. Microsoft’s .NET platform supports the standard It Proccess XML documents using various XMLWeb Services architecture. The .NET platform parsers such as the Simple API for XML itself and its technologies presents a new collection parsing (SAX) and Document Object Model of XML-based products, emphasizing the SOAP (DOM). It also supports the XML Stylesheet protocol ([16]). Language Transformations (XSLT), thus giv- In this manner, the data can be easily pro- ing the developer control to enable and convert grammed, edited, exchanged and organized between data to and from XML or another formats. Web Sites, applications and devices. In the Picture 15 we take note that the communication between • Java API for XML Messaging (JAXM) - sends different Web Services is done using this commu- SOAP messages over the internet in some stan- nications standards ([28, ?]). dard way. It can be extended to work within message protocols such as ebXML. Web XML Web Service • Java API for XML Registries (JAXR) - Service presents a standard way to access business registries and related informations. It allows XML XML write applications in Java programming lan- guage supplying a uniform access path to reg- XML Web Web istries based on standards such as ebXML or XML Service UDDI. Service "Building Service Blocks" • Java API for XM, RPC-Based (JAX-RPC) - XML enables one to write a Java programming lan- Client XML Client guage application that uses SOAP to invoke a remote procedure call (RPC). It can be used also in the message request and response. Thus, this API enables the developer to define Figure 15: Microsoft Web Services Model ([?]) its own XML schema and use it to send XML fragments and documents. The XML Web Services model proposed by Mi- crosoft consists in building blocks to move data via These APIs enable one easily access XML-based distributed computing. services using Java programming language accord- The Picture 16 represents the method used by an ingly to Picture 14. application to supply data and services to provide
10 data and services to another applications or users, • Server and Solution Explorer Tool: It’s an over the Internet, using a common supply chain. Ap- graphical interface to navigate among Web Ser- plications access Web Services via WEB protocols vices and manage such projects. (world-widely available) and data formats such as HTTP, XML, UDDI e SOAP without needing to ac- complish specific operating system or implementa- 1 Directory (http://uddi.microsoft.org) Client tries to locate a XML Web service. tion details. UDDI (or another A URL to an discovery document is bound. directory system)
2 Discovery Web (http//www.contoso.com/default.disco) Services The client requests the discovery document.
The discovery document is then returned.
An programmable application component 3 Descrição Open Internet accessible through standard WEB protocols Client XML (http//www.contoso.com/MyWebService.WSDL) The client requests the service description. Protocol Web service Service description is then returned. UDDI XML Web 4 Communication Structure service The client requests the XML Web Service.
WSDL The service' s response is then returned.
SOAP
XML, HTTP, SMTP Figure 17: XML Web Services .NET Infrastructure ([20])
Figure 16: Web Services ([?]) Microsoft’s XML Web Services structure is refer- enced in Picture 17, which presents three entities or roles: The XML Web service client, the XML Web The .NET platform enables the creation and use service and the Directory Service. As it follows, the of applications, processes and XML-based WEB operations made by them will be described. sites, such as services which design share and com- bine informations and functionalities from another 1. The client is interested in a credit card valida- platforms and devices ([?]). tion service. UDDI then provides the service The .NET Web Services development components directory and search functionalities througth a follows ([20]): standard API.
• ASP+ runtime: represents an programming ab- 2. A client requests a discovery document regard- straction that allow developers to build Web ing the service, which resides, by convention, Services from an existing structure. at the WEB server’s root directory. A discov- ery document contains pointers or endpoints to • .NET Class Libraries: Offer a collection of var- service descriptions and its locations. In the ious classes to built and manipulate Web Ser- case a client already knows the Web Service’s vices. URI, this step can be omitted.
• Web Services Description Language Tool: gera 3. The Web Service’s client requests then a ser- um código de serviços para XML Web Ser- vice description in the form of a WSDL docu- vices e serviços WEB clientes a partir de ar- ment, througth an standard URL, using stan- quivos WSDL e arquivos XML Schema Defini- dard HTTP. The then-returned WSDL docu- tion (XSD). ment contains all the technical informations needed to invoke the service (parameter list, • Web Services Discovery Tool: Discovers XML- data types, etc. ...). Web Services’s URLs located inside a WEB server and records locally documents and 4. The client then requests through the service a metadata related to each XML-Web Service. SOAP message containing the names of the methods, its parameters, etc. ... that it needs. • WEB References: It’s an graphical interface Then the XML Web Service processes the re- that incorporates the functionality of the Web quest and return a SOAP envelope containing Service Description Language Tool. the computed results.
11 There are various definitions of XML Web Services, which aren’t open neither shared by other develop- althought all definitions have some common points: ment tools aside Visual Studio.NET. There is a com- parison between these two technologies in the Table • XML Web Services exposes functionalities use- 2. It is possible envise their characteristics in rela- ful to the users through a standard WEB proto- tion to various points such as used interpreters, dy- col. In most cases, SOAP is the used protocol. namic WEB page or content servers, database ac- cess among others. • XML Web Services provides such way to de- scribe its interfaces with sufficient details, that it even allows the user to build an client ap- Characteristics .NET J2EE plication to talk to them. This description is Technology Profile Product Standard generally offered in a XML document called WSDL. Intermediate Solutions Microsoft 30+ Interpreter CLR JRE • XML Web Services are registered in such way Dynamic WebPage ASP.NET JSP that users can find them easily. That search is Generation .NET Management done through UDDI. Middle− tier Components EJB Components A comparison between the main approaches is Database Access ADO.NET JDBC, SQL/J shown below. SOAP, WSDL, UDDI Yes Yes Implicit Architecture Support Yes Yes 4.5 An Architecture Comparison (load− balancing, etc) Considering the mentioned information regarding the main proposed architectures, in this section we’ll analise briefly its differences and similarities to un- Table 2: Comparison between J2EE e .NET tech- derstand better its technologies and standards. nologies ([26])
.NET (Microsoft) J2EE (SUN) IBM Web Services HP Web Services
Technology .NET J2EE J2EE J2EE
Development Visual Studio.NET J2EE+JWSDP J2EE+WebSphere J2EE+Cocoon 5 Conclusion Environment
Server Platform Windows NT/.NET JVM Compliant JVM Compliant JVM Compliant
Services UDDI or another This paper tried to present the main Web Services UDDI UDDI UDDI Registry Directory System approaches, likewise its technologies and standards Service WSDL (DISCO WSDL WSDL WSDL Discovery document) as well. The different architecture implementations Communication SOAP SOAP SOAP SOAP Protocol shows the fact that standards such as SOAP, UDDI and WSDL represents a form to allow Web Services communication built among different platforms. Table 1: Comparison between Architectures We could note that companies like Sun, IBM and HP are redirecting their efforts to build their devel- The Table 1 represents a comparison between em- opment platform in a non-proprietary, standard fash- ployed technologies in Sun, Microsoft, IBM e HP ion, remarkably contrary to the Embrace and Extend proposals. The adoption of standard technologies characteristics regarding Microsoft’s .NET strategy. such as SOAP, WSDL e UDDI by the different com- The common effort to use standards built upon the panies is driven by interplatform operability objec- XML language allows that applications can commu- tive. We can note, however, the use of two concur- nicate between each other using a common, standard rent technologies such as J2EE e .NET. and human-readable messaging technology. By this J2EE technology is adopted by most of corpora- meanings, the programming language in which its tions whose efforts are being redirected to Web Ser- implementations are done becomes transparent. vices application development. Another Web Services Architecture’s visible char- Otherwise, Microsoft’s proposed technology acteristic is the possibility to create new applications seems try to integrate the Web Services architecture only composing and combining services that already to a proprietary layer, driven by the .NET classes, exists through the Internet.
12 References [13] Gudgin, M. ; Handley, M.; Moreau, J. and Nielsen, H. F. SOAP Version 1.2 Part 1: Mes- [1] Amrstrong, E.; Bodoff, S.; Carson, saging. W3C, October 2001. D.; Fisher, M.; Green, D and Haase, K. The Java Web Services Tutorial. [14] Gudgin, M. ; Handley, M.; Moreau, J. and http://java.sun.com/webservices/dowloads/web Nielsen, H. F. SOAP Version 1.2 Part 2: Ad- servicesturorial.html. Last access - juncts. W3C, October 2001. 16/04/2002. [15] Gudgin, M.; Hadley, M. Moreau, J.; Nielsen, H. F. SOAP Version 1.2. W3C, July 2001. [2] ARIBA, INC., International Business Ma- chines Corporation and Microsoft Corpo- [16] Hanson, J. Use Web services to in- ration. UDDI Data Structures Reference. tegrate web aplications with EISs. September, 2000. http://www.javaworld.com/javaworld/jw- 02-2002/jw-0208-eis_p.html. Last Access - [3] Bray, T.; Paoli, J.; Sperberg-McQueen, 22/02/2002. C. M. and Maler, E. Extensível Markup Language (XML) 1.0. Second Edition. [17] Hendricks, M.; Galbraith, B.; Irani, R.; Mil- http://www.w3.org/TR/2000/REC-xml- bery, J.; Modi, T.; Tost, A.; Toussaint, A.; 20001006. Last Access - October 2000. Basha, S. J. and Cable, S. Professional Java Web Services. Wrox, January 2002. 588 pages. [4] Brittenham, P.; Cubera, F.; Ehnebuske, D.; Graham, S. Understanding WSDL in a UDDI [18] HP Web Services Plataform Archi- registry, Part 1, September 2001. tecture - an oveview. October, 2001. http://www.bluestone.com/downloads/pdf/web [5] Brittenham, P. Understanding WSDL in a _services_architecture.pdf. Last Access - UDDI registry, Part 2, September 2001. 25/03/2002. [6] Box, D; Ehneubuske, D.; Kakivaya, G.; Lay- [19] Kao, J. Developers´ Guide to Building XML- man, A.; Mendelsohn, N; Nielsen, h. F.; based Web Services with the java 2 Plataform, Thatte, S.; Winer, D. SOAP: Simple Object Ac- Enterprise Edition (J2EE). Sun Microsystem, cess Protocol, April 2000. Inc. June 2001.
[7] Clarke, N. W. Silverstream and Web Services - [20] Kraft, Reiner. How IBM WebSphere A Technical Overview & Developer’s Perspec- Studio Aplication Developer Com- tive of SOAP, June 2000. pares with Microsoft Visual Studio .NET - Part1: Conceptual Differences. [8] Clements, T. Overview of SOAP Web Services http://www7b.boulder.com/wsdl/techjournal/02 - Tecnical Overviews. Sun Microsystems, Au- 02_kraft/kraft.html. Last Access - 27/02/2002. gust 2001. [21] Kreger, H. Web Services Conceptual Architec- [9] Cheng, J. and Xu, J. IBM DB2 ture. IBM Software Group, May 2001. XML extender. February 2000 www- [22] McLaughlin, B. Java and XML. O’Reilly, 4.ibm.com/software/data/db2/extenders/xmlext 2001, 528 pages. /xmlextbroch.pdf. Last Access - 26/04/2002 [23] Microsoft Corporation. XML WEb Ser- [10] Christensen, E.; Curbera, F.; Meredith, G. vices - A new Opportunity for ISVs. and Weerawarana, S. Web Services Descrip- http://www.microsoft.com/serviceproviders/str tion Language (WSDL), March 2001. ategicwp/xml_web_services.asp, 2001. Last Access - 25/03/2002. [11] Ehnebuske, D.; Rogers, D.; Riegen, C. V. UDDI Version 2.0 Data Structure reference. [24] Rajaram A. Overview of UDDI. Web Services June 2001. - Tecnical Overviews. Sun Microsystems, Au- gust 2001. [12] Graham, S.; Simeonov, S.; Boubez, T.; Davis, D.; Daniels, G.; Yuichi, N. and Neyama, [25] Seely, S. SOAP Cross Platform Web Service R. Building Web Services With Java. SAMS, Development Using XML. Prentice Hall PTR, 2002. 581 pages. 2002. 391 pages.
13 [26] Vawter, C. and Roman, E. J2EE vs. Mi- crosoft.NET - A Comparision of Build- ing XML-based Web Services, June 2001.http://www.midleware-company.com/. Último acesso - 25/03/2002. [27] Wahli, U.; Tomlinson, M.; Zimmermann, O.; Deruyck, W. and Hendriks, D. Web Services Wizardry with WebSphere Studio Application Developer. Redbooks - IBM. April 2002, 598 pages. [28] Wolter, R. XML Web Services Ba- sics. Microsoft Corporation, December 2001.http://msdn.microsoft.com/library/default .asp?url=/library/en- us/Dnwebsrv/html/webservbasics.asp?frame= true. Last access - 25/03/2002. [29] Yin, K. A Reference Architecture for Smart Web Services. Sun Microsystems, August 2001.
14