For the past year, we have been working with a company called Covast to connect their B2B Suite product (built on Microsoft BizTalk) to the GXS Trading Grid.  The idea was to build a highly functional connector using a combination of AS2 (for moving files back and forth) and web services (for everything else).  We selected AS2 for file movement because both companies have a lot of AS2 business, and it was popular with customers.  We chose web services because most of what we wanted to do was not addressed by widely used document standards — and we felt that we could also leverage some existing web services already deployed on the Trading Grid.

Our initial concept was to allow a company that had installed Covast’s product (which we also resell…) to do all of their Trading Partner administration (add/update/delete, request relationship, etc) as well as their document tracking, from within the B2B Suite interface.  Our assumption was that they would enter some info about a partner and then query the service for them.  If located, the profile would be sent back to populate the software, and a trading relationship would be requested.  Almost as an afterthought, a service was implemented to pull all the partner data connected (via relationships) to the customer — mostly to provide a tool for synchronizing the software and the service.

Well, I still have hopes for the original model, but that is not what our joint customers are doing!  Read the rest of this entry »

A really good, and brief, argument for why Services and Components are really different, from Radovan Janecek’s Weblog .

It is not too difficult to argue with it, but it has the merit of being “observable”. His core argument is that components are stitched together through code — either at compile or runtime, while services are accessed dynamically over a network. Interesting basis, and much easier to apply than many based solely on granularity.

Interesting article on ZDNet,» Grand Central turning to Swivel | Between the Lines | ZDNet.com, concerning the rise and fall of Grand Central Communications. Although I have already seen many analysis of this — mostly with respect to its implications for Web Services, I like this article because it addresses the business challenges.

It is hard to sell infrastructure, period. When most infrastructure was software, most companies that started as infrastructure software companies wound up peddling applications built on their products. It would always begin as demonstration apps, graduate to POCs, and eventually become the product. The cycle concludes with a port to some other piece of infrastructure software (BEA, webSphere, etc). Thus was the fate of most of the application server vendors.

Part of GCC’s challenge was its belief that it had discovered a new space, rather than a new channel into an existing space. Companies have been sharing information for decades via private networks, the Internet, EDI, RosettaNet, etc. Web Services is a fantastic addition to the toolbox, but it is especially valuable when used in the context of other technologies.

Our core messaging business makes use of several different protocols, the latest of which is AS2. We look to web services not as a way to replace all of this, but as a way to extend what we can offer our customers and partners. For example, we have built web services interfaces for provisioning — allowing software partners to setup partners and relationships, which they can then use for traditional messaging.

The lesson for me is that B2B spending is controlled by innovative conservatives, people who do not hesitate to invest in the new — but only when it works for them now.