3.3 Web ServicesThe Evolution

3.3 Web Services ”The Evolution

3.3.1 What Is Web Service?

The term Web Services has become a buzzword in the industry recently. With the change in the economic landscape, there is an increasing interest in pursuing cost-effective solution development and implementation by Application Service Provider (ASP), out-sourcing, or out-tasking.

On the other hand, Business-to-Business integration (B2Bi) has always been a hot subject with the emergence of more e-Marketplace and Exchanges. Traditional point-to-point interfaces and proprietary message structures become difficult to manage as the number explodes exponentially. There is a need for an open standards-based, yet flexible solution for wide and speedy deployment.

These two driving forces have been crystallizing with the development of Web Services. Web Services are units of business services, applications, or system functionality that can be accessible over the Web (either Internet, extranet, or intranet). Web Services can enable legacy system functionality to be exposed as a reusable business service (for example, publish a legacy function as an API), without rewriting it. The technology can be used as a cross-system or cross-enterprise integration. This is particularly useful for outsourced or managed services interoperating with in-house applications.

What Is NOT Web Service?

It is usually easier to understand what a Web Service is by understanding what it is not:

• Yet another Enterprise Application Interface package

• A rebranding of CORBA technology

• A new technology that can develop and deploy applications with a few keystrokes using a wizard

• A common and agreed-upon standard for all application servers, database servers, or software products to interoperate with each other, without changing any piece of codes or customization

3.3.2 Web Services Features

Business services provided by existing system functionality are exposed to external systems as Web Services. This enables a legacy system to become a service-based or component-based architecture. However, the use of XML does not necessarily mean that the application is Web Services-enabled. SOAP is one of the key technologies for Web Services, but it is not the only technology (ebXML is another).

Applications and business services developed and deployed using Web Services technology have the following characteristics:

Loosely- Coupled Components . They are loosely-coupled (for example, messages are decoupled from the data transport) and are easy to integrate with other platforms and open standards technology. In other words, changing the implementation of one component does not require changing the rest of the services, which makes configuration and deployment easier to manage. They are also highly reusable.

Self-Describing and Adapting. Using XML technology for data contents and information exchange enables transactions and information to be self-describing and adaptive, without requiring a prior knowledge of the applications or the interfaces. Web Services technology uses the Web Services Description Language (WSDL) in the XML structure to define the interfaces, network connection, and service end-points. Only the business-level interfaces, rather than the fine-grained, low-level interfaces, need to be exposed. As a result, data is decoupled from process logic, which makes integration easier and cleaner.

Distributed and Location-Independent. The use of ebXML and UDDI registries enables business services to be location-independent and highly distributed. This also enables noncore (and even core) business services to be out-tasked to a specialized service provider, even in remote areas, at a lower total cost ownership, while maintaining control of ownership and integrating with the core back office systems. The "contracted" functions of the Web Services make use of publicly available standard description languages (such as WSDL). This enables business services to be discovered and bound/ unbound from the Web Services registries (for example, ebXML registries).

Dynamic and Extensible. As information and transactions are encapsulated in XML, they can be dynamically aggregated, transformed, and processed at real-time. Thus, the business services become more dynamic and easily extensible without rewriting the back-end systems.

Open Standards-Based. The architecture framework of Web Services is based on open standards technology such as J2EE , XML, SOAP, and UDDI, instead of proprietary or vendor-specific technology. This enables a wider choice of vendor solutions and easier integration between components, as well as easy migration to newer technologies later.

3.3.3 Web Services History

Web Services technology standards are often demarcated by the contributors ( mainly technology vendors ). They changed rapidly between 2000 and 2002. Table 3-1 traces the history of Web Services technology.

Table 3-1. Web Services Technology History

Web Services Standard	Version	Release Date	Status
Web Services Description Language (WSDL)	1.1	Mar. 15, 2001	W3C Note submitted by IBM, Microsoft, Ariba. Refer to http://www.w3.org/Submission/ .
	1.2	Jan. 24, 2003	Currently as W3C Working Draft. There is a new WSDL bindings (using WSDL with SOAP 1.2, HTTP/1.1/GET/POST and MIME) working draft. Refer to http://www.w3.org/TR/2003/WD-wsdl12-20030124/ and http://www.w3.org/TR/2003/WD-wsdl12-bindings-20030124/ .
Universal Discovery, Discovery, and Integration (UDDI)
	1.0	1999	Proposed by Microsoft and UDDI.org .
	2.0	2001	Managed by UDDI.org.
	3.0	July 19, 2002	Currently managed under OASIS. Refer to http://www.oasis-open.org/ committees /uddi-spec/ and http://uddi.org/pubs/uddi_v3_features.htm .
Simple Object Access Protocol (SOAP)
	1.1	May 8, 2000	Proposed by Microsoft, IBM, UserLand, Developmentor. Refer to http://www.w3.org/Submission/ .
	1.1 with Attachment	Dec. 11, 2000	Proposed by HP and Microsoft.
	1.2	Dec. 19, 2002	Currently as W3C Candidate Recommendation. Refer to http://www.w3.org/TR/2002/CR-soap12-part0-20021219/ , http://www.w3.org/TR/2002/CR-soap12-part1-20021219/ and http://www.w3.org/TR/2002/CR-soap12-part2-20021219/ .
ebXML Message Specification
	1.0	May 11, 2001	Managed by OASIS. Use SOAP 1.1 with Attachment as transport and routing.
	2.0	Apr. 1, 2002	Managed by OASIS. The standard is approved on Sept. 5, 2002.
ebXML Service Registry
	1.0	May 8, 2001	Managed by OASIS. Refer to http://www.ebxml.org/ specs /index.htm .
	2.0	Dec. 18, 2001	Managed by OASIS. The standard is approved in Dec. 2001.
	2.1	June 2002	Addressed typo and minor errors in version 2.0. Refer to https ://www.oasis-open.org/committees/regrep/documents/2.1/specs/ebrim_v2.1.pdf and https://www.oasis-open.org/committees/regrep/documents/2.0/specs/ebrs.pdf .

Implication

There are two major variants of Web Services standards (WSDL-UDDI-SOAP and ebXML) evolving in the Web Services space. WSDL-UDDI-SOAP technology has been gaining momentum with many vendor implementations in the past two years . ebXML uses SOAP 1.1 with Attachment as the transport and routing. It provides added values to Web Services with guaranteed messaging and workflow functionality. With JAX Pack, developers can use both variants of Web Services technology seamlessly.

It is important to understand the different value propositions , and when to use them. There are also trends toward the convergence and interoperability of two technology standards in the messaging and security areas.

3.3.4 Web Services Technology Stack

Figure 3-1 depicts different layers of the Web Services stack. It is followed by a short description of each layer.

Figure 3-1. Web Services Technology Stack

Structural Framework

Internet. The underlying network for services is the public Internet over TCP/IP

Transport. The underlying transport layer may be HTTP, SMTP, SOAP over HTTP, and so forth

Service Description Language. The business service is described in a common language that depicts the service type and functionality (for example, URI, ports, end-points)

Transaction Routing. Transaction routing of the data contents and transactions to the next business service node, using the lower transport layer with guaranteed (or without guaranteed) message delivery

Service Discovery. Search and locate a business service from Service Registry nodes

Service Negotiation. Agreement on what can be exchanged and is interoperable between the service requester and the service provider

Service Dimension

Management. Provisioning of services and monitoring and administration of services

Quality of Service. Different aspects of "ilities," such as availability and scalability

Security. Message and transport layer security to support authentication, entitlement, and nonrepudiation

Open Standards. For example, XML

Judith M. Myerson, in her paper "Web Services Architectures" (Tect, 2002), summarized 10 different Web Services Architectures: WebServices.org, The Stencil Group , IBM, W3C, Microsoft, Sun, Oracle, HP, BEA, and Borland. Myerson maintains that there is no single Web Services architecture, and each vendor or organization has its own Web Services architecture (this book refers to these Web Services architectures as "vendor product architectures.") She explains that this is because the "number and complexity of layers for the stack" vary by organization. In other words, Myerson does not think there is a single Web Services stack or architecture that is unique to every organization. She summarizes different Web Services architectures from various vendors and categorizes them in a complexity scale (refer to Figure 3-2). Some organizations may require a simple architecture, and some require a complex one.

Figure 3-2. Web Services Stack Complexity Scale

There will be more coverage of the Web Services Technology Stack in Chapter 4, Web Services Architecture and Best Practices.

3.3.5 Logical Components

Web Services typically consist of several key players, including Service Requester, Service Provider, and Service Broker, as overviewed in Table 3-2. Service Registry is used by Service Requester to look up relevant business services.

Table 3-2. Web Services Logical Components

Logical Components	Description
Service Requester	The consumer (such as the buyers , buying agents , or suppliers) who requests a particular business service, upon searching (discovering) a service registry.For example, a buyer who is browsing a catalog is a service requester for sourcing/purchasing. Typically, a service requester will use a standard protocol to discover the services from a service registry (for example, ebXML or UDDI). Once a service is found, the service requester will bind the service via a SOAP Proxy.
Service Broker	Intermediary or broker that negotiates, aggregates, and provides business services of a particular request on behalf of the service requester (for example, a buying agent is a middleman/service broker for buyers). Typically, they are like portals for information and services, or trading exchanges. The business services typically reside in standards-based repositories such as ebXML or UDDI. A service provider can be the Service Broker itself.
Service Provider	The service provider creates and supplies the business services or system functionality (as a producer role ”for example, a supplier is a service provider for retail services to buyers). Business services are published in standard description languages such as WSDL. The service requester produces the services with interfaces and descriptions that are available by standard protocols (of course, with appropriate security).
Service Registry	A Yellow or White Page that hosts all business services, and the associated service providers. It may be an ebXML or UDDI service registry.

Figure 3-3 depicts a typical scenario for using Web Services. The Service Requesters (in this case, Supplier and Buyer) are consumers of the business services. The Supplier is a client of the Service Provider. The Buyer is a client of the Service Broker. The Service Broker acts as an intermediary for different business services provided by the Service Provider. The Service Broker publishes their business services in a private Service Registry (both ebXML and UDDI Registries). The Service Provider also publishes their business services (using, for example, WSDL) in a private ebXML Service Registry and to the Service Broker.

Figure 3-3. Web Services Logical Components

The Buyer is interested in finding a specific business product from the Service Broker. The Service Broker also stores the business services provided by the Service Provider. During service discovery, the Buyer finds an appropriate business service from the Supplier via the Service Broker's ebXML Service Registry. Then the Buyer binds and invokes the business service.

Actions in a typical Web Services scenario may include:

Discover/Find. Searching for a particular business service, usually by a standard reference (for example, UN/SPSC number)

Query. Inquiring about the service, using a predefined set of parameters (such as URI or end-point)

Bind. Run-time binding of the service name , the end-point, and the actual URL; this is like connecting the phone line after the actual phone number is dialed

Publish. Publishing the business service to the Service Registry using a standard interface specification (such as WSDL)

Unpublish. Unpublishing the business service to the Service Registry using a standard interface specification (such as WSDL)

Service Registry Contents

WSDL is the standard interface definition depicting the business service provided (such as the port or URI that can access the business service). The standard interface also describes the message content (such as message name and data type), operation name (such as what method or action can be operated on the message content), and binding name (what data transport is used, such as SOAP over HTTP using Remote Procedure Call). This provides all information necessary for browsing business services (from a user perspective) and developing system interfaces (from a developer or system perspective).

Web Services Use Case

Figures 3-4 and 3-5 are in UML notation that describes the use case and the associated sequence diagram. Figure 3-4 describes five business scenarios or use cases about how Web Services are used. A Service Requester wants to browse through a Service Registry and inquire (or query) about different business services that interest her. Once she discovers the appropriate business services that she would like to use (or invoke), the Service Registry will bind the services with the remote Service Provider.

Figure 3-4. Web Services Use Case

Figure 3-5. Web Services Sequence Diagram

Service Brokers and Service Providers need to preregister with the Service Registry owner first. Upon successful registration, they can publish or unpublish their business services, which are usually published to the Service Registry.

In Figure 3-5, the Service Requester browses through a Service Registry, which contains different taxonomies of Service Brokers' or Service Providers' business organizations and their business services. Browsing through and looking up different taxonomies will initiate API calls such as find_business and find_service UDDI API calls (for UDDI Service Registry), or OrganizationQuery or ServiceQuery ebXML registry calls (for ebXML Service Registry). This is the process of discovering services.

Once the Service Requester has selected a specific business organization (either Service Broker or Service Provider), the Service Registry client will issue a query API to the Service Registry. If this is a UDDI Service Registry, it will be a get_businessDetail or get_serviceDetail UDDI API. If this is an ebXML Service Registry, the previous OrganizationQuery or ServiceQuery would have returned the business or service details in the registry query result already. The Service Registry will then return the organization information (such as business name, address, and contact person) or business service details.

If the Service Requester wants to use (or invoke) the business service immediately, the Service Registry client can issue a find_binding service call to locate the URI (Universal Resource Identifier, or the service end-point URL describing the Service Provider's service) specific to the business organization or service. Once the URI (or WSDL document) is retrieved, the Service Requester can initiate a SOAP call, based on the port type, the operation names , and the service end-point URL or URI. The service end-point URL refers to the business services that are denoted by URLs (such as http://mydemo.nextfrontiers.com:8080/soap/rpc ), and are hosted by the Service Brokers or the Service Providers.

If Service Providers or Service Brokers need to publish a new business service to the Service Registry, or to update an existing business service, they need to use several APIs to publish the business organization, business service details, and the service end-point URL. For UDDI Service Registry, there are a few APIs available, such as save_business, save_service, and save_binding (refer to details at http://uddi.org/pubs/uddi-v3.00-published-20020719.htm ). For ebXML Service Registry, the Service Registry needs to specify the business organization and service details in the SubmitObject requests (refer to details at http://www.ebxml.org/specs/ebrs2.pdf ). Similarly, if Service Providers or Service Brokers want to unpublish (remove business information) from the Service Registry, they can use the same set of APIs.

3.3.6 Web Services Architecture

There are a few Web Services architectures published by leading technology vendors. Among them, there are three significant ones put forth by Sun, IBM, and Microsoft.

Sun ONE Architecture Framework

The Sun ONE architecture framework consists of the following components:

Platform. The underlying hardware and storage platform

Identity. The security components (for example, authentication) and unified user management

Service Container. The Web and EJB container that provides the application services

Service Delivery. The delivery channels and the presentation tier

Web Services. The core business services deployable as reusable components

Service Integration. The integration between business services and legacy systems/resources

Service Creation and Assembly. Creation of contents and program codes

Implication

Sun ONE is evolving. It begins with a marketing flavor ("Service on Demand") to promote open standards. Sun hardware, storage, and Sun ONE solutions are the key underlying components. Figure 3-6 illustrates the Sun ONE framework. It now encompasses an architecture framework ( http://wwws.sun.com/software/ sunone /docs/arch/index.html ), a solution platform ( http://wwws.sun.com/software/sunone/overview/platform/index.html ), and support by a number of software products ( http://wwws.sun.com/software/sunone/ ). Zefer is a good reference example ( http://sunonedev.sun.com/building/tech_articles/webserv_refarch.html ) where the Sun ONE architecture framework is used to implement online portal services with wireless clients .

Figure 3-6. Sun ONE Framework

IBM Web Services Architecture

IBM's Web Services Architecture can be depicted by three models. It is primarily based on the existing WebSphere Application Server and WebSphere Studio (developer IDE tool) product architecture. Developers use WebSphere Studio to program Java objects and codes (programming model), and deploy in a J2EE run-time environment (run-time model).

Programming Model. Base Parts, Composite Parts, and processes (such as WSDL and XML Schema). Examples of Base Parts are Java Beans , stored procedures, the database XML Extender, and the Java Script scripting language.

Run-time Model. This provides the "back plane" servicing the host and providing management, security, trace, and workload management for the run-time components (for example, service bus, application server, UI components).

Development Tool Model. This is based on the WebSphere Studio software set. WebSphere Studio is a software branding that includes an HTML home page builder (WebSphere Studio Homepage Builder), Web site builder (WebSphere Studio Site Developer), J2EE application developer workbench (WebSphere Studio Application Developer/Enterprise Developer), J2ME development tools (WebSphere Studio Device Developer), and analyzer tools (WebSphere Studio Asset Analyzer).

There are two models for deploying Web Services:

Shallow Model. This model deploys business services under a Servlet Container (such as Tomcat) with Web Service support and pluggable Service Providers, which map services to URLs and HTTP. Thus, programmers only need to configure to publish services through WSDL and SOAP.

Uniform Model. This model extends the Shallow Model by encapsulating the Base Parts with a Java Bean adapter.

Figure 3-7 depicts IBM's Web Services architecture, which consists of a servlet container for the run-time environment of SOAP messages (run-time model). The servlet container also provides pluggable SOAP Service Providers, including SOAP WSDL servlets, SOAP providers (shallow model), and SOAP EJB providers (uniform model). These providers help to map SOAP messages to database objects using XML extender and stored procedures, as well as other servlets, portlets, and EJBs via middleware or data transport protocols such as RMI/IIOP, JMS, and MQ (programming model).

Figure 3-7. IBM Web Services Architecture

Implication

This architecture provides a structural framework to describe what Web Services components are available in the WebSphere Application Server and WebSphere Studio platform and how they support Web Services. More details can be found at http://www.redbooks.ibm.com/redpieces/ pdfs /sg246891.pdf .

In IBM's Web Services architecture, the centerpiece is the servlet container with different IBM-specific SOAP providers. These providers are tightly coupled with WebSphere-specific products and are unlikely to be reusable on other vendor platforms. The servlet container, which now supports Apache AXIS using WebSphere SDK for Web Services version 5.0, allows developers to use simple servlets (shallow model) or EJBs (uniform model) to invoke remote business services. IBM brands these application design options under the term "eBusiness patterns." There are good code samples available in IBM Redbooks, such as Peter Kovari and colleagues' "Patterns: Building Message-based and Transactional Applications" (February 2003) at http://www.redbooks.ibm.com/redpieces/pdfs/sg246875.pdf .

Microsoft Global XML Web Services Architecture

Microsoft sees XML Web Services as the enabling technology in business ecosystems for integration and interoperability for (1) Enterprise Application Integration; (2) interoperability with key partners ; and (3) interoperability across multiple companies. There are four design principles for Microsoft Global XML Web Services:

• Modular/Building Block Style

• General Purpose (for example, applied for B2B, EAI, P2P, and B2C independent of the application domains)

• Federated/Decentralized

• Standards-based (for example, SOAP, WSDL and UDDI)

Figure 3-8 depicts the Microsoft Global XML Web Services architecture. It is a high-level functional component, rather than a physical architecture. There are three key logical components. The first one is the "discovery" module, which consists of Microsoft UDDI registry server and provides the functionality of directory, inspection, and business service description. The second component consists of SOAP modules, which relate to the WS-Security roadmap published by Microsoft, IBM, and VeriSign. This provides the rules about SOAP message handling and business process orchestration. The last component is the infrastructure protocols, which provide reliable data transport and messaging.

Figure 3-8. Microsoft Global XML Web Services Architecture

Implication

There is a considerable number of developers who are using the Microsoft developer platform today. Understanding Microsoft Global XML Web Services architecture, its roadmap, and the proprietary Web Services extension is helpful in building interoperability between Java and .NET clients.

Although Microsoft claims to follow standards, there are many new and proprietary features of the implementation (or proprietary Web Services extension), such as:

MSXML (versus XML). Microsoft's implementation of XML is MSXML and has some proprietary extension. It is adhered to Internet Explorer browser only.

WS-Security. Microsoft's implementation of WS-Security supports XML Signature and XML Encryption and is provided by Microsoft's CAPICOM developer toolkit.

Please note that after IBM and Microsoft jointly published the new WS-Security roadmap, Microsoft's Global XML Web Services architecture changed because the security components were superseded by the new specifications WS-Security, WS-Policy, WS-Trust, WS-Privacy, WS-SecureConversation, WS-Federation, and WS-Authorization.

Comparing Different Architectures

Table 3-3 shows a simple summary of the three previous architectures.

Table 3-3. Comparing Different Web Services Architecture

	Microsoft	Sun	IBM
Web Services standards support (SOAP 1.2, WSDL, UDDI)	Yes	Yes	Yes
Web Services architecture/framework	.NET	Sun ONE	IBM Web Services
Comprehensive development environment and tools	.NET server .NET studio	Sun ONE Apps Server Sun ONE Integration Server Sun ONE Studio	WebSphere Application Server WebSphere Application Developer Studio
Expose EJB as Web Services	No (But can interoperate with other Web Services by exposing COM/COM+ objects through .NET interoperability.)	Yes	Yes
Synchronous (Sync) and Asynchronous (Async) message support	Sync ”DCOM	Sync ”JAXM, SAAJ Async ”JAX-RPC	Sync ”SAAJ Async ”JAX-RPC
Methodology to design Web Services architecture	No	Yes ”SunTone , J2EE Patterns	Partial ”eBusiness patterns
When to Use	Wintel PC platform only PASSPORT/Active Directory already in use	Open platform and interoperability	WebSphere platform with proprietary extension

References

SunTone Architecture Methodology can be referred to at Sun Professional Services, Dot-com and Beyond: Breakthrough Internet-based Architectures and Methodologies , Prentice Hall, 2001.

J2EE Patterns can be referred to at Alur Deepak, John Crupi, and Dan Malks, Core J2EE Patterns , Prentice Hall, 2001.

3.3.7 Benefits

Web Services technology enables easier interoperability between systems to aggregate information. It is a technology enabler for consolidating services (for example, UDDI Service Registry) and customer information (such as wealth management/eCRM). It is designed to enable developers to develop and deploy services quicker, compared with traditional technology tools. Besides, business services can be exposed to be easily deployable, reusable, and independent of the underlying platform.

Web Services technology is also an alternative to integrating with legacy systems without rewriting them. It resolves the firewall-unfriendly interoperability of RPC-based applications (for example, tight firewall policies often block RMI and RPC-based internal applications from external Internet access). Use of XML data transformation and message exchanges allows a simpler architecture (for example, consolidating interfaces and services), which may result in lower operating cost.