Never confuse a service-oriented architecture with a Web service, says Graham Glass, author of "Web Services: Building...
Blocks for Distributed Systems." A company can have one without the other, but together they make a great team, he says. Glass, chief architect of Addison, Texas-based software infrastructure vendor Mind Electric Inc., is one of the speakers at this week's XML Web Services One conference in Boston. In an interview with SearchWebServices.com, he discussed how SOAs fit into his concept of a "Web services fabric."
Is it incorrect to lump Web services and service-oriented architecture (SOA) together as a single technology?
Graham Glass: Yes, this is incorrect. You can create an SOA without Web services, or create a non-SOA system using Web services. However, SOA and Web services are a perfect match, and we think that modern SOAs should be built out of Web services.
Is a service a 'component' -- or an 'object' with a coarse-grained, business-level interface?
Glass: Not necessarily. In some circumstances, it might make better sense for a service to have a fine-grained interface. However, most of the time it is appropriate for a service to have a course-grained API.
Can you give some general guidelines about what can and cannot be effectively turned into a service?
Glass: Pretty much any piece of software can be exposed as a collection of services. The tricky part is figuring out how to group the functionality appropriately and how course-grained to make each operation.
Your company preaches that there's wealth to be mined by turning legacy systems into services. What does that entail?
Glass: Most legacy systems have associated products that can expose the legacy software very quickly as Web services. For example, there are products that expose CICS [Customer Information Control System] transactions as services, EJBs [Enterprise Java Beans], SAP end points, Oracle databases, etc. Such tools also often include graphical tools to simplify the mapping of the legacy data structures onto XML.
I notice in your weblog that you coined the term 'Web services fabric.' You also mentioned that you heard it used at the recent [Burton Group] Catalyst conference. What's your definition of the term? How are others using it?
Glass: I wanted to create a simple phrase that describes infrastructure for assembling systems out of Web services -- as opposed to the services themselves. This includes functionality such as publishing, discovering, monitoring, routing, failover, security and orchestration. I also wanted the phrase to connote something highly decentralized.
I eliminated the term 'grid' -- although I've always liked this term and have used it in a couple of my books -- because it has become closely associated with CPU sharing and creating supercomputers out of commodity servers.
I noticed that in the older days of DCE [Distributed Computing Environment], they would often use the term 'substrate' or 'fabric' in a more general manner to connote a ubiquitous infrastructure into which services -- in those days, CORBA [Common Object Request Broker Architecture] -- are embedded. Then I added the term 'Web services' at the front to make the phrase 'Web services fabric.' I floated this phrase about a year ago and it seems to be becoming quite popular. Our new product, Glue Fabric, is a state-of-the-art implementation of these ideas.
FOR MORE INFORMATION:
Expert advice: Creating a private UDDI to find and invoke a service
Web Services Decisions: Service-oriented integration -- The killer app for Web services?