J2EE application servers enabled mainstream developers to build sophisticated multitiered Web applications that use mature standards and any of several commercial and open source application server platforms. A similar pattern has now emerged with the maturation of standard platforms for enabling service-oriented architecture (SOA) through Web services. These Web services platforms provide the same mainstream developer community with design patterns for implementing composite applications that leverage adapters, integration, transformation, business process management, and Web services. This article examines the key requirements for an effective Web services platform, related standards, and what impact this is having on developers and enterprise IT.

A Use Case: DSL Provisioning
To keep this discussion grounded, let's look at a real-world example for doing DSL provisioning at a major European telco. (Actually, this use case is a composite of several production SOA customers.) In this example, the requirements are to build several composite applications that automate the provisioning of new DSL orders. These orders can come in through a variety of channels, including customer service representative call centers and a public Web application. Once initiated, an order typically takes several days to complete, including sending a modem to the customer for self-installation, scheduling the required network activations, and initiating the associated back-end billing systems. Keep in mind that although this example involves a long-running process, because it adds some extra complexity and new requirements, a subset of these same requirements applies to short-lived, synchronous processes. In fact, the real telco behind this use case also has synchronous processes - for performing network tests when customers call in to report a problem with their line, for example. A simplified version of the process is shown in Figure 1.

Web Services Platform Requirements
If you think about building this application on a pure Java/J2EE platform, you will quickly see that several specific challenges will make this a difficult problem to solve - and an even more difficult situation to maintain and manage over time. Challenges include:

• Integrating with many heterogeneous back-end systems and protocols (some of which are SOAP, but most are not)
• Avoiding "hard-wired" process flows and making process state persistent
• Interleaving UI page flows with process flows
• Handling complex data types and data transformations
• Securing interactions with services through uniformly managed security policies
• Incorporating business rules, which should be changeable without recompilation or deployment of apps ("automated business policies")
• Unit testing and stress testing the composite apps
• Monitoring, administering, and reporting against the processes - for example, "Page me when the exception rate exceeds a given threshold," "What are the bottlenecks in the production process?"
• Leveraging middleware technology that is already in place

Conveniently, most of these are not new requirements, and by now the problem space is fairly well understood. Furthermore, over the past 10 years standards and vendor technologies for EAI, BPM, workflow, B2B, and the like have evolved and matured to the point where platforms can now address all of these requirements in a standard fashion.

To get to this point, industry progress has been generally incremental, but I see two key developments that have combined for a more revolutionary impact. One of these is the industry-wide acceptance of the XML Schema, WSDL, SOAP, and BPEL (Business Process Execution Language) standards. The second is the emergence of architectural platforms that use these standards to both address individual functional requirements and provide the glue between the components of a full solution. The value of these standards, when implemented religiously by vendors, is to enable an out-of-the-box, fully functional platform solution along with the ability to plug in best-of-breed technology components when appropriate. Table 1 shows best practices architecture for addressing each of the preceding requirements in a Web services platform and below is an examination of each of these approaches in more detail, along with the key standards that are relevant to each.

Standard Web Services Interfaces (XML, XML Schema, WSDL)
XML and XML Schema are now widely used for enterprise integration data models, as is WSDL for the component interface model. In the case of the DSL provisioning application, this means that a preexisting Microsoft.NET notification service can be easily integrated into the composite application. It also suggests that platform vendors need to work hard on interoperability, encouraging conformance to the WS-I Basic Profile and performing rigorous interoperability testing. For example, Oracle runs frequent interoperability tests against all of the service WSDLs at www.xmethods.org. Integrating several Web services via SOAP, WSDL, and XML into a composite app is much quicker and easier than using traditional EAI technologies.

Flexible Binding Framework (WSIF) and Adapters (JCA)
Web services means much more than just SOAP. The Oracle platform leverages many open source technologies; one of the most interesting is WSIF, the Web Services Invocation Framework, from Apache (http://ws.apache.org/wsif/). WSIF provides a mechanism for gaining the benefits of Web services - a standard WSDL interface and an XML data model - without requiring SOAP and its associated performance impact and other limitations. Specifically, with WSIF, you can use native protocol bindings (such as Java, EJBs, non-SOAP HTTP, JCA, pure socket-level TCP/IP, and so on) but still have a WSDL interface for your service. This enables a Web services component model but keeps the performance and transactionality of the underlying protocol.

For the telco in our example, the existence of 6,000+ network equipment endpoints with Java interfaces means that wrapping all of those endpoints as SOAP services would require a lot of work and have major performance implications. Using the WSIF Java binding allows those network endpoints to be "orchestrated" as if they were Web services, but without the overhead of SOAP. In addition, once a WSDL file with a WSIF binding has been created (and tools such as Oracle JDeveloper exist to do this automatically for Java classes and EJBs), the WSDL file can be put into a service directory and incorporated into a BPEL process as easily as any SOAP Web service.