The Impact of Web Services
What's New in Web Services?
Simon Phipps: To give context to our discussion, there has been a trend in computing toward loose coupling of systems since the mid-1980s, when the mainframe manufacturers unbundled software from hardware. More recently, Java was about the loose coupling of software from platforms. XML was the loose coupling of data from programs. Now we're seeing a trend toward the loose coupling of the end points involved in cross-functional boundary transactions, and that trend is called Web services.
But that term is being used to represent at least three different concepts—the overall context of loosely coupled transactions; individual applications designed in that context; and then the raft of technologies—SOAP [Simple Object Access Protocol], UDDI [Universal Description, Discovery, and Integration], WSDL [Web Services Description Language]—that are used to build them. Can we get some precision about the language and some precision about what's happening in the marketplace at the moment?
Ted Shelton: From Borland's perspective, the core of what Web services are today is an interoperability standard that takes us a further step in the loose coupling of systems—from standards for building distributed applications around things like CORBA to being able to build truly message-based architectures for applications. We see WSDL, XML, SOAP, and UDDI as core technologies, but it's just a foundation layer. Today, and probably for the next 12 months, that foundation layer is what we'll all agree on, and over the next 12 to 18 months we'll disagree and innovate around the rest of what's necessary to go to the next level of robust messaging-based architectures. Eventually we'll have to agree on those things as well.
Phipps: Are we reinventing wheels we've actually designed before, or is something genuinely innovative going on?
Benjamin Renaud: There really is something innovative. It's true that Web services is distributed computing at its core, but it has some truly revolutionary qualities. Loose coupling through XML is one of them. The ability to interoperate is a key value proposition. The fact that the Web services standards are based on underlying Web standards is a powerful thing that will help their adoption.
Support for asynchronous-based computing is another key ingredient. Distributed computing, especially across the Internet, deals with end points that are potentially unreliable and with networks that have qualities of service that vary widely and can't be relied upon. A system that will support asynchronous programming at its core is critical.
Perhaps most important is the idea of extending these qualities to an external layer that is services-based and course-grained. You don't have, as you do in CORBA, the ability to control objects that are on the other side of the country. Instead, you call course-grained services and you pass XML. It does work and then gets back to you. That constrains the developer toward an architecture that will work and scale. Because of all these things, I think Web services stand a good chance of becoming the true distributed-computing model for the next decades.
David Chappell: An important aspect of this is that XML abstraction allows people to think about how to plug together applications and services in a corporate-wide infrastructure without thinking about all the details of the other end services that might be communicating. You plug into the bus or the cloud, and the loosely coupled separation takes care of the rest.
I agree that asynchronous processing is key as well. If you think of the complexities of multiple applications and processes having to communicate, with asynchronous processing they don't have to be up and running at any given time for an overall system to remain healthy.
Return of Distributed Computing
Simon Pepper: At the end of the day, Web services is about distributed computing. In some ways, it's a different way of looking at it, but the technologies and the concepts of distributed computing and of object-oriented technology have been around since the mid-1980s. Its primary use is going to be for application integration, which is where the idea of exposing application assets as Web services and allowing them to integrate through interoperable protocols and interfaces has the potential to bring together enterprise computing. Organizations will communicate with other parties, either internal parties or outside organizations, going through demilitarized zones and using XML-document-passing protocols or exposing stuff right out onto the Internet for the general consumer to use.
Phipps: Is that why people are rushing into using Web services technology without waiting for it to get standardized? Is it because the concepts are so well proven and so transparent that we are willing to do that, or is there some other reason?
Neil McGovern: I think the excitement about Web services has converged into two heavily publicized technologies—XML and the Internet. The concept of distributed computing based on Web services is something the CIOs I've talked to understand. The adoption curve is going to be interesting because it seems that it's seen as something that everybody will need to have, but nobody can figure out exactly why it's going to be important to them in the short term. The consultants I've worked with that are building Web services-based technologies and companies like Sun are having a problem getting the adoption of Web services from legacy systems. People are asking, "What's in it for me?
Steve Benfield: The adoption of Web services will go faster than we might realize, for a couple of reasons. One is that we now live in a server-based world. People have infrastructure in place, and with some minor additional things—not to trivialize it—they can start building and hosting Web services. Having XML as a standardized way of passing data is important, but another factor is just e-business in general. Business people are demanding integration of more things than they demanded five and ten years ago. They want to deliver information to a customer, but it requires getting data from ten different systems to do that. We didn't have that ten years ago or five years ago, but we have huge demands now to meet the needs of all these audiences.
Another reason is cost. In the early 1990s, if I wanted to implement a CORBA solution, I was looking at immense infrastructure expense. You can sit down with a typical business developer and explain Web services to them and, with the right tooling, show them how to get started fairly quickly and easily. Web services today isn't trying to answer all the things CORBA or DCOM tried to answer.
Chappell: If you think of the massive adoption of the Web, a lot of it was around the grassroots movement of people writing CGI programs. The same thing is happening already and it's going to continue to happen with Web services, with people grabbing Apache SOAP toolkits and writing little things that communicate with an application that the guy down the hall has. Then it's up to the infrastructure providers and vendors like us to provide the better architectural solutions, but that has to come later, after all these people realize what they're actually doing.
Ted Farrell: Web services and integrated systems are interesting, but we're not there yet. When we start talking about interoperability between companies and integration platforms, we need to start defining roles and views, which is done now with proprietary technologies. Web services are the protocols and the data transformation and the things a particular role can handle. That's the first step. But for any kind of interesting application, you need to get into Web service orchestration, so you need something on top of it—something like RosettaNet or ebXML. The standards haven't caught up to views and roles yet, but these have to be addressed for all this to work.
Jack Walicki: The standards point is absolutely critical. I think this is the first time the industry is talking standards so heavily. Maybe we learned something from the Unix wars. At the same time, there are almost too many smart people in the territory and you can see a proliferation of standards, especially in the last six months or so, and the beginning of a divisiveness that will hurt us. There's a fine balancing act between competing for our space in the marketplace and actually slowing down the progress of adoption.
That ties to customer value. Some segments accept the concept fairly quickly. Mobile-network operators understand that to put value on their toys, they have to be able to bring new services with fairly low friction. If it's standardized—developed somewhere else and easily inserted into my ecosystem—that's of great value. The points about security, reliability, and service-level agreements are important because conceptually it's appealing, but will it work? We have many proofs-of-concept and pilot projects now, but very few large-scale, robust implementations.
Stages of Adoption
Hal Jespersen: We have talked to a lot of customers about how they would roll out Web services technology. We found a three-phase approach would be valid for most enterprises. The first phase is today, where people are doing primarily browser-facing Web applications dealing with human users and a little bit of XML-based Web services. In phase two, they'll use Web services in earnest, but focus them internally within the enterprise, either between applications behind the firewall or going outside the firewall under tightly controlled circumstances. Those would include business-to-employee applications where the employees are already registered in the enterprise directory and you can authenticate and authorize them to use the services, or bilateral B2B [business-to-business] where the two businesses have agreed in advance on what their business terms are, what Web services they're going to use, and what the quality-of-service guarantees will be.
In the third phase, the one that gets all the hype but remains in the future, is a dynamic, federated, commerce phase in which two key pieces of technology have been added to the mix. One key is public-service registries populated with semantically rich information about business processes, such as ebXML or vertical industry consortia. The other key piece is federated identity systems, such as from the Liberty Alliance, which will allow businesses to acquire new customers and business partners by accepting the security credentials of trusted partners, rather than having to register all these users individually in their site.
Adrian Mitu: IBM conducted a study last year of several thousand large customers and classified them in five stages of
e-business adoption. Some customers are at the phase of having a presence on the Web through publishing information. Conducting transactions on the Internet is the second phase. Next comes internal integration, when they start wiring applications internally. The next phase is external integration—going to B2B and B2C [business-to-consumer] scenarios. The last phase is what we call dynamic e-business when, through Web services and other technologies, you have systems automatically configuring themselves and interacting with various suppliers.
Eighty percent of our customers are in either the publishing or transactions phase, and they are beginning to focus on integration of applications. The next several years will see a tremendous focus on componentizing existing applications—all the legacy stuff we have around—and start wrappering and transforming them into Web services that are surfaced in e-business applications. The vision a lot of our customers have is that they'll get the best bang for their buck for existing applications by wrapping them in standardized Web services and then think about replacing those components at some future point.
Walicki: Large corporations' IT departments are trying to play two fronts—experimenting with the technology and, at the same time, trying to reduce the overall cost. In that context, we also see the use of UDDI registries—not the public registries but real ones inside the company that hold the information that's facilitating integration and reuse.
Pepper: Although I agree with Adrian's stages, I disagree with the timing because we have customers in the third stage who are doing external supply-chain integration using Web services. They are finding massive business benefit by taking systems and processes from two weeks—to order shoes, for example—down to hours and can drop-ship the product. Those systems are already deployed. Although we talk about stages of technology evolution, different customers are in different stages.
Mitu: Yes, although a lot of customers are in the first two stages, there are a significant number doing internal and external integration. Absolutely, there are customers that have found business value and a great return on investment in Web services.
Renaud: Web services are really about integration, and what makes it work is the Web effect—you get to the point where Web services are a new type of Web standard, and it catches on fire just as the Web itself caught fire. That has some interesting consequences. Because it's integration and because you end up having lots of enterprises talking to other enterprises, many more applications get written. Opportunities for developing applications become much greater, and that leads to the need for tools. J2EE tools are still way too complicated for the great mass of people who'll write applications for the Web. If we're going to have an explosion of applications like the explosion of content we've seen on the Web, we're going to need really powerful development tools.
This is where the Java community—the people here and the people reading this—needs to come together vis-à-vis Microsoft. Microsoft wants to own the programming model, and as the J2EE community, we can't let that happen. The community needs to come together and start pushing a set of standards that will help bring J2EE to the masses, to the traditional PowerBuilder and VB developers who know how to write business applications. These people don't want to write JCA [Java Cryptography Architecture] or JMS [Java Message Service] or EJBs [Enterprise JavaBeans]. This is critical; otherwise, we will lose the big war.
|