Markets are created when something is provided that didn't exist before. Markets explode when that capability becomes compelling - e.g., the new offering becomes dependable and usable by a large volume of people who derive significant value from it. Web services does the latter. It will cause business use of the Internet, both external and internal to companies, to explode.
Assessing the Hype
Why is this the case? What significant value will organizations derive from Web services? Most of the answers to these question can be found by examining the current state of the integration market. The use of networks to exchange information between applications and companies is referred to as "integration." It's a market, and unfortunately, it's complicated. The data is in different formats, in different places, accessible through complex interfaces, and exchanged by transferring data across unsecure networks.
How do Web services address this issue? In technology, whenever complex problems are addressed, the ultimate solution shows itself by factoring the problem correctly and partitioning the problem into smaller units. Then the total solution is realized by leveraging and using the smaller solutions. A critical factor is that "lower-level" technical issues are hidden from the problem solver at the next level up. Web services has the potential to do precisely this for integration.
A classic example is the personal computer. A PC is composed of a chassis, a motherboard, and various components such as graphics cards that connect into the overall system. Those parts are, in turn, composed of other, simpler, "off the shelf" components such as integrated circuit chips. What are the key components to this success? The appropriate partitioning of the problem, opaque interfaces (e.g., standard and common interfaces that hide the complexity behind them), and standardization, so that problem solvers can easily understand and leverage work done by others.
So what does this have to do with Web services? Let's examine the overlooked aspect of the word "service." In the example of the personal computer, an integrated circuit, generally on a chip, provides a service to the board designer - who no longer has to be concerned with the inner workings or nonstandard interfaces of the integrated circuits - they just plug in the chips. Similarly, a Web service provides a business function to the service user, who no longer has to deal with the technical APIs of some proprietary application or some obscure communication protocol.
A key element in the hiding of the complexity associated with a particular business is a well-known mechanism for describing the nature of the business function. The Web Services Description Language (WDSL) standard is the means by which Web services hides the complexity of a particular business function. It also allows multiple services to express themselves differently but in a way that can be interpreted by anyone who understands WSDL. Thus, all services are expressed in a common manner, and in a way that hides the complexity behind them (called opaqueness). The normalization of the interfaces is the key to scaling into larger systems without creating expanding complexity.
Today, integration software vendors provide tools to leverage the individual and proprietary APIs of packaged and custom-built applications. This is similar to having a PC manufacturer build a different interface for each graphics card on the market. Even worse is the application-server approach, which is equivalent to having the PC vendors build their own graphics cards out of the lowest-level components, which would require all software to be custom developed for the particular environment on which they are to run. As we encapsulate the service logic using Web services, more leverage is achieved through abstractions, productivity soars, and the market explodes.
Properly designed to expose business functions, these services can be accessed from a heterogeneous application, another business unit, or even across the Internet - all without any understanding of the implementation of the service. That, in short, is revolutionary.
Web services hasn't been overhyped. It's been mis-hyped. It's about integration. Time will show that its promise for changing the way companies do business has actually been underhyped.
What Corporations Want
Today's CxOs have a burning need to more efficiently integrate the numerous proprietary applications and legacy systems that make up their enterprises. Web services applied at the enterprise level can directly address that need.
Over the past several years, companies have invested heavily in their IT infrastructures, particularly in new ERP, CRM, and supply chain management systems that streamline and automate business processes. In the early stages, plugging those systems into existing mainframe and legacy applications (or even making them work with each other) was a very costly and messy business. Making things work together required a lot of hand coding, sometimes with a little help from middleware. This generated the usual problems with flexibility and maintenance, not to mention cost.
Of course, this challenge created an opportunity. Enterprise application integration (EAI) stepped in to bring a "product" approach to the problem. The result was that over half the time and cost involved in integrating systems was removed. And with an integration infrastructure in place, changes could be made to the business processes without having to call in the systems integrator troops.
This has created a new way of looking at existing IT resources. In the past, mainframe applications and legacy databases have been viewed as resources to be connected into. Now, with an integration infrastructure on top - built using the new Web services standard - those resources can be turned into services.
Note that this discussion has centered around leveraging existing applications, because that's where the market is. There are already components and interfaces at the application object development level using the J2EE or .NET technologies. The benefit of Web services is not realized at the local method invocation level between software components. That problem has been addressed. It's at the business-service level (using WSDL) where services are called across the network (using SOAP - Simple Object Access Protocol).
When built using an enterprise integration platform, Web services can be created without writing code. This capability is markedly different than using application servers, which were created to facilitate programming through the use of a single machine language-based object paradigm. The only users of application servers are programmers. The targeted users of an integration platform are nonprogrammers.
In summary, CxOs can leverage their significant costs in their primary mission- critical applications without changing them, without risking their operations, and without writing code.
Enterprise Web Services
Let's state the obvious. You can take any piece of software and turn it into a Web service by simply putting a Web interface on it-that's what WSDL is all about: a complete separation of implementation and interface. There's nothing about a Web service that dictates its weight or robustness. It could be something trivial built on five lines of code.
Enterprise Web services, however, the kinds of functions serious companies will be using in serious ways, will be used in mission-critical settings and incorporate important attributes such as transactional control, security, management, and the ability to be orchestrated in a business process.
Before companies begin leveraging their internal mission-critical IT investments and/or begin publishing them to the outside world, it will be critical for Web services technologies to meet three fundamental requirements:
- They'll have to provide a mature, comprehensive, enterprise mechanism for integration.
- They'll have to facilitate the utilization of Web services in conjunction with all other IS resources to define end-to-end business processes.
- They'll need to support a management infrastructure that ensures Web service providers are able to meet their service- level obligations.
In particular, the ability to manage an external Web service at the same level or an even greater level than they might internally is critical. It's the only way companies will allow themselves to depend in a mission-critical fashion on Web service technology.
No Replacement for Integration
In their zeal, some promoters of Web services technologies have advocated that the new standards will replace the need for integration platforms. But let's be clear: Web services is not synonymous with integration.
Web services as a technology does not cover important integration topics such as data transformation, transactional integrity, queuing systems, publish and subscribe models, human intervention (workflow), adapters to existing interfaces, security concerns, and business process modeling. A full integration system transcends Web services and delivers a much broader set of capabilities.
The Standard Approach
The importance of Web standards in bringing about this evolution cannot be overstated. Standards are more than something to be adhered to - they're what it's all about.
The key driver behind what is taking place is the customer's desire to automate business processes across systems, both internally and externally, and to drive down the cost and time involved. As with all evolutions, it starts with the implementation of basic functionality and then evolves into a set of standards. Standards then lead to open systems, which benefit the customer economically.
The importance of Web services is not that they are cool, or that they are an advancement in technology, but that they represent the beginning of standardization applied to the integration market.
This is huge. It will drive difficulty down, resulting in reduced costs and time. There are ongoing multiple standardization efforts in the industry to facilitate the deployment of Web services. However, a few key specifications have established themselves as the de facto standards associated with Web services. These specifications and technologies address the following core functional areas:
eXtensible Markup Language (XML): A key standard for providing a platform-neutral syntax to represent data. Many Web services use XML for representing data and XML Schemas to describe data types. Because of this, Web services are often referred to as XML Web services.
Simple Object Access Protocol (SOAP): Defines a lightweight protocol for XML document exchange, and provides a convention for Remote Procedure Call (RPC) using XML messages. It serves as a simple model to envelope and encode request and response messages exchanged between Web services.
Web Services Description Language (WSDL): An XML-based contract language that provides a simple way to describe how to invoke a Web service and provide information on the data being exchanged. It can be thought of as an XML-based language to describe Web service interfaces and the protocol bindings for accessing the services.
Universal Description, Discovery, and Integration (UDDI): A cross-industry specification for a registry of Web services. It provides a way to register Web services descriptions in a registry, enabling discovery by potential users of the services. Web Services Inspection Language (WSIL) is another specification that assists in the inspection of a site for available services.
Open Management Interface (OMI): Another key standard that doesn't receive much attention. Coauthored by webMethods and HP, OMI is the lingua franca combining integration software with systems and enterprise management solutions - and thus as a standard for managing Web services.
Together, these standards offer a way for applications to be ready-made to work with one another. The result is that things will "snap" together as opposed to having to be "glued" together. That's a tremendous benefit to corporations because it will allow them to accelerate their integration efforts and dramatically drive down costs.
It's also a major reason why it's important when selecting an integration platform vendor to evaluate who's leading in the adoption of Web services standards. Not because standards are inherently good, but because they will revolutionize the economics of integration.
Where Is It Going?
Where will Web services make its first big impact in business? I firmly believe companies will begin by experimenting with Web services internally. The new Web services standards that have been built into integration platforms will first be used to link internal applications. IT staff will then begin creating new Web services for their internal constituents based on that integration infrastructure. This will happen not only because it offers a low-risk introduction into Web services technology, but because it also offers the biggest return on investment.
Once the integration groundwork or plumbing is laid, companies will then reach out to their most important customers and trading partners to automate business practices. This viewpoint is shared by Forrester Research, which recently predicted that most Web services will be concentrated around transactional connections internally, and with key trading partners later.
Why will this happen on top of an integration platform? Because it's the only cost-effective way to do it. Just think of the challenges involved in creating a Web service that leverages customer information. In most typical Global 2000 companies, customer information is stored in a wide range of systems, from mainframe and legacy systems and databases, to newer CRM and ERP platforms. If you were to build a Web service that required access to customer information, you might have to go back in and create connectors to 10 different back-end systems to get all of the information that makes up the whole customer picture.
Corporations want to be able to gain access to and create that whole customer record for their own purposes now, without even planning ahead to the day when they will roll out Web services. That's why so many are moving ahead with internal integration programs. But once that integration is in place, it becomes a relatively simple matter to create a Web service to allow others to leverage that customer information in new ways.
With the new technologies, it can be done without disrupting the existing business rules and business processes, by adding a service interface to the application(s) and exposing that to service consumers. It's simply another form of integration.
From the consumer's viewpoint, if you're going to orchestrate a Web service into your business process, you will require that Web service to be reliable, to protect against potential harm to your business. Subscribers of Web services, or any computer service for that matter, have generally looked to define a service level agreement, something that binds the provider to meet certain service levels at the risk of paying serious penalties.
That's a fine concept, but you have to be able to manage the Web service first. As Forrester notes, the industry is still far from agreement on Web services management. Management and monitoring (as well as security) are issues that an enterprise-scale integration platform addresses today, and why Web services will not replace the need for integration.
The Complete Picture
By reaching a consensus around new Web services standards, the computing industry is about to usher in an exciting new era.
The standards are already helping to drive down the costs and time involved in integrating systems, and that will accelerate the adoption of integration technology within corporations. Companies will begin by getting their own houses in order, linking internal applications and databases to create a true corporate-wide picture of their customers and business operations. They will then be able to leverage that infrastructure to roll out enterprise Web services, aimed first at internal constituents, and secondly at their most important customers and business partners.
As new standards are brought to bear addressing key issues such as security, support for transactions, and business process management, we will begin to see the emergence of a wide range of serious public Web services. Benefits will be derived by consumers, platform providers, software vendors, and a new class of service providers. The economics will drive the momentum, and everyone will win.
|
