Web services--the future.

If you haven't already adopted a Web services-based strategy, you're probably wondering the following:

* Do Web services solve real problems? What problems do Web services solve?

* Is there really a future for Web services? That is, will this market continue to grow? Will Web services really play a big part in the next generation of the Web-or are we drowning in technology hype?

* How can I use Web services? Where exactly can my business focus to take advantage of the technology?

These questions are so fundamental that you should ask them about any candidate technology. In the following we examine each of the above statements.

Do Web Services Solve Real Problems?

What problems do Web services have the ability to solve? Many businesses suffer from integration problems in our fast-paced world of ever-changing technologies, market conditions, and business relationships. It is vital to be able to have internal systems communicate with your partner's internal systems, and databases. Rapid and easy integration facilitates and empowers your business processes. Yet businesses frequently experience many problems in this area. Because of different database languages, different communication protocols, and different ways of expressing problems in languages understood by computers, integrating systems is extremely difficult.

One of the major indicators of a successful technology is its ability to solve problems to help organizations do business.

So, we have integration problems, but we want to solve them quickly. People want to see return on their investments as soon as possible. How can you repurpose your existing assets without being disruptive to your organization's business process? How quickly can you change given new market conditions? The problem with solutions in the past is that integration efforts have taken too long, and we have created new stovepipes by creating inflexible, hard-to-change architectures.

Although it sounds like a paradox, a key reason businesses were so quick to adopt Web services was that other businesses adopted Web services. This agreement only took place because the technology can solve these integration problems by providing a common language that could be used in integration- both within and between enterprises. Without agreement on a common language, there would be no interoperability.

Agreement on a technology that works is more important for business than debating which technology works best.

In the past, there have been battles over which protocols and computer languages to use. At one time, there was debate over whether TCP/IP would be the dominant networking protocol. When it became the dominant protocol for the Internet, other protocols used that as a foundation for transport, including HTTP, which became the protocol for use over the Web. HTTP became a widely supported application-layer protocol, and SOAP was developed using HTTP as its foundation. Now that major businesses have adopted SOAP for the communication medium between applications and servers, this ensures that everyone's applications have a chance to speak a common language. Web services are based on SOAP and represent our current state of evolution in communication agreement.

Because there is such widespread agreement and adoption of the Web service protocols, it is now possible to utilise work undertaken to create existing applications and turn them into Web services by using the standard Web service protocols that everyone understands. Web services allow you to change the interfaces to your applications-without rewriting them-using middleware. An example that should have a profound impact is that with easy-to-use middleware,.NET clients and servers can talk to J2EE servers using SOAP. The implementation of the underlying application is no longer relevant-only the communication medium. Wasn't CORBA Supposed to Solve Interoperability Problems?

Today's business strategies are demanding more intercompany relationships. The broad spectrum of companies means a broad spectrum of applications and integration technology choices. Companies who succeed in this market realize that flexibility is everything. To interoperate with many companies and applications in a business, users need both a common language, and a way to solve problems in a dynamic environment. Web services provide this framework.

Is There Really a Future for Web Services?

This may be the most important question to ask. One thing that we've learned over the past 10 years is that a technology's success is not dependent on how well it works or how "cool" it is. Most of the success is based on business decisions that are made by major business players. Many well-thought- out, well-designed technologies now languish in the graveyard of useless technology because they were not widely adopted. When many key businesses begin using a technology and begin touting it, there is a good possibility that the technology has a future. When all key businesses begin using it and evangelizing it, there is an even greater possibility that the technology has a future. When the technology solves key problems, is simple to understand, and is adopted by all key businesses, its success in the future is almost ensured.

One of the major indicators of a successful technology is its adoption by key business players.

The maxim that we defined in this section seems to be a good way to partially predict the success of Web services. One of the main factors that is driving this market is business adoption. When giants such as Microsoft, IBM, Sun, and the open source community agree on something, it is not only a major milestone, it is a sign that whatever they have agreed on has a big future. In the Web services arena, this is exactly what has happened. The development of the open standards for Web services has been an open-industry effort, based on partnerships of vendors and standards organizations.

Of course, it is hard to predict the future, but because of the adoption of Web services protocols (SOAP in particular), the future is very bright.

How Can I Use Web Services?

Now that we have discussed the widespread adoption of Web services, as well as the problems that Web services can solve, you need to decide whether to use Web services in your business, and if so, how to use them. This section provides ideas on how Web services can be used. If you are an application vendor, you need to have a SOAP API to your application, because it is now a common API for all platforms. If you are a business that provides services to individuals and other companies, the previous section may have provided you with new ideas. If you are an organization that has many legacy systems that work but do not interoperate, you may find that you can easily adopt the Web services model for your business. Because the value of Web services is interoperability, you can use the technologies to solve your business problems, focusing less on the technology and more on your business process. The promise of networked businesses will not be realized until we can rapidly and dynamically interoperate. Within an enterprise, this is called Enterprise Application Integration (EAI). Between enterprises, this is known as business-to-business (B2B).

EAI is currently the killer app for Web services. Because we are at the stage of Web services where legacy applications can be made Web service-enabled via SOAP, EAI is achievable now, this is currently where the real value is. Most analysts believe that organizations will adopt Web services "from the inside out.' That is, intranet applications such as enterprise portals, where many data sources are integrated into a federation of data stores, will flourish. In integration projects, if your systems have SOAP interfaces, integrating them will be easier. Tying together your internal infrastructure, such as Enterprise Resource Planning, customer relationship management, project management, value chain management, and accounting, all with Web services, will eventually prepare you to interoperate with business partners on a B2B basis. More importantly, Web services allow you to integrate your internal processes, saving time and money.

B2B may be the future of Web services. Currently, folks at OASIS are working on standards that provide common semantics for doing business for Web services. This will be the next step in Web services development, and most business analysts believe that organizations that deploy Web services internally will be prepared for the next boom in a mass B2B marketplace. We feel that there may be an intermediary step: As your organization uses Web service technology to integrate your processes, you may be able to use Web services to do business with your private business partners, performing B2B on a smaller scale on private extranets.

In conclusion, there is a good case for Web services in most businesses. The chances are that you will need to integrate many internal systems with an EAI solution, and Web services makes this easy. If your company does systems integration, your integrators should look to Web services to easily connect legacy systems. If your company develops a server software product, creating a SOAP interface to your product will absolutely be necessary, because there is such a demand for Web service-enabled products. If your company is currently pursuing small-scale or large-scale B2B solutions, you should look to Web services as the next step for doing business. Finally, we would like to underscore our point that the near-term evolution of Web services will revolve around EAI.

From: The Semantric Web, H.C. Deconta, L.J. Obrst, K.T. Smith. Wiley Publishing Inc. ISBN 0-471-43257-1

CORBA, the Common Object Request Broker Architecture, provides an object- based approach for distributing computing in a platform-independent, language- independent way, in the 1990s, CORBAs main competitor was Microsoft's DCOM. Some people believe that because of the friction between these two technologies, because of the complexities of CORBA, and because object request brokers (ORBS) were necessary for these technologies to work, there was no unanimous adoption. SOAP is also a platform-neutral and language-neutral choice, but a major difference is that it has widespread industry support.