Going With the Flow

How can companies simplify coordination of all their external interactions?

By Michael J. Hudson

Many people argue how great the world will be once businesses can effortlessly interact with each other. Yet, realizing this ideal is still quite difficult. The many challenges involve not only being able to interface with the services of another business without regard to different technologies but also gathering together disparate calls to services of multiple businesses, as if the aggregation of these calls were one interaction. This is the dream of the new watercooler buzzword called Web services. I intend to throw some light on the present and future directions of Web services.

Initially, the term "Web services" conjures up familiar concepts: namely, the current batch of Internet businesses that provide "services" to consumers over the Web, or even current B2B interactions that deal with either placing orders on other companies' Web sites or interfacing directly with another company's inventory regardless of a Web interface. So, the first obvious question is, "What is so different about Web services?"

Successfully answering and understanding this question could save a business a lot of money. The speed at which the business community arrives at the answer will foretell whether the concept itself has any merit. In one sense, Web services are the foundation upon which businesses automate interactions with each other. However, more concretely, Web services embody the abstract idea of bundling together a group of tasks (or services) in a platform- and language-neutral way and then communicating those services to others. The major benefit is that a business can dynamically, swiftly, and inexpensively deploy its resources to others to either facilitate current transactions or make additional profit out of the services themselves.

Sounds great, right? Idealistic promises of being able to do business with a number of different and disparate corporations without worrying about the actual integration of technologies have become commonplace. But, does this concept really have any substance behind it? And I'll even go one step further into the exalted realm of CIO wishes: Can you combine the services of multiple, unrelated companies and have those actions unified as one task that you can easily repeat and configure? The answer, surprisingly, is converging quickly to an absolute yes.

Competition and Compatibility

The first challenge is: the ability to create, publish, and use a set of services within your business in an easy and independent way. Currently, two competing paradigms are clamoring for the Web services spotlight: Microsoft's product strategy (.NET initiative) and a standard called Java 2 Enterprise Edition (J2EE) created by Sun Microsystems. But doesn't this struggle for technology dominance in the Web services field hark back to the original problem? That is, doesn't the existence of two solutions to the same problem imply that neither will be compatible with the other, thus bringing back the era when implementing interoperability was slow and painful, and integration was impossible? Didn't Web services promise the disappearance of integration nightmares?

In the words of Bobby McFerrin, "Don't worry, be happy." The great thing about Sun's J2EE standard and Microsoft's .NET initiative is that they are very compatible with each other. The main reason is that both entities are using emerging Internet standards to implement their concept of Web services. These standards include the simple object access protocol (SOAP), the Web services description language (WSDL), the universal description, discovery, and integration (UDDI) initiative, and the ultra-standard that glues all these other standards together, the extensible markup language (XML) and all its supporting technologies.

The main differences between J2EE and .NET are "under the hood." Their main benefits and disadvantages involve how they link into legacy systems, which platforms they can run on, which languages they use, how portable the systems are, how much they cost, and their performance and scalability metrics. None of these issues actually affects how a business uses either platform to create, publish, or use services instantiated on the other platform. This ability to interoperate is possible because both platforms have continually incorporated support for XML.