Data integration and Web services

Computerworld - The following interview with John Radko, chief architect at GE Global Exchange Services Inc. in Gaithersburg, Md., was conducted via e-mail. GXS did its first Web services implementation for fuel distribution companies late last year (story).

Q. What do you see as the potential for Web services in data integration? Are there particular types of integration that Web services lend themselves to better?
A. Web services have great potential in integration, but probably not yet in the most critical integration scenarios (i.e. real-time inventory, automated replenishment, etc.). An exception to this generalization is the simple request/response (one time, no transaction and no lingering problems from a failed request), like a credit card authorization.
Why? Currently the Web services specifications and implementations are very strong at making request/response style requests, but there is no facility for either transactions or guaranteed delivery. While it is possible to implement this in a custom manner, it is less attractive because you are not realizing the promise of substantially less effort to integrate systems. I have two caveats, however: One is that in some cases, this will be the easiest way to integrate distributed, different technologies (.Net and J2EE in a B2B scenario, where a common middleware product is unlikely), and the second is that some very smart people are generating standards to address these areas.
Having said that, there are three types of integrations we are pursuing right now:

1. Simple request/response actions, where there are no consequences for transactions failure (other than not having the desired information) like order status, or on-hand inventory. Frequently, answers to these questions influence the decision to move forward with a larger process (procurement, inventory allocation), which is done with other integration technologies.
   Web services makes these requests more economical.


2. 2. Activities where interoperability is the key value. We are building a SOAP [Simple Object Access Protocol] interface to our Network-Based Translation [NBT] service, for instance.
   A major value proposition is that it is very easy for a customer to submit a file to NBT, which is then transformed and routed (you might submit an XML document that is transformed into an [electronic data interchange] purchase order and dropped to a major manufacturer; or you may submit a comma-delimited file that is converted to XML and routed to a chip maker). Since the point of the service is maximum flexibility for the customer, Web services is a good fit.


3. 3. Nontransactional, nonprocess application integration. Many companies like to build performance dashboards that are fed with metrics from applications and services. These dashboards are often implemented in technologies that make such visual presentations easy (like Visual Basic or Java Server Pages). Most of the systems that produce the data are implemented in other technologies, so Web services can bridge the gap.