Is there an end game with Web services? Where do you see them a year, three years, five years from now? I think...
what's going to happen is over the next two years, from a security perspective, most of the standards will be ironed out and you'll be seeing broad implementations of the security standards there.
There's going to be a tremendous amount done this year in terms of standardizing around management. It will probably be 2005 before you start seeing products built on management standards and specifications. And that will take a long time.
The hope is not only that you want to manage Web services themselves [but entire systems using Web services]. Web services are fundamentally designed to connect heterogeneous systems. When you're dealing with management, you want to manage resources from all sorts of people. If you can use Web services technology to manage all these things....I will predict that in five years it will be possible that things like disk drives will be managed using Web services under the covers.
This technology will become so pervasive about the standard way you use to communicate [not only] between pieces of software, but the hardware resources as well. You get incredible uniformity. You can use the same tools and constantly reuse these things. And again, you can build better management things on top of them -- what we call autonomic computing. Which is one way of saying all these intelligent things you thought computers could do and found out they couldn't, autonomic computing is making that happen.
And Web services will go a long way to making that happen. It's all about simplification and efficiency.
Interoperability -- the whole point of these services is that we can talk together and why we started the Web Services Interoperability organization. They've produced one profile already and they're talking about a lot of security issues already. It's based on best practices, which means that it lags the creation of the standards because you want people to start playing with them. You don't want to just make up best practices. You want to see them from actual experience.
The third area is management. That's a very new area. There are a number of smaller companies in that space as well as larger companies like IBM that are doing something. If you think about accumulating Web services, if you have only three projects, you can kind of go over and kick them and see if they're working. If I have 15 or 20 of them, I probably want some sort of automation going on here.
The same thing [applies to] moving into workflow where there are dependencies going on. If this thing goes down over here or it's operating too slowly and it's just one part of a larger workflow, it's going to affect the overall process. How do I pinpoint the problem? How do I get the right type of information to fix it? Is security still a big inhibitor right now, or is it the glut of standards that is the biggest barrier for Web services? What are CIOs telling you?
It's not an inhibitor. CIOs are telling us three things, and security is one of them. A lot of the security that you do today you can do by brute force. Let's say I send a purchase order from me to you. Security today, I can encrypt the whole thing. But once you get it, you have to decrypt it. If your job is to then hand it off to somebody else, you've lost all my encryption. You may have to encrypt it again.
With the new types of standards -- and there's not a glut by any means -- there are requirements that you have to satisfy. For example, WS-Security saysif I just want to go in and encrypt this one credit card in the message, I can do that and you can send it along to others and that's all we have to worry about. If I'm passing around patient health care information and I want to make sure a particular section is digitally signed by the laboratory that did that medical test, I can do that as well.
Then there are issues about credentials as well. Let's say I decided to outsource my human resources functions. They keep track of salary and pension information etc., so how can I let my employees sit down at their laptops, desktops and in addition to accessing everything inside my company, seamlessly go in and view their personal information and do updates to their information? How can I bridge these domains and deal with credentials that we both understand?
So the standards are all about providing this level of fine-grain security that lets people knit together the different security systems that they've paid for and want to keep using.
There's not a glut. We have a list of what we want to accomplish and the standards refer to different aspects of those requirements.
We've identified three ways. The first one is what I call the accumulation phase where a company pilots a number of Web services. It makes sense to do a few at a time because a company wants to get some experience, see what its developers can do, educate its developers and also get a sense on what the return on investment is for a particular setup. Therefore, as I start accumulating these things, I know what the next project will do.
And as a company starts accumulating these things, it needs to start thinking about them more as a whole than as a bunch of separate things.
The second phase is based around the notion of workflow and choreography. You're involving different services in more of a sequential way, a real workflow and logic between the steps. I have dependencies between the services, and I have slightly different questions. I have questions about security of information. So if I start with a bit of customer information here, and I pass it from step 1 to step 2 to step 3, what does that say about what needs to be encrypted, for example, and how. That's the phase I think you're going to see kicked off this year because of the standard called BPEL (Business Process Execution Language) you'll see coming in products from IBM, Microsoft and others as well. We'll all be standards-based and all these issues like security and management will be addressed.
The third phase is where people already have a sophisticated inside-the-company messaging infrastructure. From an IBM perspective, they would have the IBM MQ message brokers and they'll say, "I already have a lot of applications hooked together, how can I build services that tie into this? How can I have applications from one end of this infrastructure invoke a service maybe at the other end of my company or through the Internet from somewhere else?" These are the people who are running SOAP messages across MQ, for example. These are the people who are thinking about a concept we call enterprise services process. This is a notion that these things exist today, it's an evolving category, that says, "What is the backbone that connects the different applications and services together that allows you to put one service out and put another service in with the same interface, but running on a much faster machine?"
SOA is very quickly moving from a discussion of what we can do in XML with Web services, what we can do with Java with J2EE 1.4, which is one of the big things for this year, but moving toward this notion of really incorporating enterprise messaging and tying this all together.