Web services were created around the notion that it’s easier to discover and leverage somebody else’s service, rather than write your own from scratch. Also, it is much easier to create applications made up of many services, allowing change to occur at a pace faster than anything we’ve seen in the industry thus far.
The idea of Web services was to create a standard interface, programming model, description language, and a directory which would allow this to happen in and between very different systems. Indeed, today you can leverage services across the Internet that are functionally equivalent to the services being hosted locally. This is becoming a very important component to Web 2.0, or the ability to mix and match “outside-in” services for use within enterprise applications.
Taking this concept to the next level, we can build applications (composites) through the selection and use of these Web services. For instance, we have no need to write a logistics subsystem if one exists on a server someplace for you to leverage it. No need to write a risk analytics application; instead leverage somebody else’s work. You get the idea. This is clearly a more traditional computing concept than something new, thus saving a ton of time in the application development process and allowing businesses, large and small, to become more agile and have a much more cost effective IT. This is the promise behind SOA, and outside-in services will clearly deliver on that promise.
We are moving toward a world where many of our application needs, both delivered through an interface and as Web services, will be satisfied by entities outside of the enterprise. Forward-thinking organizations that are able to grasp and exploit this concept will improve their competitive advantage. Those that must hug their servers and won’t allow this new concept to take place in their enterprise because of control issues will be analogous to those who refused to hook up to the Internet for security reasons 10 years ago. Eventually the wave takes over.
Creating the Links
What’s nice about this type of open distributed computing model is the fact that it provides “natural integration.” This occurs for many reasons, including:
- The use of open interfaces to exchange information and leverage services, and thus the ability to leverage both information and services without a lot of retooling and customization.
- The use of standards to define the interaction, including standards such as WS Transaction, the “Reliable Messaging” standards, as well as emerging security standards such as SAML, WS Security, and Liberty Alliance.
- Finally, the standardization of process orchestration that exists above core interfaces, and even interaction standards, allowing process architects to define and change processes as needed, no matter what types of systems actually house the source and target information and behaviors.
However, this natural integration does not come without a cost. Those who own core systems of record must abstract their systems’ behaviors and information, exposing them using standard interfaces such as Web services. Moreover, you must build the interaction and process orchestration infrastructure above the existing exposed systems using integration technology.
Renting Services
Considering that we both understand the benefits of leveraging Web services and are willing to change our existing systems to support the exposure and leveraging of services, now what? The next step is brokering, or, allowing consumers of services to find producers of services. There are a few instances of brokers today, including StrikeIron, Jamcracker, and SalCentral.
Keep in mind that these brokers are also similar to directory and governance systems we are defining in SOAs today, however their existence on the Web means that they also provide central sharing of services, service reviews and other centralized information sharing, and the ability to support fail safe, scalability, and continuous management through economies of scale. In other words, you’re able to leverage a service that somebody is always watching, and managing. That’s much more than you can say for traditional enterprise systems.
These brokers, and brokers yet to emerge, will provide a few key features to facilitate consumers finding producers, and the ability to monetize this interaction, including:
- A directory service where the Web services can be found, containing a description of the service, owner, technology documentation, etc..
- An ability to charge for the service, either through a perpetual license, or a pay-per-drink kind of arrangement.
- An ability to share reviews and other user information with other services users.
- Ability to support a federated identity infrastructure.
Thus, like monetized Web sites today, you’re able to create a service, register it with a broker, and sit back and see the usage turn into fees for use. You can count on seeing many companies, such as the on-demand application service providers today, beginning to sell their Web services versus simple browser interfaces to applications. Clearly, Salesforce.com and Netsuite are moving in this direction. Moreover, we’ll see smaller players, such as the “one guy and a dog” hit it big time as they create that killer service that everyone wants to leverage.
These brokers are beginning to appear, and it’s only a matter of time before Web service brokering becomes as commonplace as the auction sites today, such as eBay. Perhaps guys like eBay will make inroads into this new space. Clearly Amazon is gunning for it with their recent patent application, looking for an exclusive with this new model.
However, in order for this notion to be successful, we really must consider the brokering Web services as something that all can get involved with…those creating and selling services, those brokering services, and those consuming services. We’ll have to let the market determine who the leader is in that space as time goes on. In the end, I think we’ll all be surprised.
