Despite all the attention given to Web services applications that will make life easier for general consumers, business-to-business applications have always been at the forefront of Web services development. After all, the difference between a Web service and two applications exchanging data over EDI is largely semantic.
However, while there are some B2B Web services success stories, there are many more unhappy endings (or at least stalled efforts). These failures are often the result of overestimating XMLs capabilities and thinking too big.
Many attempts have been made by industry consortia to create overarching standardized languages or schemata. On the surface, this seems like a good idea, providing a way for companies to communicate instantly over a standardized schema. However, even with very specific industry segments, no two companies communicate data in exactly the same way. The problem gets worse when you consider that most companies also constantly deal with businesses outside their industry segment.
One thing that XML and related Web services standards are really good at is handling many unique data relationships. This has made it possible for XML and Web services to radically change how B2B transactions are conducted. While previous electronic data interchange-based B2B systems were essentially advanced document management systems, XML and Web services have made it possible to build B2B infrastructures that are truly integrated, removing lots of midlevel steps that either needed to be performed manually or required heavy API-based integration.
XML and Web services ease B2B communication and transactions by removing the need for heavy proprietary coding, but they also make B2B more complex by greatly expanding integration options to companies.
So what companies really need are tools that will make it easy to build and manage the many different custom data relationships a business has with its partners.
In its simplest form, the business problem is this: A company has multiple partners with which it regularly transmits and receives a number of standardized data documents, such as purchase orders and receipts. Although the documents are similar, they are not identical, which is what is needed to effect true B2B integration.
The basic task at hand is to take partners documents, convert them to work with your business systems, and then take your own documents and convert them to work with your partners systems when they leave yours.
This sort of integration requires many steps. First, a mapping tool of some kind is required to take the partner documents and map their data points to the related data in your companys business systems. Once this conversion document (most likely an Extensible Stylesheet Language Transformations file) is completed, it is mapped to the partners business processes. Then, some form of workflow system is required to properly flow the partners documents and data into and out of the proper company business systems.
In addition, the data needs to be transmitted in a standard messaging format, which could be SOAP (Simple Object Access Protocol) or messaging systems such as those provided by IBM and Microsoft Corp. And, of course, all this needs to be centrally managed, with good security, analysis and reporting capabilities.