A Web Services Intermediary
It often seems that all of the best practices that we apply to Web services and SOA implementations we first used to implement B2B communications. That shouldn’t really be surprising. Consider the definition of SOA. While some focus on a definition of services as modules that deliver a separation of concerns – loose coupling and reuse – that seems to miss the main point. We’ve had modular development approaches for 30 years; what’s different this time?

The difference between SOA and previous approaches to modular, object or component-based development is this: SOA is designed to allow these modules to be developed, managed, deployed, and maintained by multiple, unrelated development teams. Sometimes these development teams are simply from different departments or different business units within your organization. Just as often, though, these multiple development teams are part of different organizations. Certainly they can be from the vendors of your packaged applications and from the systems integrators that deliver many of your applications. It’s also very likely that many are part of the IT organizations at your suppliers, resellers, VARS, distributors, and even customers.

Given that you, as the developer of your composite application, have little control over the internal design and development decisions that govern the applications that you would like to make into the services, what do you do?

One solution would be for your IT department, on its own, to develop solutions to each of these issues. A better alternative, at least for a fairly large portion of the SOA world, may well be the use of a third-party “SOA intermediary.”

This idea of an independent intermediary that enables integration across organizational boundaries is not new. In the B2B world, we’ve had EDI Value Added Networks (VANs) for 25 years. These VANs are still widely used, despite the many Web-based alternatives that are available, because they provide important capabilities to companies both large and small:

• A VAN can act as a trusted third party to enable secure, reliable communications between business partners. This includes certifying the identity of each trading partner and logging each interaction between partners in order to provide non-repudiation for both sender and receiver.
• A VAN can define and enforce a set of canonical standards for data format and semantics and process semantics.
• A VAN can enable the development and certify the implementation of the interfaces built by each participant on the network.
• A VAN can on-board smaller participants by allowing these smaller enterprises to connect by typing data into a Web form or by e-mailing in documents and then the VAN can convert this data into valid B2B messages.

All of these services that have been historically provided by VANs to enable EDI-based communications can be similarly provided by “SOA intermediaries” to enable more modern B2B connectivity.

However, these SOA intermediaries don’t have to stop there; they can provide additional value-added technical services and commercial services. For example, SOA intermediaries can:

• Convert EDI messages to Web services calls and responses.
• Implement version control so that each service consumer only connects to a valid version of the service provider.
• Provide commercial enablement services like letters of credit, customs clearance or bill presentment, and payment processing.
• Support reverse auctions between suppliers and manufacturers.
• Enable cost-effective service matching between suppliers and transport and logistics companies.

Note that the intermediary doesn’t have to be the entity that actually provides these value-added services. For example, it can outsource many of these commercial services to banks, insurance companies, business process outsourcers, and third- and fourth-party logistics providers.

Why SOA Intermediaries?
While there are hundreds of tools on the market that enable the development, deployment, management, and maintenance of SOA connectivity, these tools are not appropriate or they are not sufficient for some enterprises. First, there are many companies that are too small to effectively enable their own B2B SOA connections; i.e., either their IT departments are too small to allow them to build and maintain the necessary skills or their budgets for SOA connectivity are too small to justify the investment.

Second, there are issues related to the standards that we rely on to enable SOA connectivity, and these issues occur because of the lack of complete, stable, non-ambiguous, broadly adopted SOA enablement standards. If we truly had standards sufficient to cover the protocols, data format, data semantics, and process semantics required to enable SOA connectivity, many enterprises wouldn’t need SOA intermediaries. Alternatively, you could say that an SOA intermediary wouldn’t be as useful if the time and effort required to compensate for this lack of standards was smaller and more manageable.

Finally, there are capabilities that are simply best provided by third parties. For example, in an era where data logs can easily be modified and providing the providence of such files is subject to much guesswork and insinuation, it’s critical to have a trusted third party log all transactions so as to provide non-repudiation of sender and receiver, i.e., I can prove that you received the message that I sent and you can prove that I sent the message that you received.

Given all of that, is an SOA intermediary a good idea for everyone? Not necessarily. There will always be enterprises that want to do things themselves. But, in an age when anything and everything seems to be subject to outsourcing, there is every reason to believe that there are many enterprises that would welcome the opportunity to outsource the technical and commercial issues related to using SOA capabilities to deploy composite applications that link an enterprise with its business partners.

Who would provide SOA intermediation services?

There are several sources for potential candidates for SOA intermediation services. Certainly the current crop of EDI VAN providers would be likely providers and, in fact, they generally provide many of these services today. Then there are other likely candidates, such as banks, logistics providers like FedEx and UPS, and even telecom providers.

Why telecom providers? The dominant land-line telecom provider in each country or region already has a business relationship with almost all of the large and small businesses in its geographical market. And those telecoms are all desperately looking for business opportunities where they can extend their current franchise and solidify their current business relationships.

Will it happen? Will SOA intermediation services take over B2B SOA connectivity?

Some readers are certainly going to ask, at this point, if these B2B SOA intermediaries are such a good idea, why aren’t they already taking over the world? That would be the wrong question. Every good idea doesn’t necessarily result in someone “taking over the world.” Sometimes, good ideas end up serving as the basis for a nice tidy business for someone who builds an enterprise that can address a particular set of market requirements. SOA intermediation certainly looks like that sort of opportunity.