Heather Kreger

Subscribe to Heather Kreger: eMailAlertsEmail Alerts
Get Heather Kreger via: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn

Related Topics: Java EE Journal, Apache Web Server Journal, XML Magazine, SOA & WOA Magazine

J2EE Journal: Article

Understanding the Web Services Vision

Understanding the Web Services Vision

Web services is the latest trend in distributed computing. Based on sending XML messages that are transported over the HTTP protocol, the initial work has created a distributed computing model that is simple, easy, and lightweight. Most importantly, it works over the Internet.

  • Simple Object Access Protocol (SOAP) has brought interoperability between disparate systems over the Internet, providing distributed computing based on open Web standards. This complements existing approaches to interoperability, for example CORBA or messaging standards.
  • Web Services Description Language (WSDL) provides a framework for describing Web services based on XML and XML Schema. WSDL allows different systems and tools to understand and communicate with services provided by other technologies and organizations.

    Two discovery technologies allow Web services to be discovered on the Internet or on a network:

  • Web Services Inspection Language (WSIL) allows a server to publish the set of services available for a particular domain.
  • Universal Description, Discovery, and Integration (UDDI) allows businesses to publish information about their business and the services it offers, and others to search the directory for businesses and services. Organizations can also use UDDI within their enterprise.

    Web Services Motivation

    The Web today is fundamentally designed around human-to-machine interactions, with little semantic description. Now there is a requirement for a Web-based technology that supports application-to-application communication. This is driven by a number of needs, including:

  • The "Portal" model: Many companies have developed highly customized Web sites where users can access the majority of information, content, and function that they require from a single consolidated Web page. This model requires Web sites to communicate with each other.
  • The growth of electronic business-to-business transactions (B2B): Many standards exist for B2B, including EDI, RosettaNet, cXML, and others. These traditionally solve well-defined, systematic approaches to B2B. The growth of the Internet has put pressure on the technology to provide lightweight, inexpensive Web-based communications standards for B2B, with special focus on dynamic discovery and self-description of services.
  • Enterprise Application Integration (EAI): Many companies have put in place integration of applications across a wide variety of technology. In order to create efficient and effective channels to market, it is often necessary to connect together systems as diverse as mainframe systems, customer relationship systems, databases, accounting systems, and Web application servers. The push to e-business has meant that businesses are exposing their processes and systems directly to customers over the Web.

    We believe Web services offers a number of core benefits that allow application-to-application communication over the Web or intranet.

    XML and Open Web Standards:
    XML and HTTP are important because they offer:

    • A technology-neutral approach
    • Universal availability
    • An appropriate document model for loosely coupled systems
    • A vendor-neutral approach
    • Support for existing Web infrastructure like firewalls.
    Services-Oriented Architecture
    Web services focuses on describing the interactions between parties rather than the provider of the service. In particular this is important for distributed heterogeneous communications, where the implementations may vary significantly, but the interface should be constant.

    Description and Discovery
    The combination of WSDL and UDDI allows someone to search and locate a service, and create a client to that service - without requiring access to code repositories, common technologies, or even the same tools as the service provider. This organizational loose coupling has been a major driver to the growth of the Web. For example, many Web sites benefit from links, both to and from their Web sites, which did not involve any organizational involvement between the Web site owners.

    Messaging and Request-Response Models
    Typically, there has been a split in the technologies between tightly coupled request-response (RPC) behavior, and loosely coupled messaging systems. Both SOAP and WSDL accommodate both models in a single set of standards, making them suitable for both client-server and integration (B2B and EAI). This unifies the programming model for cross-Internet integration as well as supporting existing intra-enterprise optimizations. In this article we present a wider view of Web services as the basis of a services-oriented architecture (SOA). In particular, we show how Web services can be used in the portal, B2B, and EAI models, and how the notion of description and discovery can be extended to provide a rich model for interaction across multiple technologies.

    Building and Using Web Services
    The Web services standards only describe the outside interface of a service. Those interfaces imply some internal structure and semantics but the requirement to implement a Web service is very minimal. A number of technologies can be used - for example, simple Java classes; Enterprise JavaBeans; scripts such as VBScript, Python, or JavaScript; or C/C++ programs or objects can all be the implementation of a Web service. In fact, many other technologies, such as relational database stored procedures or legacy transactions can also implement Web services. There are three common models.

    Bottom-up Development
    An existing application function, such as an Enterprise JavaBean component or Java class, is exposed as a Web service. A tool examines the structure of the component, and generates the Web services description (WSDL file), which may be published using WSIL or UDDI. Often the tool will also generate deployment information, which configures a server to support and provide that service - to configure the SOAP support and other protocol enablement, and to "route" incoming requests to the underlying original component. The component does not need to understand XML, SOAP, or other formats, as the server transforms the SOAP request into the invocation mechanism of the original component.

    Tools which support this include the IBM WebSphere Studio Application Developer, IBM Web Services Tool Kit, and the Axis Java2WSDL. Once the component is deployed, users can download the published WSDL description and use any WSDL-aware tool to create a stub or proxy object. That object gives them an interface in the language they are programming in, such as a Java class or .NET business object, which can be invoked and will generate the SOAP message across the network.

    In this model, the service definition exists already. For example, a parcel delivery firm wishes to implement a Web service that allows tracking of parcels. There is an existing common interface, which is published in UDDI as a tModel. The developer of the Web service downloads the WSDL from the Internet, and uses a tool to create a skeleton. The skeleton is a component that has the structure but no business logic. The developer then creates the business logic that accesses the existing parcel tracking system. The new component calls the existing business logic, but exposes it with the common Web service interface. The service is published in UDDI with the same tModel as other parcel tracking systems. Existing parcel tracking clients, written to that tModel, are able, to invoke the new service.

    There is a third model - top-down - which we will address later. This model is similar to meet-in-the-middle, except that new business logic is necessary to implement the service.

    Implementing Web Services in a Java Environment
    Recently, there has been a great deal of work on Java standards for Web services in the Java Community Process, creating standards for using, developing, and deploying Web services in the Java and J2EE environments.

    3.1 JAX-RPC
    The Java API for XML-RPC (JAX-RPC) is a standard which defines to invoke and interact with Web services. JAX-RPC allows a user to access a stub or proxy for the service, or to use a Call interface that offers more direct access to the underlying SOAP invocation. JAX-RPC also defines a standard mapping from WSDL to Java interfaces, allowing tools to generate standardized interfaces for accessing Web services; in addition, the specification defines a standard mapping from Java interfaces to WSDL descriptions. At the time of writing, the JAX-RPC specification was about to become final. The Apache Axis project is currently building an implementation of JAX-RPC.

    JSR109 - Implementing Enterprise Web Services
    JSR109 is the ongoing standards activity on how to implement Web services in a J2EE environment. Included in the standard are:

    • How to implement Web services in a J2EE environment consistent with the J2EE programming model
    • How to deploy Web services implementations in a J2EE environment
    • How to locate Web services from within a J2EE environment
    • How to use Web services as a client consistent with the J2EE programming model
    • How to protect and secure Web services using J2EE security technology
    JSR109 adds Web Services deployment descriptors to support deployment of Web services. It builds upon the view of Web services provided by JAX-RPC and supports the deployment of JAX-RPC clients and service implementations. At the time of this writing, JSR109 was about to enter Public Review.

    Other Standards
    There are a number of other Java specifications and open-source contributions available or being developed. Some of the more significant ones for Web services are:

  • JWSDL: A simple, extensible API for reading, writing, and creating WSDL documents, backed by an open-source implementation.
  • JAX-B (XML Binding): Defines how to translate from Java classes to XML schema and back again.
  • JAX-R (XML Registries): Defines an API for accessing service registries including UDDI and ebXML Registry and Repository.
  • J2ME Web Services Specification: For use of Web services on pervasive devices; this is just getting started.
  • XML Digital Signature, XML Digital Encryption, and XML Key Management: JSRs that are developing Java bindings for their respective standards in the W3C's SOAP-SEC standard.
  • UDDI4J: An open-source API used to access UDDI directories.

    So far we've seen how the base Web-services standards fit together, and how they are implemented in a real environment. Now let's take a look at how we can use this technology, both in a B2B environment and in an EAI environment.

    Using Web Services in a B2B Context
    There are a number of initiatives for doing business-to-business electronic commerce. In particular, Electronic Data Interchange (EDI) has been very successful amongst large companies improving their supply-chain management. RosettaNet is another standard that has had success - especially in the electronic component marketplace. However, both of these initiatives, while successful in their own niches, have very limited success relative to the evolution of the Web and broad, cross-industry acceptance of HTTP, XML, etc. The result is that many companies are looking to leverage Web standards to build B2B solutions for e-commerce and e-business. We see the use of Web services developing very rapidly in B2B.

    There are two issues around this area.

    • Security and management
    • Process and conversation management
    One approach to addressing security and management is the use of a gateway. A gateway is a control point for external interactions. The gateway fills a role for B2B similar to what firewalls provide for more traditional uses of HTTP. For example, the gateway can provide an extra level of security and authorization, and logging of both incoming and outgoing service interactions. In addition, a Web services gateway can provide a layer of indirection and protocol switching, which adds security and allows enterprises to use existing protocols and still provide Internet protocols for external users. IBM has made available a Web Services Gateway Preview.

    The second issue with using Web services in a B2B scenario is that currently Web services are strictly "one-shot" interactions, whereas typical B2B interactions are ongoing, bi-directional, long-running, and correlated. However, there have been some proposals on how to manage a set of interactions as part of a process. In particular, XLANG from Microsoft and the Web Services Flow Language from IBM both address this issue. It is likely that a common cross-industry standard will emerge which will allow standardization of the processes between companies using Web services.

    Using Web Services in an EAI Context
    A number of vendors and companies have seen Web services as an approach to support Enterprise Application Integration. Many first Web services projects and pilots have been based on connecting Microsoft COM systems to Java and CORBA systems: for example, using J2EE as their application server and using COM-based Windows tools to build the clients. SOAP and WSDL allow them to create simple proxy objects on the client, which can invoke services running on the server in an effective manner.

    This approach also ties into the work many organizations began in 2000 and 2001 to standardize their internal integration on XML languages. Many companies built integration on top of industry-standard XML grammars, and this architecture fits very readily into the Web services paradigm. SOAP and WSDL support document-style interaction: in this model, the SOAP envelope is used to transmit an XML document that is defined by an existing XML Schema, allowing SOAP to be used as a messaging format for existing XML languages.

    A number of packaged application vendors have identified this as an approach to open up their systems to simple lightweight access, and this is likely to increase the use of Web services technology as a basis of EAI.

    There have traditionally been two very different approaches to integration. One approach is generally based on asynchronous one-way messaging, which is used to integrate widely divergent systems across large geographies and different technologies. This approach is typically based on document interchange. The other approach is based on tightly coupled synchronous integration, for example using remote procedure calls or CORBA and its description language (IDL) to call objects directly. This is typically used in single locations, with high-bandwidth, highly available systems, and is typically based on strictly typed interactions. Both SOAP and WSDL include both of these concepts: RPC-based interactions using typed interfaces and document-based one-way messaging. This gives Web services a very powerful approach to subsume and support both approaches.

    Web services need to meet the existing level of expectation in EAI technologies. There are a number of high-quality (and high-cost!) EAI technologies that offer essential facilities such as transformation, adaption, process management, reliability, high performance, monitoring, and metadata repositories. Web services offers a different set of benefits: low cost of entry, open standards based, and truly heterogeneous.

    Moving Beyond SOAP to a WSDL-Centric View
    WSDL forces a true separation of interface and implementation. This allows a separation of the business logic and the infrastructure - and is probably the most important aspect of the SOA. In general, application developers should concentrate on the abstract interface defined by the interface, and the deployers and administrator should concentrate on the infrastructure.

    As stated earlier, SOAP is the key component for building systems that can interoperate across the Web, but the real benefit of Web services is for building distributed systems where the service implementation is unimportant to the user of the service. What is important are the interface and its description. This motivates us to move our attention from SOAP to WSDL, and in particular to developing our models based on the interface or PortType of a service.

    There are a number of approaches and technologies that are being developed that take this approach.

    Top-down Development
    Earlier we described bottom-up and meet-in-the-middle development. The other approach is to do top-down development. In this model, the business analyst builds a UML model or business process. This is an abstract description of the interaction or the process. From this the WSDL PortType can be generated. Outside of Web services, this model is used very successfully as it tends to produce systems that closely match the requirements and the business model. From a Web services viewpoint it also works well because it fits the Web services model, and tooling exists to then create implementation objects from the WSDL definitions. This scenario describes an approach known as Model-Driven Architecture.

    Business Process Management
    Once sets of services are available via SOAP and described and published, it becomes very desirable to be able to build new processes using those services. Typically, programmers in the past have used programming languages to code the flows of a process, in which it is very easy to capture the "success case" - the normal handling of a particular process. However, often the fault cases are complex. In particular, if the individual activities in the process are distributed and loosely coupled - for example provided by another organization across the Web - then we need to have smart compensation logic in order to handle the fault cases, because traditional two-phase commit protocols are not appropriate in loosely coupled environments.

    A different model is to describe the process using a business process description language. These "flow" languages capture the relationship between services and the steps in the business process. An engine then runs this process, and if faults occur, the engine takes appropriate compensation action. Work is ongoing to develop a standard Web services language for describing business processes, where the process is described completely in terms of the interfaces/PortTypes of the individual services, and the bindings are defined at deployment time. Building business processes becomes a matter of composing existing services.

    Web Services Invocation Framework
    Earlier, we described how WSDL was inherently extensible, and independent of implementation type. Adding extensibility elements to WSDL allows the creation of descriptions of other service implementations than SOAP. Typically, Web services are implemented using existing application components - such as Java classes, Enterprise JavaBeans, or COM objects. These components are also sometimes wrappers onto legacy systems, such as mainframe transaction systems. We can capture the dependence relationship between these by extending WSDL to describe the existing component models, the exposed SOAP-available service, and the underlying component. In effect, we are adding the description capability of the SOA to the existing component model.

    WSDL is not just a description layer - it has a real implementation in tools that can use WSDL descriptions to generate stubs that can access the services. So if we add descriptions of non-SOAP systems, we are in danger of losing that benefit. The Web Services Invocation Framework (WSIF) addresses that. Effectively, it is a pluggable framework, that allows providers to be plugged in. A provider is code that supports a WSDL extension and allows invocation of the service through that particular implementation.

    This means that the client code is independent of the implementation. WSIF also allows late binding, where an existing client can use a new implementation at runtime - even over a new protocol or transport. WSIF also allows the infrastructure and runtime to choose the best implementation on the basis of quality-of-service characteristics or business policy.

    Provisioning is the ability to host services and charge clients for their use. For the Web services vision to become real, it will be necessary to be able to sell services and to identify who is using them, and how often. Provisioning is not based on the underlying SOAP message, but instead on understanding the range of services and how they fit to contracts. In order for a service to be provisioned, there must be a contract with a given identified user or organization, and then each use of the service must check if there is an applicable contract and then be metered. From the metering, a rating engine can identify the cost under the right contract and generate an invoice for the usage.

    The Web Service Hosting Toolkit (WSHT) is a toolkit that offers the ability to provision services, irrespective of how they are implemented and deployed.

    In this article we have seen a progression, from the base Web services standards bringing point-to-point interoperability using XML and HTTP, all the way to dynamic invocation and composition of services using higher order description languages. Our vision is of an SOA that:

    • Encompasses both messaging and RPC approaches
    • Supports discovery and description of services
    • Enables both business-to-business communications and enterprise application integration
    • Allows composition of services into business processes
    • Enables the metering, monitoring, and contracting of services
    In our vision of Web services, there is a clear distinction between the business logic process and interfaces and the underlying infrastructure that provides them, through meta-data and XML descriptions such as WSDL and process descriptions.

    We recognize that there is still a long way to go in the Web services technology for the greater marketplace - in particular, there are requirements to address and standardize:

    • Composition and choreography
    • Complex end-to-end security models
    • Support for reliability
    • Business transaction models
    • A framework for business trust
    These efforts are underway, but that shouldn't stop the technology from being used today. The production environments exist to allow Web services to be deployed, described, published, and accessed today. Early implementations exist that show how Web services can be exposed to partners, composed, and provisioned. Finally there is a vision and a roadmap that is shared by a number of vendors that are delivering on a new service-oriented model of computing.


  • Standards: www.w3.org and www.uddi.org.
  • Java Standards: www.jcp.org.
  • CORBA, UML, and MDA: www.omg.org.
  • Web Services and Open Source Portal: www.ibm.com/developerworks.
  • Open Source Web Services: http://xml.apache.org.
  • IBM WebSphere: www.ibm.com/websphere.
  • IBM Previews: www.alphaworks.ibm.com.
  • More Stories By Heather Kreger

    Heather Kreger is IBM’s lead architect for SOA Standards in the IBM Software Group, with 15 years of standards experience. She has led the development of standards for Web services, Management and Java in numerous industry standards groups including W3C, OASIS, DMTF, and The Open Group. Heather is the author of numerous articles and specifications, as well as the book “Java and JMX, Building Manageable Systems,” and most recently was co-editor of “Navigating the SOA Open Standards Landscape Around Architecture.”

    More Stories By Donald F. Ferguson

    Don Ferguson is Corporate Senior VP, Distinguished Engineer, Chief Architect Products and Technology at CA. Formerly, at IBM, he was the visionary behind WebSphere.

    More Stories By Sanjiva Weerawarana

    Sanjiva Weerawarana is a research staff member in the Component Systems Group at IBM's TJ Watson Research Center. He is one of the coauthors of the WSDL and WSFL specifications, and a codeveloper of Apache SOAP, WSTK, WSDL Toolkit, WSIF, and WSGW. He holds a PhD in computer science from Purdue University.

    More Stories By Paul Fremantle

    Paul Fremantle is a Web services architect in IBM's Hursley Laboratory. Paul has been working with Java, XML, and Web technologies since 1994, and is one of the architects of IBM's Web Services Invocation Framework and the Web Services Gateway. Paul is the coauthor of The XML Files, an IBM Redbook, as well as technical papers on WebSphere. He has an MA in mathematics and philosophy from Oxford University and an MSc in computation.

    Comments (0)

    Share your thoughts on this story.

    Add your comment
    You must be signed in to add a comment. Sign-in | Register

    In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.