Helpful Links

This chapter focuses on technologies that, while promising, have not yet reached their market potential. Each of the technologies discussed here has been developed to improve upon previous technologies in the same space; in fact, the goal of each is to become the standard in its field.

The goal of this chapter is to introduce each of these technologies and explain how it relates to mobile computing. Thereafter, we will examine the reasons why it is expected that they will be able to survive in the very competitive mobile industry. The chapter starts by taking a look at Web services from a mobile perspective. Of the technologies included in this chapter, Web services are clearly the leader in market acceptance and standardization. The others, such as BREW, SALT and M-Services, are still working to gain meaningful vendor and developer acceptance.

Web Services

The W3C definition for Web services is as follows:

• "A Web service is a software application identified by a URI, whose interfaces and bindings are capable of being defined, described, and discovered as XML artifacts. A Web service supports direct interactions with other software agents using XML-based messages exchanged via internet-based protocols." (http://www.w3.org/TR/2002/WD-wsa-reqs-20020819).

Essentially, Web services are segments of business logic that are made accessible over the Internet. They can be incorporated into any application that can communicate with XML over HTTP. They may be incredibly simple, such as validating a user, or intricately complex, such as executing a business transaction across many systems in multiple organizations. In short, Web services will change the way Internet applications are assembled. This is quite a profound statement to make about a relatively new technology, but it is not at all unreasonable for the simple reason that Web services provide a standardized way for corporations to both publish their own applications and access other prebuilt applications over the Internet; and these tasks can all take place without requiring the participating parties to develop any formal relationship.

It is interesting to note that the idea behind Web services is not unique. Many other technologies provide similar capabilities (CORBA, Java RMI, and DCOM) but all in a more proprietary manner. Each is capable of providing remote access to business logic. But Web services are succeeding where others have failed because they provide the same services in a simple, standardized way. Web services use XML for communication, rather than the proprietary binary formats used by other technologies. In addition, Web services are both platform-and language-neutral; they can be implemented using any piece of middleware, based on J2EE, .NET, CORBA, DCOM, or others. These technologies all allow for distributed application development using industry specified protocols. Earlier in this book we have discussed the various components of both J2EE and .NET, but we have not as of yet defined either CORBA (Common Object Request Broker Architecture) or DCOM (Distributed Component Object Model). CORBA is a language neutral distributed object model specified by a consortium of over 500 vendors through the Object Management Group (OMG). It allows applications at different locations, by different vendors, to communicate with one another, typically over the Internet using Internet Inter-ORB Protocol (IIOP). Notably absent from the OMG member list is Microsoft, who instead of supporting CORBA, created their own distributed component model in DCOM. DCOM, which is based on COM, is a protocol that enables software components to communicate directly over a network in a reliable and efficient manner. Web services simply provide the interface into this logic using HTTP and XML. More specifically, Web services are a combination of several technologies, including SOAP, WSDL, and UDDI (all of which will be described shortly).

All of the major industry players agree on the Web services concept, so it almost certainly will become the de facto method for accessing application logic on the Internet. Initially, it is expected that corporations will make Web services available internally, via corporate intranets. This will enable them to become familiar with the technology in a controlled, secure environment. Over time, these same services will be made available to other parties over the Internet. Eventually, we will have a complete library of Web services applications available for use to our applications, both wireline and wireless.

Before we explore how Web services fit into a mobile environment, some background on the core Web services technologies is in order.

Web Services Technologies

In order to understand how Web services work as a whole, we need to understand each of the core technologies involved in using them. Over the past three years, the following technologies have come to the forefront for implementing Web services:

• Simple Object Access Protocol (SOAP)

• Web Services Description Language (WSDL)

• Universal Description, Discovery, and Integration Service (UDDI)

For universal integration of Web services, these technologies have to be adopted by all major Web services vendors. It is likely that other technologies will either complement, or possibly replace, these technologies as Web services evolve.

The following subsections offer a brief description of each of these technologies. Then we will examine how they work together to define the complete Web services platform.

Simple Object Access Protocol (SOAP)

The Simple Object Access Protocol, SOAP, is a specification for the exchange of structured XML documents between parties in a distributed environment. The data exchange can occur over standard Internet technologies such as HTTP, SMTP, or FTP. While SOAP is fundamentally a stateless one-way message exchange, applications often use it to create the more complex request/response and request/multiple response interactions commonly used in Internet applications.

SOAP consists of the following three parts:

• SOAP envelope. Defines an overall framework for expressing what is in a message, who should deal with it, and whether it is optional or mandatory.

• SOAP encoding rules. Defines a serialization mechanism that can be used to exchange instances of application-defined data types.

• SOAP RPC representation. Defines a convention that can be used to represent remote procedure calls and responses.

The fundamental benefit of using SOAP is interoperability. Current middleware technologies have difficulty communicating with one another. By using XML for data exchange, SOAP enables heterogeneous technologies to communicate with each other. For example, a Java client can communicate with a .NET component exposed using SOAP; or in the same manner, a .NET client can communicate with an EJB using SOAP. This is extremely powerful in the current fragmented middleware environment. Many of the current middleware environments provide a way to translate their native function calls into a SOAP message. For example, Microsoft provides tools to translate COM function calls to SOAP, and many J2EE vendors provide tools to translate Java function calls to SOAP.

IBM, Microsoft, Lotus, DevelopMentor, and UserLand created the SOAP specification in 2000 and submitted it to the W3C for standardization. The XML Protocols Working Group is responsible for all future specifications.

Web Services Description Language (WSDL)

The Web Services Description Language (WSDL) is an XML-based specification that provides a standard way to describe Web services over different protocols, or encodings. WSDL is used to describe what a Web service can do, where it resides, and the parameters required to invoke it. Even though it is designed to work over any protocol, the specification currently only describes its usage in conjunction with SOAP, HTTP, and Multi-Purpose Internet Mail Extensions (MIME). This makes it well suited for our discussions of Web services, since those are the common protocols used.

In order to interact with a Web service you have to have knowledge of its input and output parameters, its function structure, and its protocol bindings. Service providers use WSDL to provide this information to clients who want to invoke the service. In this way, disparate clients can automatically understand how to interact with a Web service wherever it may be located. This is a key aspect to the ubiquitous nature of Web services. Without a standard way to describe the interface, Web services cannot be accessed from remote parties using disparate client technology.

Similar to SOAP, the WSDL specification is now the responsibility of the W3C.

Universal Description, Discovery, and Integration (UDDI)

The Universal Description, Discovery, and Integration (UDDI) service is a mechanism clients use to dynamically find Web services. It provides a platform-independent, open framework for describing services, discovering businesses, and integrating business services using the Internet. More simply, UDDI can be thought of as the "yellow pages" of Web services: It is where you look to find available Web services by searching for names, categories, or other specific characteristics of a Web service.

The UDDI specification lets two companies query each other's capabilities and for each to describe its own capabilities. Businesses can submit their services to be included in the UDDI business registry. Each entry is an XML file that describes a business and the services it offers. There are three parts to an entry in the UDDI directory, as follows:

• White pages. Includes name, address, contacts, telephone numbers, and other known identifiers.

• Yellow pages. Includes industrial categories based on standard taxonomies such as the Standard Industrial Classification.

• Green pages. Includes technical information about Web services that are provided by a given business. These pages should provide enough detail so that a third party can write an application to use the Web service.

UDDI takes advantage of standard technologies and protocols such as XML, HTTP, Domain Name System (DNS) protocols, and SOAP.

Bringing Them Together

In isolation, no one of these technologies is a major breakthrough; but when brought together in a cohesive manner, they establish a strong foundation for the next generation of business integration. All three of these specifications (SOAP, WSDL, UDDI) are based on Internet standards and use XML as a core language. This commonality is behind the success of Web services, and marks the first time a standard solution has been made available for integrating dynamic business services.

Figure 18.1 shows how these three technologies interact within a Web service architecture. The client application has a need to find a particular service on the Internet. The client queries the UDDI registry for this service by using an identifier such as its name or category. Once the Web service is located, the client obtains information about the location of the WSDL document. This document contains the information on what the service provides and how it can be called. The client then creates a SOAP message that adheres to the information provided by the WSDL document. The SOAP message is then sent to the host of the Web service, where it can then be processed.

Figure 18.1: Web service using SOAP, WSDL, and UDDI.

Another specification that warrants discussion is Electronic Business using eXtensible Markup Language, or ebXML. ebXML is a standard specification that provides guidelines for electronic business. It takes advantage of technologies such as SOAP, UDDI, and WSDL to provide a real-world view at how Web services can be implemented for business transactions. In general, ebXML is largely complementary to these Web services technologies, although it does offer alternative technologies to both WSDL and UDDI in the form of Collaboration Protocol Profile (CPP) and the ebXML Registry Service, respectively. When it comes to a comparison between the standards, Web Services provides the low-level technologies for enterprise integration, while ebXML provides a real-world implementation of Web services for electronic business transactions. The complete ebXML Technical Architecture Specification can be found at www.ebxml.org.

.NET versus J2EE

The topic of Web services always generates debates as to the relative merits of J2EE versus .NET. Based on the strengths that each platform offers, a conclusion will not be reached anytime soon. That said, the vendors promoting J2EE platforms, and Microsoft promoting the .NET platform, do agree that Web services form the cornerstone of Internet applications; hence, they are scrambling to make sure the core Web services technologies are supported in their offerings. Some observers feel that Microsoft has the lead because of its strong support for XML standards, such as SOAP, which is native to its platforms. Others feel J2EE will be dominant because of the strong industry support for this platform from software leaders such as Sun, Oracle, BEA, and Sybase, all of which have J2EE Web services-enabled platforms. More likely, there will be no clear winner; probably both .NET and J2EE will continue to attract developers to their respective platforms, meaning that many corporations will end up deploying a combination of .NET and J2EE servers for some time to come.

Note 

J2EE and .NET were defined earlier, in Chapter 11, "Thin Client Overview."

Because both have strong Web services support, it is important to understand the differences between the .NET and J2EE offerings. The following are the main areas where the two platforms differ:

• Core technologies supported. Both J2EE and .NET have support for core Web services technologies such as SOAP, WSDL, and UDDI, although they provide access in different ways. The .NET platform was built with Web services in mind and therefore has native support for SOAP, WSDL, and UDDI. In contrast, J2EE had to be retrofitted by adding Java APIs to access these technologies. These APIs are not difficult to use with current versions of J2EE, and future J2EE versions will support Web services technologies natively, so this eventually will be a moot point.

• Programming languages. This is an obvious distinction: J2EE is based on the Java programming language, while .NET enables the use of many programming languages. In both cases the programming languages are compiled into binaries that can be executed by a virtual machine. The Java Virtual Machines (JVM) require Java binaries, while the Microsoft common language runtime can use Microsoft languages such as Visual Basic, C#, and a variety of others.

• Supported platforms. Another obvious difference: J2EE platforms can be deployed on nearly all server platforms, including Solaris, Windows, Linux, AIX, and many others, whereas .NET currently can be deployed only on Windows-based platforms. For organizations that are not solely Windows-based, this could be a deciding factor on which platform to implement.

• Scalability. Along with the server platforms comes scalability. J2EE is proven to be very scalable for large deployments. High-end .NET deployments have yet to be seen on a large scale. By the same token, .NET has been shown to have better performance than J2EE, especially for dynamic Web sites.

• Ease of use. This may cause some disagreement, but the .NET platform is easier to develop on. Ease of use is a core .NET design goal. Since a single vendor provides all aspects of the platform, they work very well together. Implementing a complete J2EE solution can be quite complex. While there are many great Java development tools on the market, they cannot change the fact that J2EE is inherently complex.

In spite of their differences, however, these two platforms may find common ground in Web services. That said, true interoperability will only be achieved if vendors of both platforms work together to achieve a common specification. The most logical way for this to happen is through the Web Services Interoperability Organization (WS-I). The goal of WS-I is to promote Web services interoperability across platforms, applications, and programming languages. To accomplish this, WS-I is providing some key deliverables to help developers create interoperable Web services. These include implementation guidelines, sample implementations, and a set of tools for creating, monitoring, and detecting errors in Web services applications. The WS-I has adopted specifications such as SOAP, WSDL, and UDDI from other standards bodies, including the W3C and IETF, for usage in its Web services profiles. And WS-I encourages all organizations interested in promoting Web services interoperability to join the WS-I. At the time of this writing, more than 140 companies had accepted the invitation to become WS-I community members.

Web Services in a Mobile Environment

By their nature, Web services are ideal for mobile applications. They provide access to business logic and enterprise data using standard Web-based protocols such as SOAP, WSDL, and UDDI over an HTTP network connection. This allows Web services to play a role in the development of both smart client and thin client wireless applications. Since most devices do not possess the processing power for complex transactions, these calculations have to occur in a different location. Even when devices have the required capabilities, creating the applications and distributing them to mobile devices that are running different operating systems is not a trivial task. The same is true for implementing security and administration.

Having a way to offload these capabilities to a centralized server—or, better yet, to license them from a third party—could mean tremendous benefits for mobile deployments. Instead of having to create all of the content in-house and then finding a way to make it available to mobile applications, corporations can take advantage of Web services to access the required functionality. In the near term, it is likely that corporations will gradually implement logic as Web services for internal usage. As the standard becomes more prevalent, these same Web services will be made available to outside parties. For example, rather than creating a custom authentication routine, services such as Microsoft Passport could be used to authenticate users. Or credit card clearance centers could allow for credit card purchases to be approved using Web services. The possibilities are nearly endless.

To make Web services easily accessible from Windows CE-based devices, Microsoft has enabled Web services on Windows CE .NET. The first step was to provide native support for SOAP in Windows CE, then to provide in the .NET compact framework a set of services and APIs that enable application developers to quickly and easily offer Web services support for their mobile applications.

The same ideas are being incorporated into J2ME. With support for XML, HTTP, and the Java APIs for Web services, J2ME applications can take advantage of Web services. This makes possible a whole new set of applications for the wide range of Java-enabled devices on the market.

For applications on more limited devices, such as Web-enabled phones, the integration with Web services may have to occur on a server, since the client does not have the necessary processing power to parse the SOAP message and consume a Web service. In this architecture, a server could consume the Web service, and relay the relevant information to the mobile device using a standard wireless markup language such as WML or XHTML Mobile Profile. It is expected that this will be the most common methodology for limited devices to access Web services in the near future.

The great part about both of these architectures is that the result of the complex logic on the server is an XML document or a wireless markup language, which is easily consumed by a mobile client application. This means that even the simplest client-side applications can access subsets of critical data. This data can then be used within a client-side application, and possibly be stored in a local data store or simply be displayed using a microbrowser. In either case, Web services provide an important interface to complex enterprise logic and data from a variety of mobile clients.