We have the basic building blocks and standards in place for Web
services, and people are using them. Where do we go from here? Obviously, the more mature the standards get, the better the
applications. And in security, there is a psychology at work. There was
a time when people said that you don't want to do commerce on the
Internet because it's not secure. You have to overcome that psychology.
I think there is a little bit of that at work with Web services, and
that's an important thing yet to come. But the big issue is that most of
the effort around Web services has been around the composition of the
service rather than the consumption of the service.
What has happened to confuse the meaning of Web services? How did we
get to this juncture? And how do we straighten things out so that
technology buyers understand it?
Web services is a very broad term and different vendors are promoting
Web services from different angles. It's been all jumbled together, and,
in particular, I think Microsoft has been promoting Web services from
the consumer, individual point of view, rather than from a sort of
back-end IT point of view. And that has tended to get more play in the
press because everybody understands it.
Is that going to divert away from what proponents say will be the
chief benefit of using Web services?
This is something of value that can help solve IT's biggest problem,
which is that systems built over 30 years using different technologies
now have to be integrated and delivered in ways that nobody intended.
That's the big phenomenon, and now it's happening in big companies. Is it
sexy? No. Is it easily understandable by the common man? No. Is it the
most important phenomenon going on in IT? Yes.
But you expect the increased scrutiny will work to the benefit of the
overall technology.
Some of the nastier problems associated with Web services, such as
security and supporting transactions, are getting significant attention
right now. So we have some new standards, like WS-Security and
WS-Transactions, launching. And BPM (business process management), which
is a very important component of Web services and one of the principals
of Web services is combining individual services to make more complex
services.
We are seeing a trend, where anything proprietary can't dominate. When
you define a service, it touches things outside of your environment.
Therefore, anything proprietary, no matter how big it is, can't
dominate. So everyone, including Microsoft, is being forced to the
standards table when (products) touch other areas.
That to me seems to be the most significant part of Web services. The
concepts aren't new. We've heard them before with things like COM
(Component Object Model, a Microsoft architecture for software
development) and CORBA (the Common Object Request Broker Architecture,
an earlier distributed software strategy).
What I think is most important is this: With both COM and CORBA, you
were required to have someone with a highly specialized skill set create
something new. Namely, a CORBA object that was not easy to write. We are
not writing Web services applications--what we are doing is Web
services-enabling existing applications. Web services is much more of a
wrapper technology. It's much less invasive and requires fewer new
skills (for programmers) to create the services.
So in your mind, does that mean we will not go down the same paths as
we followed with COM and CORBA? Meaning that we will avoid the
complexity that stalled or doomed projects to failure?
Absolutely. One of the things about COM and CORBA is that you need both
sides of the (transaction) handshake to understand each other. You don't
need that in Web services. The notion that Web services is just the next
step in the evolution of distributed object models is not quite
accurate.
And so your definition of where this is heading would be what?
We are using very sophisticated software that requires the expertise of
the thing you are enabling--an SAP business application or an Oracle
database, for instance--and it turns it into XML (Extensible Markup Language) using graphical mapping
and transformation tools. Once you have something in XML, turning it
into a Web service is easy. Instead of writing a distributed object, we
have created something that looks like a distributed object, but the guy
on the other end of a transaction doesn't have to be a COM or a CORBA
guy to use it. In fact, a Web browser can use it--it's just XML. In that
way, Web services is fundamentally different than COM or CORBA. Word and
Excel can work with Web services. You didn't see Word or Excel--without
massive difficulty--using COM or CORBA.
Are there alternate ways of doing the same thing? Is there a danger
of a split in agreement on how Web services presentation is handled?
Sure. You can use other technologies. And you may have seen that
Microsoft announced XDocs, where presentation is bound to XML. XDocs is not as oriented to transactional systems or services. It's much more
tied to the Microsoft world and Office.
Here's the reality with Web services: We are moving into a number of new
applications. Companies are not going to rewrite their core
applications. They are going to expose them as XML, and all their new
applications written--portals or whatever they build--will use that XML.
In a very short number of years, most Web-based applications--the
majority--will be dealing with data that is coming across the wire as
XML. So most applications will have to consume XML. And for the
mainstream developer, this will be a phenomenon tantamount to them
learning how to build client/server applications.
Will they need to learn a completely new way to do presentation
programming?
They won't have to do that with Web services, because a lot of these
people already know how to do Web programming. And the average
application developer will not use SQL (Structured Query Language, a
standard for database application programming) anymore. They will use
XML. And that makes sense, if you think about it. Why do we have
specific information about data sources in our applications? It makes
those applications very fragile and easy to break.
You work for a specific vendor, so I'm going to ask you to put aside
your loyalties for a moment. In the client/server evolution/revolution,
there were some big winners--Oracle, Powersoft and Microsoft for
example. In Web services, who will be the clear winners? Or is it a more
level playing field, because so much is standards-based?
What are the pieces of the puzzle? We have to create the services, so we
need integration services. You have to be able to create interaction, so
you need personalization and presentation and data binding to XML, which
requires portal software and content management. And you need an
operating environment, and that's going to be either .Net (Microsoft's software-as-a-service plan) or J2EE (Java
2 Enterprise Edition, a standard for Java business application
development). You need development tools. You need identity management,
so you need directory services. And you need security. Later, we will
see Web services management.
It's pretty clear that the companies that will provide all of those
pieces will not be start-ups. They will be established players. I think
it is going to be a large vendor game. I think the vendors have to have
all of these pieces and be committed to standards and so forth. The big
vendors are coming from a lot of directions. Sun Microsystems is from
hardware, SAP from ERP (enterprise resource planning software),
etc. You can go through the list. So I think the market is going to
shape up where it is fewer than 10 players, and probably more like six
or seven major players. And some of those players will get dragged down
by their over-reliance on one specific application, database, operating
system or piece of hardware. This technology is inherently
cross-platform.
What don't we have in place now? You mentioned management as one
item.
Management is very early on, and there are some start-ups here, and
security, which is coming along. This XML client area needs to come into
focus, and, of course, transaction management.
Back to Vision Series
intro
