Web services are a great vision to talk about. as evidenced by the increasing number of companies declaring themselves the leader in the Web services market. Hype aside, just as with XML, sooner or later we'll all realize there's no Web services market per se but only ways to apply Web services as part of B2B machine-to-machine integration, enterprise portals, knowledge management, marketplaces, self-service forms, and so on. In other words, what we need to focus on is how to use Web services to solve specific technical problems rather than getting excited about new and more dynamic "plumbing."

Returning to the vision part, it's easy to be almost overwhelmed by the many technologies that need to be in place to make the full vision of Web services a reality. The good news is that not all of these specifications and standards need to be in place to get started. But first, let's look at the technology landscape today and how it affects the delivery of the vision of Web services.

Technology Landscape
Interface Standards/Vertical
Business Objects
As we know, SOAP can be deployed following a more messaging-oriented paradigm or a more remote procedure call (RPC) paradigm. There are others also, but let's focus on these two.

If we use SOAP for RPC, we don't need vertical standards per se as we're just calling methods on remote objects. What worries me a bit is that we see many wizards and tutorials that can easily transform Java objects or COM objects to a Web service, which in itself leads to RPC-type Web services to execute a particular transaction. Because we're calling a method and its associated parameters, I still consider RPC-type calls as tighter coupling.

This is great news if I just want to integrate the Web services of one or two business partners. It becomes more problematic if what we're interested in is transparent information exchange across an entire value chain, where we need to have agreements on messaging structures rather than just APIs.

On the side of vertical business objects, thanks to the work of the numerous industry consortia, we already have a pretty good set of business objects available and we're starting to see the adoption of some of these.

Web Services Security and SSO
What's the most annoying thing in dealing with Internet e-business services? Did you think "having to log into each system (over and over again)"? Right!

The magic word is single-sign-on. It's a core part of the Web services vision to be able to integrate and aggregate services provided by numerous geographically and logically dispersed providers.

Without standards to provide means for services to exchange users' authentication information, large-scale deployment of dynamically aggregated services won't happen.

The good news is that we have a few very promising initiatives going on. One is the OASIS Security Assertions Markup Language; the other is Passport, driven by Microsoft.

Distributed Transactions
Gone are the days when ACID was everything we had to worry about (and I don't mean kids doing drugs in discos). Atomicity, Consistency, Isolation, Durability were everything we needed to ensure well behaved transactions in our systems.

It became more complex as we started to distribute our systems. All distributed databases and other such systems today support "two-phase commits" to deal with the increased complexity of transactions in distributed environments. In this scenario, all participating processing nodes have to either commit or rollback a particular transaction.

The Internet, however, is the most distributed and complex system we can imagine. Two-phase commits alone are not suitable to address the complexity of Internet-scale transactions. In the Internet realm we typically deal with multiple entities (customers, suppliers, and business partners) that use loosely coupled Web services to execute a particular transaction. This overall transaction in turn consists of smaller transactions that are wired by some implicitly or explicitly defined workflow. Should an individual transaction fail, we may not be able to roll it back so we have to introduce a compensating transaction to regain system integrity.

While the standards and vendor community is working hard to address this problem, no broadly accepted standards exist. Examples of interesting efforts in this arena include the OASIS Business Transaction Protocol.

Business Processes
"Workflow goes Internet." While in the past we could be content with describing the workflow within the confines of our corporate boundaries, today we have to deal with complex interactions between a number of parties involved in our extended enterprise (including customers, suppliers, and business partners).

Emerging specifications will help us find a common, reusable, and hopefully interchangeable format for describing these processes. The most promising initiatives include the OASIS/UN-CEFACT ebXML suite, Rosetta Net, Biztalk, BPMI, and WSFL, just to name a few.

In this category of emerging technologies, the difficulty isn't finding novel ways of addressing the problem, but rather coming up with a broadly agreed upon way of doing it.

On a smaller scale, we'll need business process management as well. Web services help us to break up applications into discrete components. Once that has happened, something has to integrate them back together. This will be either some glue-code or - even better - some externalized business rules driven by the business process engines.

Reliable Protocols
We want our systems and our Web services to be reliable. The problem is, while we know that SOAP doesn't care about the transport protocol used to get a SOAP message from A to B, we also know that we'll use HTTP, especially between companies.

Unfortunately, while HTTP is known for being ubiquitous, it isn't known for being reliable. Two approaches can be used to fix this. You can build code around these protocols - which is what most designers have to do today - or you can make the protocol more reliable, which is what the guys at IBM are suggesting with their "Reliable HTTP" - httpr.

Payment Services
Software as a service? This is unlikely to work without an associated plan for charging for it. (Larger software companies seem to prefer this model to the old-fashioned buy-and-own.) Certainly a recurring revenue-stream seems to be valuable, and it will be much harder to do a "backup" copy for a service-based software package.

As we talk about payment services, however, we need to distinguish carefully between paying for software and the use of it (as described above), or whether we're talking about a business service (like a credit card check) that we pay for (whereas the Web service is more the means than anything else). I'm not yet convinced we can treat them in the same way (but I'm always willing to listen).

Web Services Adoption
So are we doomed? Will we have to wait for all these things to be defined and standardized? Not really!

Informational Web Services
These kinds of services are the best examples for using Web services without having anything else in place. Not mission critical in nature, these services offer stock quotes, weather reports, traffic reports, and so on. In this case I am not really concerned with anything else but getting to information (and showing off "the power of dynamic Web services").

These services lend themselves nicely to RPC-type SOAP calls where we want instant gratification. I believe all the services on the well-known Xmethods site follow this paradigm without exception (which isn't surprising).

Web Services as Next Generation APIs
This should be the most straightforward thing to do (especially for applications that aren't tied to a heavy user interface component). Is there an existing SDK to your product? If yes, then all you need to do is wrap the EJP, JSP, COM, or whatever components you use into a collection of Web services and suddenly your product is Web services- enabled and Internet-ready.

Extending the Reach
This is where it gets really exciting with respect to Web services in the short term. In the past I could have a few online forms as part of my extranet and people would use them to order goods, check on availability or delivery, and so forth.

What limited the reach of these applications was that, for one, all of the user interface was hardwired. Many intranets have set guidelines for colors, fonts, and other style-related attributes. With Web services you can integrate a service and have complete control over the visual appearance, providing seamless integration.

Secondly, interfaces weren't explicitly described. This made it hard to programmatically call an old-style Web service without having to dig into the HTML code to figure out what the parameters were (not talk about valid types, error-handling, etc.).

With such Web services, it's also easier to extend the reach beyond the browser to cell phones, PDAs, and all the other great devices that are still looking for the "killer application."

Small to Medium Enterprises
With Web services, a smaller enterprise can now do what it previously would have required costly EDI infrastructure for. Now it can finally afford electronic data interchange and participation in larger markets (we just need to wait for the right tools to hit the market). The OASIS/UN-CEFACT was designed with this category of users in mind and it's also architected to use Web services from a transport perspective.

Dynamic Trading Networks
In the short term we'll see some vendors providing platforms to develop, publish, locate, integrate, and charge for Web services. Since none of the standards I described are in place, these vendors will have to make up for some shortcomings by "proprietary" approaches.

This is a part of the vision of dynamic Web services where we see most disconnect between current practice and future promise. The problem with this vision is that, while exciting and promising, it does have to overcome many existing hurdles of today's business and technical everyday practices.

A company's data structures (read schemas) contain a lot of information about how they do business (often, information they want to share with just a handful of business partners). The same holds true for business processes or other aspects of a company.

Maybe that's why the adoption rate of public service and schema registries is so slow (and I am not talking about quantities of objects stored, but rather the way people use them and for what purpose). Unless you're really interested in the vision of dynamic discovery of business services, you're more likely to just publish your Web service descriptions, schemas, and other interchange relevant components to your known business partners, and that's all you need to do..

Trust
Trust has been at the heart of business since the dawn of time. The "new economy" requires a company to trust an unknown, almost anonymous entity to deliver goods or (Web) services that are critical for its business. That's a lot to ask for, which is probably one of the reasons why, according to the various assessments, private and more controlled e-marketplaces are more pervasive than open and "public" ones.

Summary
We can see Web services beginning to emerge as a means to solve business problems. Once we've covered distributed transactions, single sign-on, business process management, and so forth, we can talk about the new world order. Until then, and even then, Web services - just like any other technology - will change the way we do business, but often not as fast as we i-technology visionaries would like.

Author Bio:
Norbert Mikula is a founding member of DataChannel and is an integral part of their strategic product planning and technology research. He has more than 10 years of experience in building and delivering Internet and e-business technologies. Norbert serves as vice-chairman of the board of directors of OASIS and is industry editor of Web Services Journal. He is recognized internationally as an expert in Internet and e-business technologies and speaks regularly at industry events. norbert@datachannel.com