Web Services: A Business Module Packaging Strategy

Date: Apr 2, 2004

Return to the article

The World Wide Web (WWW) has created a rapidly expanding need for application-to-application communication. To promote interoperability and extensibility among these applications, as well as to allow them to be combined in order to perform more complex operations, a new standard was needed that was backed by the entire software industry. That standard is web services.

As web services become more mainstream and enterprises start adopting a service-oriented architecture (SOA) for their application infrastructure, we need to analyze best practices and/or guidelines with this approach. This article begins a series on the best practices for XML-based web services. Through this series, we will evolve a potential framework for web services that could be leveraged by an enterprise. In this first article, we explore the use of web services as a packaging strategy for a business logic module. We'll start by providing some background information on web services that leads us to the rationale behind having web services as a business module packaging step.

Distributed Technologies

Web services provide a standard means of interoperating between different software applications, running on a variety of platforms and/or frameworks. Various other technologies have had the same goal—enabling remote access for a software module such as CORBA, RMI, DCOM, IIOP, or RPC. Each of these technologies has inherent strengths in solving specific issues in specific scenarios. But they all have glaring drawbacks with interoperability; for example, inability to be constrained on the operating platform, or restrictions on the programming languages they support.

Web services is a new addition to the distributed technology family. The wide popularity of web services is based on the fact that web services are designed with interoperability as the core principle. Web services follows the success of HTML and the browser that has led the way in demonstrating how human-to-computer interaction can be facilitated seamlessly regardless of the platform, technology, or overall application environment. This success has created demand to improve computer-to-computer or application-to-application communication in the same way.

Web Services Architecture and Web Protocols

A distributed system consists of discrete software agents that must work together to implement some intended functionality. The agents in a distributed system don't operate in the same processing environment, so they must communicate using hardware/software protocol stacks that are intrinsically less reliable than direct code invocation and shared memory.

To choose the right distributed system for a particular need, you must determine the system's data-sharing requirements. If all software agents share a common platform, it may be possible to use some other distributed solution for that platform—web services may not be the optimal solution for your needs. However, before you choose another distributed system, we strongly encourage you to look at what web services have to offer.

This is the first time in the history of the software industry when a distributed system is being endorsed by all the major players and thus will be well supported. Web services don't assume the processing environment you're in or the technology you choose. The web services approach is also focused on business, rather than being mired in low-level technology details, and thus enables service-oriented architecture in the true sense. Even if web services may not currently address all your requirements, your enterprise and system architects should consider the future potential and value of having an open architecture for distributed systems—and the pain that such an open architecture can alleviate—before deciding on another distributed system.

Web services are built to be interoperable between all processing environments (even embedded systems). This design requires the standards and protocols for the web services architecture to be nonproprietary and standards-based. Web services technology leverages a lot from existing web technologies. Let's consider a couple of these technologies that are relevant to our discussion: HTTP and XML.

HTTP as a Transport Protocol

Web services is an extension of the human-to-computer interaction that has been so successful with the Internet and the World Wide Web. A lot of technology—encryption algorithms, security protocols, digital certificates, tunneling through firewalls, and so on—has developed around the web and the Hypertext Transfer Protocol (HTTP) that the web uses to communicate across various processing environments. These technologies have made it possible for enterprise IT systems to consist of a single common infrastructure. Because web services primarily use the Internet as the medium through which services are accessed, the obvious choice was to adopt a related protocol stack rather than invent a parallel one. Web services use HTTP as the transport protocol to communicate across various software agents, and directly benefit from all that work and support that already exist for the web.

XML as a Messaging Format

To publish information for global distribution, you need a language that all computers can understand. The publishing language used by the web is Hypertext Markup Language (HTML), a language with predefined visual elements that have specific characteristics. But application-to-application communications requires transferring messages and transaction data between two systems, and the vocabulary for such transfers must be far richer than that of HTML. The solution is Extensible Markup Language (XML), which allows various enterprises and business entities to define their messages in a very rich format and in a nonproprietary way. It's an obvious choice for web services to use as a messaging format.

XML over HTTP Communication

XML over HTTP has been a preferred architecture for application-to-application communication, especially in web-based transactional applications. Web services formalize this method of communication, and will probably help it to further evolve and become more mainstream. Some of the evolution includes supporting multiple transport protocols (such as SMTP and FTP) seamlessly, and defining standards for discovery of these services. Web services have also defined new protocols:

• Web Services Definition Language (WSDL) describes a service and its interfaces.

• SOAP provides an "envelope" to exchange structured data.

Many other protocols and standards help to provide a comprehensive solution for application-to-application interaction.

The basis of the framework that we propose in this series is to build on the XML-over-HTTP model and selectively choose the new web services defined technologies to build a better enterprise solution.

Web Services for Coarse-Grained Business Logic

Both HTTP and XML are text-based formats and thus are more verbose than binary formats. The choices of technology and formats for web services were inherently not based on optimizing the exchange for performance or verboseness of the transfer. Other factors were more important: interoperability, wide-ranging support, using existing web technologies, leveraging infrastructure to go through firewalls, viewing the messages flowing through the wire easily with XML. As a consequence, the roundtrip delay in response while accessing a web service likely will be far higher compared to other distributed technologies. To keep the response time within acceptable limits, the expectation is that the service module would process a more coarse-grained functionality or even do composite tasks together to avoid multiple roundtrip delays. This plan makes web services better for exposing coarse-grained business functionality rather than a fine-grained operation.

This may be a perfectly reasonable expectation for distributed systems. Until now, we were forced to think about distributed technologies with low-level technical details such as the data objects to exchange, the programming language to communicate, and the platform constraints. The most basic scenario fulfilled by XML web services is that of providing some fundamental piece of business functionality for clients to use and define the interface at that high level.

Web Services for Loosely Coupled Systems

Two systems are considered loosely coupled if the only mandate imposed on both systems is to understand the aforementioned self-describing, text-based messages. Tightly coupled systems, on the other hand, impose a significant amount of customized overhead to enable communication, and require a greater understanding between the systems.

By using XML-based messaging as the mechanism by which the service is created and accessed, both the web services client and the web services provider are freed from needing any knowledge of each other beyond inputs, outputs, and location. A high degree of abstraction exists between the implementation and the consumption of a web service.

Loosely coupled and coarse-grained characteristics make web services very suitable for exposing high-level business functionalities, and a good distributed platform to expose a business module.

Business Module Packaging

A business module is implemented to provide specific functionality. The interface to the module is published for clients to interact with it. For in-process communication with direct invocation capability, it could make a direct call to the API. For remote access, the interaction would be through a distributed technology mechanism. In either case, the decision to expose the business logic remotely through web services or direct invocation has no relevance in defining the business module interface. The interface definition is the responsibility of the business module owner, and it should be defined independently of how it gets exposed for remote access.

This is the gist of this article. Web services have been determined to be a preferred way to expose a business module. However, the decision to use web services (or any other technology) is independent of the definition of the business module interface or its development. With this approach, the business module can be developed in isolation, and the decision to use a suitable distributed technology can be determined after the fact. If necessary, we could choose multiple technologies to expose the business module remotely and widen its accessibility. The architecture of such a proposed integration is detailed in Figure 1.

Figure 1 Web services architecture.

Web services act as a packaging layer to the business module. Separating the business module from the web services layer, as shown in the figure, helps in clearly defining the roles and responsibilities for software development within an enterprise.

Web services have WSDL as a means to define the interface, but using WSDL to define the business module interface defeats the purpose of choosing web services, because it ties you to using only the web services technology stack. It's in the interest of the business module owner to have the flexibility to seamlessly change the infrastructure and the distributed technology it uses to communicate with other applications or services. Also, multiple infrastructures could be deployed simultaneously to provide distributed access to the same business module. This is a very common mistake, causing non-portable business modules that cannot switch the distributed layer seamlessly. Many projects start by writing WSDL for their service/business module interface. But WSDL is a web services technology and shouldn't be used to define the core business interface. If you use WSDL to define your interface, and web services are eventually replaced by a newer technology, your business module interface would have to be redefined again in the newer technology.

The interface is the key-binding contract between the consumers and producers; having to change the interface purely due to adoption of a new technology is highly undesirable. Even worse, the interface definition change most likely would break existing clients, because it wouldn't be compatible with the old technology specification. All of this, even while the real interface to the business module is unchanged. This change in interface due to a technology change may be considered poor design.

In the next article, we'll take a closer look at best practices to define the interfaces for your business logic module in greater detail. Subsequent articles in this series will exploit this architecture further and evolve a framework to automate packaging of any business module as a web service.

© 2024 Pearson Education, Informit. All rights reserved.

800 East 96th Street, Indianapolis, Indiana 46240