By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
The definition of Web services
by Dr. Bob Sutor, Director of Web Services Strategy, IBM
I just got back from speaking at a Web services conference where I was dismayed to find that people were still joking about "the many definitions of Web services." I hope they were joking, because for those of us who have been working in the trenches on the technology and explaining the business value of the technology, "Web services" is quite well understood and characterized.
Now I'm not going to give you a heavy computer science-ish definition of Web services via "service oriented architectures" and "loosely-coupled distributed systems," though both are important technical underpinnings of why we do Web services the way we do. Rather, I want to describe the requirements that Web services technologies are being designed to meet. In thinking about these, I hope you can identify places in your own business where Web services are now or will soon be applicable.
First of all, we start with an application that you want others to use. That is, you have a piece of software that initiates or accepts business transactions, provides or updates enterprise information, or perhaps manages the very systems and processes that make your business run. You may want to make this accessible to people in other parts of your organization, or a business partner, or a supplier, or a customer. We're really thinking here about software-to-software communication rather than the person-sitting-at-a-browser-talking-to-server-software situation, though it turns out that Web services can be used there as well.
This sounds good, but haven't we done this before? Absolutely, and this is the first important thing to remember about Web services: we've done it all before, and in many different ways, often at the same time. It's this myriad of possibilities that causes such headaches for IT departments. They can end up spending so much time making all the underlying business communication plumbing work that they have fewer resources to spend on the parts of your infrastructure that make you a more efficient business, delivers greater value to your customers, or more clearly differentiates you from your competitors.
Web services reduces this complexity by bringing down the number of choices to a few manageable, best-of-breed technologies that can be used over and over again in different combinations. This means less training for your IT staff, greater efficiency in building new applications, and significantly greater and faster interoperability. I hope this appeals to you!
So we now have a service we want others to use. Just because we build it, that doesn't mean others will know how to find it or interact with it. So we need a standard that says "this is how I write down how I talk to the service and what it says back to me." With that in hand, we can then standardize how to publish enough information about the service so that others can find it. This process of discovery might, in fact, be trivial: I may just email the description of how to interact with my service to my colleague whose software needs to use it.
As Web services get increasingly deployed as part of what IBM calls "e-business on demand," we'll see greater automation and software that can dynamically locate and use the services they need. One of the best examples I can think of for this is that I may maintain a registry of my known suppliers with whom I've negotiated deals. The registry contains descriptions of Web services provided by my suppliers that allow me to request quotes as well as place and track orders. With this in place, I can automate a large portion of my procurement process, including negotiating with multiple suppliers to get what I need at the best price. It's easy to add new suppliers to such a system.
We may need one more thing at this point. For very local Web services we can use traditional software programming methods to actually pass the needed information to and from the services. When we want to use the Internet or an enterprise messaging product like IBM WebSphere MQ to send and receive messages, we may want to wrap up the information in a standardized electronic envelope. Think of the chaos that would exist if your postal system had no rules for what an envelop looked like and where you put the stamp, addresses, and letter to be sent. We need to avoid such problems in the electronic realm as well, so Web services includes a specification for an electronic envelop and conventions for how to exchange messages using it.
To recap where we are: Web services provides standards for an electronic envelop, a language for describing how you talk to a service and what it says back, plus techniques for publishing and discovering these descriptions.
These features alone provide a tremendous amount of leverage and efficiency. Via these we can simplify the software development process, the communication infrastructure, and the maintenance of our systems. The standards for these are well underway and some products like IBM's WebSphere are already in their second generation of support for them.
We're not done because we haven't dealt with reliability and security. In this context, "reliability" means that when we send a message to a Web service we will know with certainty that either the message got there once and only once or else it did not get there at all. This is important: if I use a Web service to place a $1 million order for my manufacturing operation, I will have big problems if the order does not get placed or gets placed more than once. Remember, calling someone of the phone doesn't count as a solution here!
Security for Web services is more sophisticated than the security we use for sending credit card numbers around the Web, although many people are using exactly that technology for their early Web services deployments. For Web services we want to be able to encrypt selected parts of the information we exchange and also digitally sign different portions. For example, if my health care record is part of a Web services transaction then my name and social security number might be encrypted while the parts of the record coming from my various physicians and lab reports may be digitally signed to ensure authenticity.
Let's use an outsourcing example to illustrate another requirement. Today my business keeps all employee information in-house in an ERP system. My employees can sit down at our intranet portal, enter their serial number and password and get full access to their job and salary histories, 401K accounts, and so on. Security is provided in some way so that only the appropriate people get the ability to view and update HR data. Now suppose I want to outsource all these HR data functions to a specialized company that can provide greater value and additional features. This company has many clients and through the years they have developed their own security system. I am not willing to change my intranet security infrastructure to match that of the HR company. Can we somehow bridge this divide so that my employees can still seamlessly access their data while only having to remember their single serial number and password?
The IT industry is now working on standards to provide these kinds of Web services security features. We have a good roadmap of what needs to be done and you should see products start to appear in 2003 from IBM and other vendors.
We've now augmented the basic Web services definition above (electronic envelop, description, and so on) with requirements for reliability and security. There's a bit more to look at and then we'll be done.
So far we've only talked about interacting with a single service with appropriate security and reliability. I seriously doubt that for any company there is one "super service" that does everything they need to run the business and allow others to electronically communicate with them. We need to have some things that explain how and when to talk to several Web services and include the logic that drives the whole process. Let's use another example. This is oversimplified, but you can fill in what I leave out to make it complete.
My company does simple assembly and distribution of chairs with two parts, a cushion and a metal frame. I have a number of suppliers that can provide me with these parts.I just received an order for 5000 chairs via a public Web service I provide for my customers. The first thing I do is run a credit check on the customer via a Web service my financial services company provides. If this comes back negative, I might reject the order or demand an alternative form of payment before I do anything else. Let's assume, though, that this is fine.
Next I check my inventory (via a Web service, of course) to see if I have the 5000 chairs in stock. I only have 2000, so I need to manufacture 3000. I must now ensure four things can happen: I can get enough cushions, I can get enough frames, I have the manufacturing capacity in my factory to get the chairs to the customers when they are requested, and my shipping company can deliver them in time as well. All four of these things must happen: it does me no good if I can get the parts but not make the chairs. My communication with my suppliers, my factory management application, and my supplier will all be done via Web services and coordinated. Assuming all these things can happen as needed, I order the parts, build and then ship the chairs.
The sequencing of Web services with the necessary decision making goes under several names including workflow, choreography, orchestration, and business process automation. When you need to ensure that several things must all succeed as a group you are dealing with transactionality. Real business scenarios involve combining both of these techniques. IBM and other companies have been providing workflow and transaction products for many years. The difference now is that the units of activity are Web services. Some very good specifications have been published for how to do this and I expect to see standardization start in early 2003 with products based on the developing standards first appearing later in the same year.
We've just augmented our Web services definition with two new requirements: workflow and transactionality. There is only one thing left to describe to complete what I consider the core technologies of Web services. Everything else you hear about is either contained in these areas or is an application of them.
When you deploy applications or networks that are critical to your business you manage them. That is, you don't just hope they keep running but rather you monitor what they are doing and how fast they are doing it. If something is wrong, you do whatever is necessary to get your system running at the performance required to successfully run your business. For example, IBM's Tivoli products manage enterprise applications, among other things.
How should we manage Web services? Perhaps we don't have to do anything! They are just pieces of software and we've been managing them for years, so do we really need to do anything special? We can and we should.
Web services allow me to standardize the way I talk to similar applications. In the chair manufacturing example above, if all my cushion suppliers allowed me to order their products using the same vocabulary, my procurement process would be simpler. I could ask exactly the same questions and make the same requests of each supplier. When I get this degree of homogeneity my life becomes much simpler and I can automate more.
In the same way, if I can monitor and adjust the performance characteristics of multiple Web services using the same vocabulary for each, I can write better and simpler applications to do the actual management. I can also use the development tools and techniques to handle both the function-specific interfaces (for example, inventory checking) as well as those I use to manage the service while it is running. I think this use of Web services is one of the more elegant ways the lower level features can be reused to provide advanced capabilities.
We can sum up everything we've talked about in the following way: Web services standards and technologies allow us to describe and deploy applications or services on a network in a consistent way so that they can be discovered and invoked in a secure and reliable manner. A "web service" is an application that uses these standards and technologies. It is likely that a given Web service will be employed as part of a larger set of transactions or involved in a business process or workflow with many activities. Once deployed, we want to manage these applications via Web services interfaces so that we can deliver the quality of service our customers and partners require from us.
That's it! That's what the IT industry is creating standards to do and what all those "Web services enabled" products are supposed to do.
Note that we did not have to speak about specific operating systems, programming languages, tools, databases, CRM systems or anything like that to define Web services. Your choice of development platform and runtime is important to you, of course, because you need to make good use of your existing software assets as well as the skills of your IT staff. That said, a user of your service should not be able to tell how you built it. This gives you the flexibility to put your service on the platform that makes the most business sense to you and delivers the quality of service your customers require.
Dr. Bob Sutor is director of Web Services Strategy for IBM.
About Dr. Bob Sutor:
For more information:
- Looking for free research? Browse our comprehensive White Papers section by topic, author or keyword.
- Are you tired of technospeak? The Web Services Advisor column uses plain talk and avoids the hype.
- For insightful opinion and commentary from today's industry leaders, read our Guest Commentary columns.
- Hey Codeheads! Start benefiting from these time-saving XML Developer Tips and .NET Developer Tips.
- Visit our huge Best Web Links for Web Services collection for the freshest editor-selected resources.
- Visit Ask the Experts for answers to your Web services, SOAP, WSDL, XML, .NET, Java and EAI questions.
- Couldn't attend one of our Webcasts? Don't miss out. Visit our archive to watch at your own convenience.
- Choking on the alphabet soup of industry acronyms? Visit our helpful Glossary for the latest lingo.
- Discuss this article, voice your opinion or talk with your peers in the SearchWebServices Discussion Forums.