coarsegrained: A Rose By Any Other Name

« Pluggable Services in the Web Services Bus | Main | WS-Eventing spec released »

December 16, 2003

A Rose By Any Other Name

I have gotten some good feedback from various quarters on the term "web services bus". This is definitely not the only possible name. We do believe that it conveys both the orientation to pure web services and, with the word "bus", the distinction between the current generation of point to point web services integrations.

But there are other possible names. For example the following names have been proposed by various other web services analysts and pundits:

services infrastructure layer- a very good report from the New Rowley Group. Very close to the web services bus in concept. The characteristics are described as: decentralized, deployed incrementally, built on open standards, and enhanced by a plug-in market: all of which sounds very familiar. Its especially gratifying to see the emphasis on plugins. It does not talk about message delivery capabilities or the move away from point to point style web services integration.
service grids- as described in John Hagel's and John Seely Brown's paper Service Grids: The Missing Layer in Web Services. It is less specific about the role pluggable services can play. It also has an unfortunate overlap with grid computing: a separate topic entirely.
pure web services ESB - I have seen this term proposed as well. It doesn't quite roll of the tongue though. It also doesn't convey all of the differences of what we've been proposing from other ESBs. I think it would be better to pick more of a "greenfield term" that doesn't already have a lot of associations with it (perhaps also an argument against using the word "bus" at all in the term).
fabric, services fabric, web services fabric - I've seen the word fabric now used to describe enough different offerings (from WebMethods/TME, Sonic, even Microsoft) that I'm not sure what it means. The best distinction from bus that I've seen is that a fabric is highly distributable with no centralized nodes required. In essence, it seems to be a description of an architecture for supplying web services-related services, such as failover. Any such infrastructure will need at least a logically centralized registry. However, if there is consensus that this word is better for describing the attributes we have been discussing below, then we should adopt it.

I think the "adjective prefix" can either be "services", "web services", "services integration", or "services infrastructure". I don't have a strong preference except that "web services" may convey the orientation toward open standards.

For the "noun", the options are (at least): layer, grid, fabric, and bus. Bus conveys the move away from point to point, while having some baggage from the old EAI days. Grid has perhaps too much association with grid computing. Layer is perfectly accurate but doesn't really give too many clues as to what the layer does. Fabric may or may not be the term to use depending on what meaning it has evolved to.

So there you have it. Pick one from column A and one from column B: "services integration bus", "web services layer", "services infrastructure grid". I don't have a strong preference either way. I'd love to hear other nominations.

December 16, 2003 in Web Services Infrastructure | Permalink

Comments

I think that there are several different, completely context appropriate styles of services oriented architecture, including point-to-point, hub-and-spoke, service bus, and peer-to-peer, and I think that each term should be fairly clear and used in the context for which it fits.

I think that using the term bus, especially given its legacy with the computer, connotes centralization and should really only apply to such architectures (despite what ESB vendors actually implement and put in their marketing literature.)

I like fabric for the peer-to-peer, fully decentralized service architecture, and I don't think it implies a logically centralized registry, though at deployment, you certainly could approach it that way. I know that Graham Glass chose Fabric for the then-TME/now-webMethods product because he wanted to distinquish his federated, peer-to-peer approach from a more centralized approach. This is the only one that will scale across enterprises, and I think it makes sense in many situations for internal, enterprise service architectures.

Posted by: Jef Newsom | March 05, 2004 at 08:22 AM

Can you explain to me what the difference between "peer to peer" and "point to point" is in your description of various topologies? Also how does the fabric work to provide things like distributed failover (the default Gaia demo) without having a place to store the locations of all services?

- Adam

Posted by: Adam Blum | March 07, 2004 at 09:52 PM

That is a good question/point (sic). Perhaps I should change point-to-point to "direct and hard-coded." This is what I would more traditionally think of as client/server. I think of peer-to-peer as being decentralized and bi-directional compared to what I refered to as "point-to-point."

I don't know that that answers your question, but it has me thinking about what are the orthogonal qualities of the various topologies. I will have to get back to you with that post in hopes that it might be better thought out than my previous one (smile).

As far as your second question goes, I like to think about dns, dhcp, maybe netbios. I think both provide methods of distributed failover that do not require a (do you mean central?) location to store the ip leasing and naming, respectively, services. I think that webMethods discusses their approach at least conceptually in their user doc.

It seems like it is basically a rebind with a rediscovery in the [web] service client, where the discovery protocol is not confined to querying the previously known set of service repositories. I could imagine one [brute force] approach being querying a local, perhaps even in-process, uddi service for locations of other uddi services, and perhaps you get a different one each time, each of which offers a different set of service bindings for a given service interface. Don't know that I would necessarily recommend that approach, and I would sure as, um, heck, worry about performance in such a case, but the point is that you don't necessarily have to have a centralized location for all of the services.

Posted by: Jef Newsom | March 24, 2004 at 11:51 AM

Can anybody explain me the difference between PEER-TO-PEER NETWORK and POINT-TO-POINT NETWORK.
I am very much confused. please e-mail me asap

Posted by: Somesh Kumar | December 21, 2006 at 09:32 PM

Posted by: aol | July 31, 2007 at 02:42 AM

The comments to this entry are closed.

About

September 2005

Sun	Mon	Tue	Wed	Thu	Fri	Sat
				1	2	3
4	5	6	7	8	9	10
11	12	13	14	15	16	17
18	19	20	21	22	23	24
25	26	27	28	29	30

Blogs

Specs

Companies

Good Technology
open architecture for mobile access to enterprise data
My Wireservice
My newsreader.
ZapThink
very insightful writing on unsolved problems in web services
Center for Document Engineering
one of the few places really concentrating on how to do good document design
MindReef
I love the focus on value-added WSDL tools. Very important for schema-first approach to web services creation
Microsoft Advanced Web Services

coarsegrained

thoughts and observations from Adam Blum on web services and XML document-oriented development approaches and tools