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

J2EE Journal: Article

Web Services: A Practical Approach

Web Services: A Practical Approach

Web services, designed primarily for companies to leverage their business services to a global market, also has value and benefits for companies at the enterprise level. Even if you choose to postpone your company's global Web services offerings, the integration and development benefits presented by Web services are worth investigating.

This article explores how to use Web services concepts and technologies to integrate your applications and make resources available to the entire enterprise by discussing these questions:

  • What are Web services?
  • What value do Web services bring?
  • What technologies are used for Web services?
  • How can you use Web services at the enterprise level?
  • How can you integrate different technologies with Web services?
  • What current development issues exist with Web services?
IBM has been a leader in the Web services field by helping to standardize Web service technologies, implementing tools to create Web services in IBM WebSphere, and providing one of the global Web service repositories.

Benefits of Web Services
Many businesses today are a conglomeration of disparate system architectures and technologies. Company mergers and differing departmental philosophies add to this mixture of systems and applications. Companies may even deploy multiple systems that provide overlapping or redundant business services to the organization. Web services can help you integrate your enterprise. By creating an enterprise-wide repository that registers all services, any service is available to any client, which speeds development, enables enterprise-wide access, and opens new revenue streams.

Web services can help to:

  • Implement a language- and platform-independent strategy
  • Integrate disparate systems and architectures
  • Enable access to legacy systems
  • Streamline business processes
  • Expand business channels
  • Build on the componentization and modularization of existing applications
Your company may not be ready to build a Web application based on Web services from an unknown company. In doing so you would be trusting the reliability of another company in a 24/7 marketplace. However, using Web services from a trusted business partner or building a Web portal for departmental exchange of information provides integration benefits to your organization and expedites your business processes. The advantage Web services brings to traditional enterprise application integration is an open standards-based framework to apply to the integration effort. The advantage IBM WebSphere brings to a Web services implementation is a full range of tools for creating and deploying Web services.

What Are Web Services?
A Web service is a component packaged and published in a service registry as a single entity that can be used by other programs. Using the Internet, a Web service can be published at the global level, allowing other companies to access it. Alternatively, by using an existing network or intranet a Web service can be accessible to an entire enterprise. Web services can be grouped together to provide greater levels of functionality, exposing a set of business processes, or even a set of applications.

An example of a Web service is a stock quote service that returns a stock price when given a specific ticker symbol. Any business process, such as a document retrieval process or an ordering system, can be engineered with Web services.

In its simplest form, the Web services model is a message-passing system. The breakthrough in Web services is that messages can be passed across different programming languages, different architectures, and different platforms.

Web services use a combination of new and existing technologies that allows any Web service to talk to another Web service. Since existing Web technologies provide the base for Web services, an existing Web server can easily become a Web services server. This, in combination with wide industry support, makes Web services a viable commodity.

The top part of Figure 1 shows Web services allowing Company A to place an order and receive an order confirmation from Company B. The bottom part of the diagram shows internal Web services at Company B being used to fulfill the order - verifying the customer, performing credit card validation through an external provider, and integrating all the legacy systems that control inventory management.

Companies have been solving integration challenges with proprietary solutions for decades. The power of Web services lies in bringing three things to the forefront:

  • Best-practice architecture
  • Open standards for true interoperability
  • Tools to rapidly apply the standards
Understanding the Web Services Architecture
In order to understand how Web services work, let's examine the components of Web services (see Figure 2). Web services are deployed in a service-oriented architecture (SOA) that consists of the following:

  • Service provider: Publishes the availability of its services in a registry and responds to requests to use its services
  • Service registry: Categorizes published service providers and allows searching of its registry
  • Service requester: Uses service registries to find a needed service and binds to that service

    Even at the enterprise level, this architecture is in place (although in enterprise configurations all of these roles could be performed by the same company) in order to complete the three Web services operations: publish, find, and bind.

    The company acts as service provider, publishing its Web services in a service registry. This registry can be behind the firewall for internal access or at a company portal for business partner access. Once the service is published, application developers, acting as service requesters, can access the registry in order to find the needed service and retrieve the service's interface description. The bind operation occurs as the service requester interacts with the service at runtime, using the binding details in the service description to invoke the service. In this way, valuable business processes can be shared across an organization.

    Applying Web Services Technologies to the SOA
    When you combine the SOA of the service provider, service registry, and service requester with service-oriented technologies, you get the Web services stack shown in Figure 3, with the upper layers of the stack building on the lower layers:

  • Network: At the bottom of the stack are the network layer and the basic communication protocols. A Web service must be available on a network. Communication protocols such as HTTP (Hypertext Transfer Protocol) allow transfer of data and access to applications over the network.
  • XML messaging: XML (eXtensible Markup Language) allows data to be structured in a platform- and language-independent manner. Unlike HTML, which uses a fixed set of tags to specify both the content and display of information, XML allows you to define your own set of tags that accurately describe the information and enable the presentation of the information to change depending on its use. SOAP (Simple Object Access Protocol) specifies an XML-based messaging protocol and provides an envelope for transferring XML data.
  • Service description: WSDL (Web Services Description Language) describes a Web service in an XML-based format.
  • Service publication and discovery: UDDI (Universal Description, Discovery, and Integration) specifies how to publish and find Web services.
  • Service flow: As the technology matures, Web services will be combined to provide greater degrees of functionality. WSFL (Web Services Flow Language) uses XML to describe how Web services interact to solve a business problem by modeling the basic workflow.

    The vertical bars in Figure 3 represent requirements that need to be addressed by all layers of the stack: security, management, quality of service, and transactions.

    Developing Web Services in the Enterprise Environment
    Defining Web Services

    To develop Web services in the enterprise environment, you must first define in your enterprise UDDI which services you want to make available. Any existing EJBs (Enterprise JavaBeans) or COM components, which are inherently modular in nature, are prime candidates for publication in a UDDI registry. In addition, you need to examine your legacy systems. Functionality in those systems can be wrapped as message-based Web services.

    Publishing Web Services
    Once the Web services are available, you need to publish them. There are tools available to automate this process, writing the necessary WSDL at the specified location. For IBM WebSphere, the Web Services Toolkit and WebSphere Studio Application Developer (WSAD) contain tools that will write the WSDL. By completing the steps in WSAD's Web service wizard you can:

  • Define a Web service based on an existing Java class, EJB, or Document Access Definition eXtension (DADX)
  • Generate WSDL and deployment descriptors for the Web service
  • Create a service proxy and client mappings
  • Create a sample test client, as illustrated in Figure 4

    Creating the UDDI
    By publishing the Web services, you create the UDDI. At the enterprise level, you can implement one or more of the following UDDI scenarios:

  • A private UDDI placed inside the firewall for applications within the company
  • An enterprise-wide UDDI placed inside the firewall for interactions within the company and with trusted business partners
  • A company portal UDDI placed on the firewall, allowing interested business partners to find Web services across the Internet but restricting access to published operations

    Developing Service-Based Applications
    Once the services are published they can be called from any enterprise application (see Figure 5). Even though Web services can be bound dynamically, a widely accepted practice is to look up the Web service during development and use its interfaces and methods in the application.

    Current Development Issues
    As of this writing there are two major divisions of Web services tool sets:

  • J2EE technologies used by vendors such as IBM, Sun, and Oracle
  • Microsoft's .NET technologies

    The J2EE technologies have been around the longest, making their solutions more robust in many areas, but since Web services specifications have been agreed to by all major vendors, different technologies can work together.

    There are several issues at the current stage of Web services, especially when implementing Web services at the global level:

  • Reliable messaging: How to determine if a particular message was actually received and was sent only once.
  • Dependability: How to determine the dependability of an unknown company in a 24/7 marketplace.
  • Security: How to make Web services secure if they use the HTTP protocol. HTTPR is a new protocol that has been proposed to address security concerns.
  • Transactions: How to complete transactions in the Web's stateless environment. In the past, transactional applications used a two-phase commit structure to determine when a complex transaction was complete and ready to commit to the database. Since this model is not available on the Web, new models for transactions are being discussed. One of these models uses a concept called dependency spheres, which allows both synchronous and asynchronous distributed messages to occur within a single transaction.
  • Payment for Web services access: How to be paid for Web services used by other companies.

    As Web services evolve, expect to see answers and specification changes that deal with these issues.

    Using Web Services to Integrate Technologies
    To illustrate how Web services can be used to integrate disparate system architectures, the sample application described in Figure 6 uses both EJB and COM technologies. The sample application was built with:

  • IBM Web Services Toolkit (a version was also built using WebSphere Studio Application Developer.)
  • IBM WebSphere 4.0
  • Microsoft SOAP Library (for the Microsoft clients)

    Contact information (name, address, and so on) in the sample application is stored in Microsoft Outlook and a DB2 database. Using Web services, you can update the contact information using either HTML or Visual Basic clients and those changes will be reflected in both data sources.

    The sample application consists of:

  • Proxies: These provide directly callable methods that map to SOAP services. They contain the service names and URLs of the Web service servers.
  • Helper beans: Helper beans call the proxies and hold and parse the data returned by the Web services. They contain read and write methods that make the service calls. They also contain get and set methods for data access.
  • JSPs: JSPs contain the user interface and call the helper beans in order to access and change all data. They also perform some data validation.
  • SOAP servlets/Apache pluggable service providers: These handle all incoming SOAP requests. The requests are parsed and the appropriate implementation is called. The service is defined in a deployment descriptor used when registering the service.

    Accessing Web Services
    When the sample application was implemented, it contained two SOAP services, one for each data source:

  • DemoOutlook: Provides an interface for reading and writing an entry in the Contacts section of Microsoft Outlook
  • DemoDB2: Provides an interface for reading and writing an Employee record from the Employees table in the DB2 sample database, which is part of IBM WebSphere

    Using a Java Client
    Access to a SOAP server through Java was done using a service proxy. Since the proxy interface is static, it needs to be changed or regenerated if the SOAP service is updated. The Java SOAP client does not access the WSDL file at runtime.

    Using a Microsoft Client
    Access to a SOAP server through VB or VBS was done using the Microsoft SOAP library. Unlike the Java client, the Microsoft client is dynamic. By simply initializing a SOAP object with the WSDL URL, all the service methods are available to be called.

    Future Directions
    One of the benefits of building an enterprise-based UDDI is that it can be upgraded for other uses. Even though its initial benefit is for internal enterprise integration, with trusted business partners it can later be used to move to global Web services. Major vendors such as IBM and Microsoft provide online access to the global UDDI registry in order to publish services or to search the registry for needed services or potential business partners.

    Web services are the future of e-business. Future visions of the Internet see applications primarily being hosted on Web servers, thereby encouraging access by all types of devices, not just personal computers. Web services can be used to provide access to those Internet applications, even allowing syndication of them to many Web sites.

    Web services also allow for greater automation of business processes since computer-to-computer communication across systems and architectures is easily implemented. This combination of communication, open standards, and multiple vendor support paves the way for Web services not only to expand, but also to transform e-business.


  • SOAP:
  • SOAP 1.1 Specification:
  • UDDI:
  • Web services:
  • Web services by IBM:
  • Web services on WebSphere:
  • Web services zone:
  • Microsoft .NET:
  • More Stories By Andrew Cohen

    Andrew Cohen is a senior consultant responsible for
    delivering distributed WebSphere solutions for global clients. He is a member of the Prolifics WebSphere Consulting Division, a staff of specialized consultants retained by IBM to solve the toughest of their
    customer's challenges and deliver training, mentoring, and
    development services.

    More Stories By Jan Hittle

    Jan Hittle is a WebSite Publisher and has authored several papers and best
    practice documents on topics including Application Development, Distributed Systems, Component-based Architectures and WebSphere Solutions.

    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.