Another response from an e-mail question from a blog reader: "How is SOA and Web 2.0 related?" Here is a quick response:

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 (composites), 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. Moreover, we can support access to valuable information as needed, when needed, within whatever application. This is the promise behind SOA, and outside-in services will clearly deliver on that promise of making SOAs more valuable.

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 or Web service providers today, including StrikeIron. These guys provide a single stop shopping and management mechanism for those looking to consume those service. In other words, you sign up, find the service you need, download the WSDL, and you're in business.

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.

Think of the PC before the Web. While it did have value, the Web provided the current content, and that made all the difference. The same with emerging Web. Just think services and machine to machine information exchange using standards interfaces. The world is heading in this direction quickly, and SOA not only becomes the core enabling architecture, but liberates existing information contained in legacy, as well as provides a mechanism to consume services from the Web. Indeed, SOA and the Web 2.0 are married. In fact the Web could become the mother of all SOAs very quickly.

Posted by Dave Linthicum on February 15, 2008 04:46 AM