9.2 Are There Any Next Frontiers?

9.2 Are There Any Next Frontiers?

So far, we have seen many new technology innovations emerge. The technology trends and Open Standards are evolving speedily. Honestly speaking, it would be extremely difficult to predict what comes after the current Web Services technology. Nevertheless, we can better manage these changes by understanding the rapid "delta" of these specifications and the new APIs that are published under standards bodies such as W3C and OASIS. Based on these new specifications, we can identify three major technology areas, which may be called the "Next Frontiers" of Web Services technology: convergence of Web Services standards, wireless Web Services, and open source software and standards. The last section will conclude the discussion by identifying some emerging Web Services technologies that may influence the technology directions of Web Services for the next three years .

9.2.1 Convergence of Web Services Standards

There were many interesting evolutionary changes among leading vendors and Web Services standards bodies in 2002. These changes have dramatically affected the landscape of the Web Services standards. The timeline in Table 9-1 offers some examples:

Table 9-1. Tracking Recent Web Services Standards and Specifications

February 6, 2002	IBM, BEA, Microsoft, and Intel formed the Web Services Interoperability Organization to promote Web Services technology. http://www.ws-i.org/
April 5, 2002	IBM, VeriSign, and Microsoft announced a new WS-Security specification to supersede IBM and Microsoft's SOAP-SEC, Microsoft's WS-Security and WS-License, and IBM's security tokens and encryption documents. Sun and other leading vendors also later announced WS-Security support.
June 14, 2002	Sun, SAP, BEA, and Intalio jointly propose a specification Web Services Choreography Interface (WSCI) on using XML messages to describe the flow of messages exchanged by a Web Service in the context of high-level business process.
July 15, 2002	Liberty Alliance releases Liberty specification 1.0. This is found and backed up by technology vendors (such as Sun, RSA, and HP) and industry members (such as Sony and American Express).
July 30, 2002	UDDI.org is transitioned to OASIS Standards Consortium
August 9, 2002	IBM, BEA, and Microsoft announced the new specifications WS-Transaction, WS-Coordination, and Business Process Execution Language for Web Services (BPEL4WS or BPEL). The latter will supersede IBM's Web Services Flow Language (WSFL) and Microsoft's XLANG.
August 30, 2002	Sun continues to contribute to the second major iteration of Universal Business Language (UBL), which consists of over 500 reusable business information entities. UBL is intended to be the XML contents that can fill the "payload" slot in Business-to-Business framework such as ebXML. In this way, the XML contents (instead of having different XML standards for different industry domains) can be converged into a common semantics.
September 16, 2002	Oracle, together with other supporting vendors, including Sun, proposes a W3C Working Group to form a new industry-wide working group to find consensus on the several variant specifications of Web Services choreographing Business-to-Business transactions.
September 18, 2002	Sun announces the first Liberty Alliance tool, Sun ONE Identity Server version 6.0, since the Liberty specification went public on July 15, 2002.
December 19, 2002	W3C's XML Protocol Working Group publishes SOAP 1.2 as a candidate recommendation.
January 13, 2003	Liberty Alliance announces version 1.1 of the Liberty specification, which supports cross-domain Single Sign-on.
January 14, 2003	W3C creates a Web Services Choreography Working Group to address the ability to compose and design the relationships between Web Services. This is a step toward convergence from similar business process orchestration specifications.
February 12, 2003	The Web Services Basic Profile specification version 1.0 is approved. Sun is now part of the WS-I community. An interoperability test (WS-I test) has been demonstrated by various vendors in Web Services Edge 2002. Better understanding has been gained in achieving Web Services interoperability between their existing vendor products. http://www.ws-i.org/Profiles/Basic/2003-01/BasicProfile-1.0-WGAD.html
March 3, 2003	OASIS Web Services Technical Committee releases a public draft of the new Web Services specification, since OASIS has taken up the work to converge different Web Services specifications. http://www.oasis-open.org/ committees /wss/
May 28, 2003	OASIS's New Web Services Security Technical Committee announces the establishment of classification standards for Web Services vulnerabilities.

We shall continue to see more convergence of different technologies and standards. The new WS-Security core specification and the related profile specification issued in March of 2003 by OASIS ( http://www.oasis-open.org/committees/wss/ ) is an early success of the convergence. The positive side is that convergence helps the business community to stay focused on a common standard. This bridges the gap between different Web Services technology alternatives and variants. Unfortunately, there is the negative side where the "standards" are predominantly steered by a few technology vendors without extensive community involvement (similar to Java Community Process). We do not yet see a clear technology transition plan outlined for architects and developers who have developed solutions using the obsolete technology specifications (for example, transitioning from existing programs using SOAP-SEC or Microsoft-specific WS-Security to the new WS-Security specification). Architects and developers may need to re-engineer their code to accommodate the new Web Services specifications, and thus resources previously spent on implementing the obsolete technology specifications will be wasted because the program code cannot be reused.

One interesting progress is from the interoperability testing (WS-I test) demonstrated by several Web Services vendors at the recent Web Services Edge Conference 2002 ( http://www.infoworld.com/article/02/10/03/021003hncheng_1.html ). It was found that some vendors were using XML encoding in the SOAP messaging that may not interoperate with other vendor implementations . Thus, WS-I has published a Web Services Basic Profile specification that provides some guidelines in interoperability between Web Services ( http://www.ws-i.org/Profiles/Basic/2003-01/BasicProfile-1.0-WGAD.html ). The new J2EE 1.4 release in the summer of 2003 will also reflect any relevant updates. These are good signs for the convergence of Web Services specifications and reference implementations.

9.2.2 Wireless Web Services

With the availability of J2ME technology and Java phones, wireless access to Web Services is another big emerging trend. The coming of 3G will be another accelerator for wireless Web Services. SOAP is now available to mobile devices such as the Palm PDA, Pocket PC, and Java phones using J2ME. Developers can implement a thin Web Services client using J2ME Wireless Toolkit ( http://java.sun.com/products/j2mewtoolkit/ ) and the kSOAP reference implementation ( http://ksoap.enhydra.org/ ). Coding a mobile device using kSOAP is similar to coding a normal SOAP Client. Sun ONE Studio 4 ( http://wwws.sun.com/software/sundev/jde/buy/index.html ) has a sample "Vineyard Demo" that illustrates the use of kSOAP and MIDP technology, as in Figure 9-2.

Figure 9-2 Sample Wireless Web Services Client Code

[View full width]

  import org.ksoap.*;   import org.ksoap.transport.*;  ...    public VClientkSOAPProxy() {       this.serviceURL = "http://localhost:8000/VApp/servlet/rpcrouter";       initMappingRegistry();    } ...    public java.lang.String getPriceForWine(java.lang.String winename, java.lang.String  wineyear) throws java.io.IOException {       HttpTransport call = getNewCall("getBottlesInStock");       lastResponse = call; //     This invokes the Web Services call based on the WSDL //              end-point URL=serviceURN //              operation name=getBottlesInStock  SoapObject so = new SoapObject(serviceURN, "getBottlesInStock");  so.addProperty("winename", winename);       so.addProperty("wineyear", wineyear);  Object result = call.call(so);  if (result instanceof java.lang.String)          return (java.lang.String)result;       return result.toString();    } 

This sample wireless Web Service can be accessed by any MIDP-compliant mobile device such as a WAP phone or a Palm PDA. Figure 9-3 shows a simulated Motorola WAP phone accessing the sample wireless Web Service.

Figure 9-3. Wireless Web Services Client Using Sun ONE Studio 4

9.2.3 Open Source Software and Standards

New Web Services-Related Java Specifications

More new Java Specification Requests (JSRs) are coming out to support Web Services implementations. They not only converge different home-grown or vendor-specific implementations into a single Open Standard, but they also prompt developers and architects to get ready for the migration when the JSRs are finalized. At the time of writing, the list of recent Java Specifications shown in Table 9-2 would be essential to Web Services implementations, as found at http://www.jcp.org/jsr/all/index.en.jsp .

Table 9-2. List of Web Services-Related JSRs

JSR #	JSR Description	JCP Version	Release Date	Status
5	XML Parsing Specification ” Java API for Parsing (JAXP)	1.0	Mar 21, 2002	Final Release
16	J2EE Connector Architecture (JCA)	2.0	Sep 24, 2001	Final Release
31	XML Data Binding Specification ” Java API for Binding (JAXB); binding for XML Schema-to-Java class	2.1	Mar 4, 2003	Final Release
63	Java API for Processing 1.1 (JAXP)	2.1	Sep 10, 2002	Final Release 2
67	Java API for Messaging 1.0 (JAXM)	2.1	Jun 12, 2002	Final Release 2
93	Java API for XML Registries 1.0 (JAXR)	2.1	Jun 11, 2002	Final Release
101	Java APIs for XML-based RPC	2.1	Jun 11, 2002	Final Release
104	XML Trust Service APIs	2.1	Mar 13, 2001	Expert Group Formation
105	XML Digital Signature APIs	2.1	Apr 7, 2003	Community Draft Ballot
109	Implementing Enterprise Web Services ” programming model for developing Web Services, analogous to EJB	2.1	Nov 15, 2002	Final Release
110	Java APIs for WSDL	2.1	Sep 29, 2002	Public Review
112	J2EE Connector Architecture 1.5 ” asynchronous integration with EIS and JMS provider pluggability	2.1	Nov 6, 2002	Proposed Final Draft 2
155	Web Services Security Assertion	2.1	Oct 30, 2001	Expert Group Formation
156	XML Transactioning API for Java (JAXTX)	2.1	Nov 6, 2001	Expert Group Formation
157	ebXML CPP/A APIs for Java	2.1	Nov 6, 2001	Expert Group Formation
172	J2ME Web Services Specification	2.1	Mar 22, 2003	Public Review
181	Web Services Metadata for the Java Platform	2.1	Apr 16, 2002	Expert Group Formation
183	Web Services Message Security API	2.1	Apr 23, 2002	Expert Group Formation

JAXM, JAXP, JAX-RPC, and JAXR specifications are accepted and implemented in Java Web Services Developer Pack. Not all of these JSRs, especially those in Expert Group Formation status, may be approved and implemented in the J2SE or J2EE reference implementation. Among these JSRs, JSR 31 (JAXB), JSR 109 (Web Services Programming Model), and JSR 110 (WSDL), are fairly interesting and promising .

Similarly, you can look at http://www.w3.org/2002/ws/ for a list of Worldwide Web Consortium upcoming standards for Web Services technology.

New W3C Specifications

W3C has a different process to manage Internet and Web Services standards specifications. Members can submit Notes (dated public records about some technology ideas, comments, or documents, with no W3C commitment to pursue ), which may evolve into Working Drafts (technology papers with W3C commitment to pursue), Candidate Recommendations, Proposed Recommendations, or Recommendations.

Table 9-3 presents a list of Working Drafts and Notes extracted from http://www.w3.org/TR . The highlighted W3C Notes denote some forthcoming specifications that may impact Web Services technologies and implementations in 2003 and early 2004.

Table 9-3. List of W3C Web Services Specifications

Description	Release Date	Status
Web Services Description Language specification Version 1.2	Mar 3, 2003	Working Draft
SOAP Version 1.2 Specification Assertions and Test Collection	Dec 19, 2002	Candidate recommendation
SOAP Version 1.2 Part 0: Primer	Dec 19, 2002	Candidate recommendation
SOAP Version 1.2 Part 1: Messaging Framework	Dec 19, 2002	Candidate recommendation
SOAP Version 1.2 Part 2: Adjuncts	Dec 19, 2002	Candidate recommendation
XML Key Management (2.0) Requirements	Mar 18, 2002	Working Draft (Last Call)
Web Services Architecture Requirements	Nov 14, 2002	Working Draft (Development)
SOAP 1.2 Attachment Feature	Aug 14, 2002	Working Draft (Development)
Web Service Description Usage Scenarios	Jun 4, 2002	Working Draft (Development)
Web Service Description Requirements	Apr 29, 2002	Working Draft (Development)
XML Key Management Specification (XKMS 2.0)	Mar 18, 2002	Working Draft (Development)
XML Key Management Specification Bulk Operation (X-BULK)	Mar 18, 2002	Working Draft (Development)
XML-Signature Requirements	Oct 14, 1999	Working Draft (Development)
Web Service Choreography Interface (WSCI) 1.0	Aug 8, 2002	W3C Notes
Web Services Conversation Language (WSCL) 1.0	Mar 14, 2002	W3C Notes
XML Key Management Specification (XKMS)	Mar 30, 2001	W3C Notes
Web Services Description Language (WSDL) 1.1	Mar 15, 2001	W3C Notes
SOAP Security Extensions: Digital Signature	Feb 6, 2001	W3C Notes
SOAP Messages with Attachments	Dec 11, 2000	W3C Notes
Simple Object Access Protocol (SOAP) 1.1	May 8, 2000	W3C Notes

Some Recent OASIS Initiatives

OASIS is another Web Services standards body that endorses Open Standards. It has the support of a large community. Many of the community members are also UN/CEFACT members who are actively involved in the EDI implementation. OASIS and the United Nations jointly sponsor ebXML. That is another reason that it draws such worldwide community support. In addition to the ongoing ebXML initiatives, the list in Table 9-4 identifies some recent OASIS initiatives ( http://www.oasis-open.org/committees/committees.shtml ) that are related to Web Services and may have an impact on the next frontiers of Web Services technology.

Table 9-4. List of OASIS Web Services Specifications

Technical Committee	Description	Status
eXtensible Access Control Markup Language (XACML)	XML specification for expressing policies for information access over the Internet. http://www.oasis-open.org/committees/xacml/index.shtml	Working draft 16 (Aug 22, 2002)
Business Transactions (BTP)	XML protocol for managing complex B2B transactions over the Internet. http://www.oasis-open.org/committees/business-transactions/index.shtml	Version 1.0 specification approved in May 2002
Directory Services (DSML)	XML specification for marking up directory services information. http://www.oasis-open.org/committees/dsml/index.shtml	Version 2.0 specification approved in Nov 2002
XML-based Security Services (SSTC)	Advancing SAML, an XML-based security standard for exchanging authentication and authorization information. This technical committee will also coordinate with other similar security initiatives (for example, XML Key Management Specification, XML Signature, XML Encryption, BEEP, Shibboleth, DSML, and XACML) to avoid duplicate effort. http://www.oasis-open.org/committees/security/index.shtml	SAML version 1.0 specification is at maturity level in Nov 2002
Web Services Security (WSS)	Continuation of the WS-Security security foundation published by IBM, Microsoft, and VeriSign's WS-Security in Apr 2002. http://www.oasis-open.org/committees/wss/index.shtml	Draft 11 specification issued on Mar 3, 2003
Web Services for Interactive Applications	Creation of an XML- and Web Services-centric component model for interactive Web Services applications. http://www.oasis-open.org/committees/wsia/index.shtml http://www.oasis-open.org/committees/wsia/documents/WSRP-Specification-v0.90-1.html	Early draft available for review
Web Services for Remote Portals (WSRP)	Definition of an XML and Web Services standard that will allow plug-and-play, user - facing Web Services with portals and other intermediary Web applications. http://www.oasis-open.org/committees/wsrp/index.shtml http://www.oasis-open.org/committees/wsrp/documents/version1/	Initial draft issued in Feb 2003 for review
UDDI Specifications	Continuation of the development of UDDI specification from UDDI.org for publication and discovery of Web Services both within and between enterprises . http://www.oasis-open.org/committees/uddi-spec/index.shtml	UDDI version 3.0 specification
Universal Business Language (UBL)	Development of a standard library of XML business documents by modifying an already existing library of XML Schema to incorporate the best features of other existing XML business libraries. http://www.oasis-open.org/committees/ubl/index.shtml http://www.oasis-open.org/committees/ubl/	First draft of public release made on Jan 27, 2003.

Open Source Web Services Software

We have seen many new Web Services software and tools coming from Open Source and freeware. There is also an emerging trend of using Linux for business applications. Many IT management and enterprise architects are concerned about the stability, reliability, and support services of Open Source software, especially in developing and implementing Web Services for mission-critical applications. This is a valid concern from a risk-management perspective.

The new Apache Axis (the next generation SOAP engine) allows developers to wrap business functionality without writing additional code. All you need to do is rename the Java file to .jws (e.g. StockQuoteService.java to StockQuoteService.jws) and drop it in your %JWSDP_HOME%\webapps\ axis directory. You should be able to publish the system functionality as Web Services without writing additional server-side code (see Figure 9-4.). This appears to be fast and convenient , yet developers still need to configure the application settings for better performance and scalability, modify the code to accommodate any additional validation or exceptions handling, and deploy the services. There are also design and deployment considerations for transaction management, trading partner agreement (for example, service level), transactional reliability, and security aspects. Refer to Chapter 4, Web Services Architecture and Best Practices, for details.

Figure 9-4. Deploying a Java Source File as Web Services Using Axis Instantly

You can also turn on the secure message services, which provide encryption and decryption of SOAP messages automatically using security tokens such as X.509v3 certificates (also refer to the sample "security" under the directory samples/security of the Axis distribution.) These new programming paradigms have changed the way we think of Web Services.

Figure 9-4 shows the default screen output if the StockQuoteService.jws Web Service is being invoked. Developers have placed a default Java program under the %JWSDP_HOME%\webapps\axis subdirectory, and Apache Axis will automatically expose it as a Web Service. If there is no custom-built code to handle the SOAP message reply, Apache Axis will return the message "Hi there, this is an Axis service!" by default.

The availability of Apache SOAP (and its descendant Apache Axis), Java Web Services Developer Pack, and various reference implementations for Web Services security standards have made Open Source software more visible. Many Web Services software vendors have embedded Web Services APIs (practically in jar file formats) into their Application Server and Developer Studio products. Thus, developers can purchase software support services of Open Source Web Services software.

9.2.4 The Frontiers of Web Services Technologies

Between 2002 and 2003, there were some interesting technologies announced by leading Web Services vendors. These emerging technologies may have a major role in influencing the technology direction of Web Services development and implementation (aka the new frontiers of Web Services technology). The following section briefly discusses what these technologies are (in layman's terms, instead of technical details), their benefits, and how they may influence the future development of Web Services solutions in the next two to three years.

Disruptive Technologies

Disruptive technologies are new technologies that create a "paradigm shift" in the way we use technologies in solving business problems. They are likely to create cultural changes (or disruption of the current culture) and will have a great impact on the current technologies. For instance, an Internet browser is a disruptive technology to the traditional rich client. It has drastically changed the perspective we have for the client front-end. The term disruptive may not appeal to many people because it implies a negative connotation of business changes.

Further details of the emerging technologies discussed in the following sections can be found in the references at the end of the chapter.

Sun's N1

Sun's N1 is a "long-term vision and architectural blueprint that coincides with Sun's core values of aligning with the needs of enterprises everywhere" ( http://wwws.sun.com/software/solutions/n1/ ). Sun announced the N1 technology at the Worldwide Analyst Conferences in 2002 and 2003. N1 consists of service components from stateless computer domains, which include environment elements (such as racks and power), storage elements (such as intelligent storage and SAN servers), network elements (such as switches), appliances (such as dedicated function nodes), computer elements (such as partitioned hardware SMPs/nodes), and N1 control fabrics (such as hardware management, work load balancing, and network-side billing).

N1 is a virtualization server that can provision network, computation power, and storage capabilities dynamically. It supports "service on demand" by adding or decreasing capacity on-the-fly , without impacting the service-level requirements. It also supports utility computing by billing on the actual use of computing resources (instead of the hardware and software licenses). Computing resources, which are Web Services, can be dynamically adjusted and reallocated to other locations when there is an unanticipated increase of business transactions.

For instance, if a customer needs huge computing capacity to meet large Christmas online shopping transaction volume, he/she can reprovision the N1 components from one machine (say, a low-end machine) to another larger computing platform (say, a mid-range machine) using the "flare" utility (in layman's terminology, it is like the Norton Ghost utility on a PC machine). The flare utility will transfer the entire machine disk image, data storage, and all configuration settings to another machine (or another network platform), and the new machine can start up without reconfiguring or retesting the application services.

Such flexible network computing power is a key technology enabler for Web Services because infrastructure and application services are no longer limited to one particular machine. Web Services (back-end business applications wrapped as Web Services) running in the remote data center can be scaled up or down easily using N1. It is anticipated that there will be more coverage on N1 for Web Services.

JXTA

Project JXTA ( http://www.jxta.org ) is an Open Source initiative for designing and implementing peer-to-peer solutions. JXTA technology runs on Linux and J2SE platforms ( http://www.jxta.org/servlets/ReadMsg?msgId565924&listName5announce ). There are many similarities between JXTA and Web Services, both of which have evangelized service-oriented architecture, reusable components, and distributed computing. For instance, JXTA technology can be used to connect to a range of network resources to support auctioning or to provide business information sharing.

JXTA technology has its own implementation of service discovery and service invocation. It is a complementing technology to Web Services technology. Besides, it can also initiate a SOAP call using a JXTA bridge ( http:// relativity .yi.org/jxta-bridge/ ). Both of these technologies provide different low-cost options to implement service-oriented architecture and reusable components, and they can interoperate using a JXTA bridge. Examples of peer-to-peer applications are the sharing and aggregation of business information (such as aggregating research data) from multiple enterprises and peer-to-peer payment. It is anticipated that there will be more examples of collaboration between JXTA and Web Services in mid- to late 2003.

Grid Computing

Grid computing technology allows reusing available computing resources to perform business services collectively. This is a cost-effective architecture approach to leverage existing computing resources. Grid computing requires a grid computing agent installed on each machine. The grid computing master will manage the scheduling and policies for different computing applications. If there is any conflict or any exception, the policies should handle them according to the predefined processing rules. Each grid computing agent can be programmed to invoke remote business applications (that is, Web Services). Besides, each machine running the grid computing agent can become a Web Service (Service Provider for the Web Services).

One example of how grid computing might be used: a grid of risk-management applications can be set up to calculate the market risk using tens of low-cost Linux and Unix machines. Each of the risk-management applications is exposed as Web Services. This risk-management solution could be an extremely expensive and time-consuming task if it is performed on a monolithic mainframe system.

In Chapter 2, Web Services Phenomenon and Emerging Trends, we discussed some trends in developing grid computing applications. We are beginning to see grid computing technology used with Web Services in the industry (such as grid computing for the capital market, http://www.simc-inc.org/archive0203/Grid/agenda19nov2002.htm ). It is anticipated that with Web Services available there will be more examples of grid computing in the near future.

Web Services Management and Appliances

The Era of Web Services Management

As Web Services technologies and tools mature, the demand for managing Web Services applications is increasing. There are an increasing number of Web Services management vendors in the market. Chapter 3, Web Services Technology Overview, identified some examples of Web Services management tools and vendors.

Web Services management tools can provide black box-style infrastructure to manage message encryption/decryption (for message-level and data transport layer security), message compression (for faster performance and throughput), service versioning (for managing different versions of remote applications), Web Services testing (for stress testing and regression testing a service end-point URL), and service-level management (such as monitoring service-level targets and analyzing bottlenecks for remote SOAP calls). There is no single vendor today that provides all these functionalities. Some of the existing infrastructure or application server vendor products can provide partial Web Services management functionality. For example, J2EE application analyzer tools can enable tracing and tracking some of the performance bottlenecks if the remote Web Service is implemented using an EJB. If the remote Web Services are not EJBs, then the J2EE application analyzer will not help, even though the SOAP client is written in Java.

Several Web Services management tools can be consolidated into one machine to provide an integrated management platform. These management tools can be embedded in low-cost Unix or Linux machines for massive deployment. These are sometimes called Web Services appliances. We are beginning to see some of these Web Services appliances, such as Westbridge's XML Message Server ( http://www.westbridgetech.com/architecture.html ), Westbridge's SOAP monitor ( http://www.westbridgetech.com/soapmonitor.html ), and IBM's Web Services Gateway ( http://alphaworks.ibm.com/tech/wsgw ) in the market.

It is anticipated that more technology vendors will enter the Web Services management space by extending their existing infrastructure products, systems management tools, middleware products, application developer tools, or application server products. Another technology trend is the emergence of Web Services appliances from new startups and niche vendors.

These Web Services management tools address two important technology problems: the monitoring, analysis, metering, and billing of Web Services for service-level management and using a black box-style Web Services appliance approach to simplify development and deployment. Currently, there is no standard and structured way to monitor, analyze, and troubleshoot Web Services applications. The black box-style appliance approach denotes that developers do not need to modify their existing application code or infrastructure to add monitoring or troubleshooting Web Services capability. For example, a Web Services appliance (black box) can encrypt/decrypt and compress/decompress the SOAP messages speedily using dedicated hardware or firmware components. It can then forward the SOAP messages to the target SOAP proxy without adding new Web Services security and compression logic in the existing applications. These Web Services management tools would be a major boost to productivity and manageability.

Web Services Technologies Continue to Evolve

Next-Generation SOAP Engine

Apache Axis is designed to be the next-generation SOAP engine with high performance and throughput. It not only provides better tools to generate SOAP client stubs and server skeletons (or tiers), but also provides new infrastructure features to support Web Services security (such as encryption and digital signatures). Before Apache Axis was available, developers needed to use a separate Web Services development tool to generate SOAP client stubs and server skeletons (or tiers). Then they needed to wrap the remote business applications in a SOAP proxy, and deploy the program code. Now Apache Axis provides a simple way to wrap remote business applications. The "Paper and Pencil" exercise in this chapter illustrates how this can be done.

Apache Axis can also be embedded in a Web Container to become a SOAP appliance. Apache SOAP is an important milestone in Web Services technology because many application servers have incorporated it. It is anticipated that the Web Services development area will be very receptive to Apache Axis (and it will have stronger traction) in the next few months.

SOAP on CICS

IBM announced a CICS SOAP technology preview on March 5, 2003 ( http://www.infoworld.com/article/03/03/05/HNcicssoap_1.html?web ). This enables developers to invoke a COBOL application in the remote CICS region through SOAP requests over HTTP request or WebSphere MQ messages. The software can be downloaded from ( http://alphaworks.ibm.com/tech/soap4cics .)

In Chapter 5, Mainframe Integration and Interoperability, we reviewed some of the mainframe integration and interoperability options. This new capability of CICS SOAP will make mainframe integration and interoperability even easier. However, it is not clear whether this new technology will foster more Web Services implementation on IBM's mainframe platform or not.