Starting with a brief look at how developers build systems in J2EE and CORBA, I'll compare these two well-understood approaches to Web Services. Then I'll give a real-world example of Web services. By fleshing out this example, we'll see the business and technical issues relative to building systems based on Web services, and identify the best model for building Web services to solve real business problems.

Distributed Computing Paradigms
When building EJBs in a J2EE environment, developers focus on server-side business components. Decisions are made about the individual components: What type of data is being passed. What is the messaging model, document exchange or RPCs? Is the component stateful or stateless? Is it long-lived or short-lived? Does it need to access the database? The answer to these questions results in the creation of a message, entity, or session bean. If it's stateful, decisions are made on how the state is made persistent. The approach is to identify what type of bean you want to build and then implement the corresponding home and remote interfaces. The exciting thing about J2EE is that after you answer these questions, the primary focus is on building the implementation logic. The container takes care of abstracting away all of the qualities of service such as transactions, persistence, and threading. After the bean is created, it's deployed and can be found by searching through JNDI.

With CORBA, the focus starts with the client contract, the IDL. The contract defines the services being provided from the client's perspective. As long as you implement the contract, the actual underlying details are up to the developer. The server developer leverages prebuilt CORBA services to tackle implementation problems. The designer also specifies the corresponding POA policies used by the server for managing CORBA servants and obtaining higher levels of scalability and performance. Further decisions may be made about threading. After the server is implemented it's registered to a location daemon, naming service, or trader service.

With Web services, you begin by thinking about process collaboration. How will systems integrate this Web service? Based on the process collaboration requirements, how can existing logic be exposed to satisfy this new avenue for accomplishing the business function? The business objective leads the developer to think primarily about integration. Whereas with EJBs and CORBA components the focus is on business logic, with Web services the focus is on the process collaboration. Web services can be found by looking through UDDI or ebXML registries, but like CORBA, the registry isn't necessary because the location of the Web service may already be well known. Let's look at a real-world example to see this model in use.

Real-World Example
The Business Problem
A hypothetical application is presented in Figure 1 depicting a Web service collaboration between a large telecom company with a cellular network called Big Telco (BT) and a music label called Enormous Music Label (EML). To beef up the image of BT's cell phone service and differentiate themselves from the competition, BT wants to enable their customers to not only listen to MP3s on their cell phones, but to allow their customers to browse for and select MP3s to be downloaded to their phone or to a friend's phone. Ordering MP3s for the cell phone must be inexpensive and convenient for consumers or they won't bite. In order to justify the ROI for building such a system, it must be fully automated, easily built, easy to maintain, and have a scalable business model, one that easily accommodates changes in business parameters.

EML wouldn't profit by selling MP3s directly to the individual because of the billing issues.

If an MP3 can be purchased for a dollar, it's economically unfeasible for EML to either take a credit card or send a "snail mail" bill. EML is more than happy to let a third party solve the billing issue. BT already sends a direct monthly cell phone bill to the customer. Customers pay on average $50-150 per bill. The joy of being able to get any song, any time, at a negligible price would ensure that each customer would purchase songs without caring about the additional charges on their bill.

EML isn't in the business of cell phone portals and telecom companies don't have the ability to deal with music copyrights. For BT to provide this service to their customers, they need a partnership with EML.

The Collaboration
In Figure 1, automated contract negotiation occurs at the beginning of the collaboration process. Contract negotiation is an important part of many business collaborations. We've always dreamed that contract negotiation could be automated, but as most people know, it will take years to get to this point. People are still needed to do the negotiating to incorporate the proper business and legal processes that ensure a binding and realistic contract. So let's ignore contract negotiation for the first go-round and consider it a future possibility.

The use case is a customer browsing the music catalog on their cell phone on BT's portal to order a song for a friend. The catalog originates from EML's site. BT already has the cellular portal in place to properly paginate Web pages to the cell phone and can easily stream the catalog to the phone once received from EML. BT simply needs to retrieve the catalog information and display it on their portal.

When the customer selects a song to order, BT notifies EML. This transaction needs to be secured. EML has an account for BT and bills them quarterly. The billing system notifies the fulfillment service and sends the corresponding MP3 to Telco, which in turn sends the MP3 to the friend's cell phone.

Either the friend's cell phone receives the song and sends a receipt or the order times out. This is a complicated transaction requiring a two-phase commit across two organizations. If the friend is on vacation without a charger and doesn't turn the phone on for five days and never receives the song, EML shouldn't debit BT's account, nor should BT debit the customer's bill.

Let's look at the touch points of integration:

1. EML cataloging system with BT portal
2. BT portal and customer billing system
3. BT portal and purchasing system
4. BT purchasing and EML ordering systems
5. EML ordering and billing systems
6. EML ordering and fulfillment systems
7. EML and BT fulfillment systems

It's easy to imagine that EML has Macintosh and Windows boxes hosting applications built in Java and Visual Basic. They have packaged SAP applications and a mainframe where the catalogs are archived. It is also easy to imagine that BT is a CORBA shop that recently adopted J2EE for servicing their Web portal. The semantics of these distinct technology platforms need to be abstracted away. Data needs to flow between all of these systems in order for the application to function.

The complexity of the system is apparent when you realize that creating these Web services requires the exposure of many back-end systems that weren't previously accessible via the Internet. Exposing these systems leads to a major security challenge. Both companies have a back-end integration challenge to expose these systems to their new partner. Once these systems are exposed as Web services, the B2B collaboration needs to be implemented. Since BT has the relationship with the customer, they'll drive the overall collaboration. If the MP3 doesn't reach the friend, the customer will look to BT to find out why and will expect not to be billed.

Handcoding this solution would become too costly and prove to be a lost investment. It would be a considerable effort to hand code each integration point in the original design. Once the system is deployed, considerable investment would be required to maintain, upgrade, and customize the system. Eventually BT will want to provide more third party services for their cell phone users and may need to customize the way the Web services interface into their back-end systems to integrate with the new partner. If the relationship breaks down between EML and BT because EML is unable to meet the contracted service level agreements, BT may decide to switch to a completely new partner. Each one of these changes will cause considerable changes in the integration. Hand-coding this integration is possible, but it would be time-consuming and wouldn't scale with the business model.

Tools are needed to aggregate back-end resources to the Web as Web services. Tools are also needed to define the collaboration between the two companies. The corresponding runtime environment is needed to monitor the business process collaboration and ensure that transactions are properly committed or rolled back.

EML needs to ensure that there is ROI in exposing their systems as Web services. Like BT, they'll require tools to integrate, secure, and expose their back-end systems for consumption. Most likely, BT won't be the only customer of this system. Many third parties will also distribute MP3s. These third parties would likely aggregate catalogs from multiple music labels and deliver them to cell phones, cable boxes, handheld devices, and desktop computers. The number of integration points quickly increases and becomes extremely complex, effectively creating a web of Web services. Taking a programmatic approach to accomplishing this integration wouldn't be feasible and would quickly become unmanageable.

The Model
Building a system based on Web services requires that you take the following steps:

1. Expose the back-end systems as Web services.
2. Define the business collaboration model.

Interface refactoring can be simple and complex. Only a subset of the overall functionality of the back-end system will be exposed. For example, EML will allow BT to get a copy of the catalog, but not modify it. Data types may need extensive restructuring. Imagine an EJB that passes Java Serialized Objects. It makes little sense to allow a Java Serialized Object to traverse the Web service because a consumer that is built on a VB application or a .NET platform will not be able to consume it.

A single order may have multiple back-end touch points requiring a process engine to tie the systems together and expose the process as a single coherent service. Different systems expect data to be formatted in different ways, transformation technologies may be needed to change the structure of a document for use by different systems.

Sun initiated a number of Java Community Process JSRs, commonly referred to as the JAX APIs. These JSRs define APIs for portable coding to Web services standards. JAX allows for programmatically creating and accessing Web services in Java but in reality much of this is already automated. The reality is that most Web services today are not being built from scratch. As seen in the example, over 90% of the business logic existed before. EAI systems have taught us that it's better to leverage tools to achieve integration than to hand-code it. Hand-coding is less flexible when changes are required.

Once these Web services are exposed, the collaboration needs to be defined. This is also a nontrivial process. If Web services previously existed and were built for another customer, translation may be needed. Often a Web service interface exposed for one customer will need refactoring or translation for another customer to integrate it. Transactional and security contexts may need to be exchanged by these two vendors. If one vendor is using the Microsoft Transaction Service and the other is using the Object Transaction Service, there needs to be a common standard for passing the transaction context to properly interoperate with these systems. SSL can be used to authenticate and encrypt the messages, but if higher levels of security are needed, a standard like S2ML may be adopted to pass security context from one system to the another.

Conclusion
Web services represent a new variant of distributed computing where integration is the main focus. Through our real-world example, you can easily see that Web services present an integration challenge requiring much more than simply enabling existing applications to speak SOAP. The reality is that Web services represent a new Integration Model. Web services require process collaboration, security, transactions, translation, monitoring, logging, and connections into multiple back-end systems. The primary focus of Web services is to repurpose an existing system to enable a company to add a new line of revenue. To justify the investment in these systems, the proper tools must be provided to expose existing systems easily and ensure that integration points can be tied together quickly, translating from one interface to another and transforming one data format to another in a secure and potentially transactional manner.

Author Bio:
Rebecca Dias is a Web services product manager at IONA Technologies rdias@iona.com