SOA Architecture, Governance, and Industry Standards in the Enterprise

Paul Lipton

Subscribe to Paul Lipton: eMailAlertsEmail Alerts
Get Paul Lipton: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn

Related Topics: Java EE Journal, XML Magazine

J2EE Journal: Article

Web Services in a Wireless World

Web Services in a Wireless World

Conventional wisdom is a curious thing, especially when applied to a technology as new as Web services. Web services are often thought of as distributed business processes participating in a B2B relationship using Internet protocols and XML-based data standards. In fact, much of the introductory literature on Web services emphasizes that while most modern Web applications are designed to be used by human beings sitting in front of a browser, Web services are supposed to be used by some sort of automated service requester. The examples given in such texts frequently support such assumptions, but is this the only useful scenario?

In a typical B2B relationship, the actual client application logic is likely to be found in the middle tier of a distributed application of some sort. Frequently, but not exclusively, this middle-tier logic is a business object in the form of an EJB or .NET component. Fundamentally, this component's relationship with Web services is likely to be similar to its role with other components in a traditional distributed-object system based on CORBA, COM+, or Java technology. The component could be the client of more than one Web service, and it could be a Web service itself.

However, it becomes increasingly clear to many architects and designers that the business logic exposed by properly designed Web services is often coarser-grained than the logic exposed by so-called "business objects" in the more tightly integrated distributed object systems. In other words, Web services should usually function at a higher, more business-centric level than do middle-tier business objects in distributed Web applications.

Business objects, despite the name, are often not very business-like. To illustrate this concept, imagine some fairly officious "business EJB" carrying out requests to "update customer table" or "debit account." Indeed, this is often the level of functionality exposed by business objects in many distributed business applications. The level of business abstraction in most object-oriented, component-based systems is not very high. This may be a failure in design, but it's nevertheless often left up to the Web components (such as ASPs or JSPs) to coordinate these lower-level requests based on higher-level human instructions. These higher-level human instructions, precipitated at the browser level, function more truly at a real business level. For example, that very low-level business logic I just mentioned might be invoked by very high-level and meaningful human business decisions to do something like "join the book club" or "purchase a new bank service." Thus, it's fair to say that business components in applications based on tightly integrated, object-oriented technologies often function at a finer-grained level than Web services.

Web services function at a higher business level for many reasons. One of the most obvious is the overhead associated with parsing XML for each invocation of a high-level business function. An even more significant reason is the philosophical underpinnings of Web services as compared to highly integrated, object-oriented systems. Web services are typically applied to integration tasks rather than distributed application development tasks. This difference of purpose is somewhat subtle. However, Web services standards such as SOAP, UDDI, and WSDL were developed with much thought about issues closer to the EAI (Enterprise Application Integration) world, rather than distributed application development, and that has made all the difference, as the well-known poet (and erstwhile Web services consultant) Robert Frost once said.

When solving EAI problems, loose coupling is essential. Loose coupling means minimizing the dependencies between systems. People experienced with EAI know that dependencies between autonomous systems, possibly using radically different technologies, are very dangerous. Binary data formats can change, protocols can change, and parameters associated with business logic calls can change. The list of risk factors is endless, and you can never really trust either side to behave properly all the time. So, while tightly coupled distributed applications can be built quickly and can be very efficient (good goals for an application built within the enterprise or a corporate division where the IT department can exercise control), loosely coupled systems can potentially offer faster, easier, and safer integration beyond the firewall, or between any two systems that are based on different underlying technologies. Throwing away all the rhetoric, this is a very compelling value proposition for Web services.

Why Wireless?
Why should people interested in Web services also care about wireless? It's beyond the scope of this article to examine the demographics and analyst reports indicating an observable rise in the use of wireless technologies throughout the world. For the sake of discussion, I'll simply say that I believe the widespread use of wireless technology is both inevitable and around the corner, as long as your definition of corners is a couple of years long. In fact, many IT development projects now wisely incorporate some sort of long-term plan to support wireless devices. Certainly, the huge commitment of companies (e.g., Microsoft with its Smartphone technology, based on the compact .NET Framework; and Sun Microsystems with J2ME) illustrate that the software industry is taking wireless very seriously. Wireless companies, such as Qualcomm with their BREW platform, are also pursuing aggressive wireless software platform initiatives.

Unlike the business objects currently implemented in many Web applications, the ideal Web service is granular enough to expose meaningful business functionality. So why wouldn't end users want to take advantage of that business functionality on the many types of wireless devices that they're likely to use in the next few years for at least some of these Web services? Indeed, Web service creators may be driven to respond to this demand for increased accessibility and convenience by making their service available to an equally new generation of wireless end users, in addition to the more traditional service requesters from other systems. However, Web service creators who come from a traditional Web application development environment may find that the world of wireless presents new challenges.

To directly access Web services, end users need an application user interface for their wireless devices, as well as conventional PCs. In the past, the task was simpler. Designers of conventional Web applications experienced a relatively restricted range of client hardware. Their various display and navigational characteristics were fairly small and uniform. Many Web applications could reasonably assume a pixel-addressable color display of fairly high resolution (at least 640x480 pixels) running on a very small number of browsers. In fact, it was often sufficient for developers to ensure that the application worked properly with the various versions of IE and older versions of Netscape. Even the most forward-thinking developers often did little more than extend their development and testing to include the latest Mozilla-based browsers as well as the increasingly popular Opera browser. With a total of four HTML browsers at the most, and mouse-driven navigation of the user interface as the norm living within a high-resolution color display, development was a challenge that a good Web team could master.

Achieving WS2C
The very diversity of wireless devices currently poses a different sort of challenge for creators of new end user-enabled Web services: Web Service to Consumer, or WS2C. There's an incredible diversity of device hardware, navigation styles, displays, and operating software available for these devices. While certain enterprise applications will be able to mandate the wireless device type for clients, many Web services developers won't have that power over their end users. Hardware designs in the wireless world are far from standardized. Displays vary in color depth and resolution, with the displays of the simplest devices limited to black and white characters instead of color pixels. Navigation can be by many mechanisms, including arrow keys or a pen. Memory and processor speed are very diverse, and the resident software platform can be a thin-client browser or a fat client. In addition, many vendors are vying for a share of the action.

Note that despite all the posturing by vendors, there's truly no market leader in the wireless market. Just the opposite is true, so it's difficult to limit the breadth of support for wireless devices. Furthermore, the diversity of devices, from PDA/phone combinations to unusual form factors and software capabilities, will only increase. Nor is it certain that the new, fatter-client wireless devices based on technologies such as J2ME, BREW, and Smartphone will rapidly replace the hundreds of millions of WAP-enabled phones currently in use. In fact, it may be more appealing in some markets to use less complex phones and their simple browsers. The only safe assumption is that many devices and technologies will continue to fight for market dominance for some time, as both the bandwidth and the usefulness of wireless devices increase.

Thus, those building business-level Web services that are WS2C-enabled over the next year or two will be faced with an interesting challenge. In the past, exposing business functionality over the Web has meant writing a Web component, such as an ASP or JSP, consisting of some fairly static markup (typically HTML) along with logic to coordinate lower-level calls to business objects. Certainly, such an approach could be used to front-end a Web service either by directly accessing the Web service or by using an underlying business object like an EJB. But, does this architecture make the most sense in today's world of extremely diverse clients?

Writing a different Web component with the appropriate markup (WML, XHTML, etc.) for all the different wireless browsers in the market now and in the future would make maintenance quite difficult. For more intelligent devices, it might be sufficient to directly pass the XML derived from the Web service to the wireless device for parsing and display. Thus, the ability to sense the client type and dispatch very different transformations of XML data (or none) to a client becomes important. That's why wireless technologies embedded in server-side middleware like some of the various Java application servers and .NET feature some sort of transformation technology to sense the client type and dynamically convert the content to a format acceptable to the device.

Many wireless technologies offered by middleware vendors require the addition of special markup tags or instructions in their Web components so that transformations to various wireless devices can be done intelligently by the server. This is often a less obvious aspect of committing to a middleware vendor, and the result ties one to that vendor tightly. Since there are no leaders or dominant standards for such technology, it might require significant effort to port the wireless application to another vendor, even if both vendor products are based on the same underlying technology, such as Java.

Architecturally, it may be best to consider placing the wireless support closer to the end users. Transformations at this level can be independent of the underlying middleware. This shields the enterprise from having to commit to a single underlying technology like J2EE or .NET for wireless initiatives. Many decision makers are still hedging their bets between these two competing technologies at many levels, and wisely so.

The corporate portal, which inhabits a tier much closer to end users, is already an important part of any proposed WS2C solution for many enterprises, as it provides the personalization and security necessary to make a Web service truly useful, secure, and accessible to end users. It will also be the essential role of portals to support that same personalization and security on a wide range of wireless devices. Given the diversity, rate of change, and lack of leadership in the wireless industry, wise architects and decision makers incorporating portal technology as part of their infrastructure will need to ensure that their portal has wireless support that is truly open, extensible, and standards- compliant.

More Stories By Paul Lipton

Paul Lipton is VP of Industry Standards and Open Source at CA Technologies. He coordinates CA Technologies’ strategy and participation in those areas while also functioning as part of CA Labs. He is co-chair of the OASIS TOSCA Technical Committee, and also serves on the Board of Directors of the open source Eclipse Foundation, as well as both the Object Management Group and the Distributed Management Task Force in addition to other significant technical and leadership roles in many leading industry organizations such as the OASIS, W3C and INCITS.

Lipton is also an approved US delegate to the international standards organization ISO, as a member of the subcommittee focused on international cloud standards. He is a founding member of the CA Council for Technical Excellence where he leads a team focused on emerging technologies, a Java Champion, and Microsoft MVP.

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.