At the time of this recording John Crupi ran Sun's Enterprise Web Services Practice and consulted on SOA at a number of large enterprises. John Crupi is also one of the main authors of the book Core J2EE Patterns. In this interview, John shares his insights based on consulting with Fortune 1000 companies about what SOA means to the Enterprise, SOA analysis and design vs. OO, effective service composition, governance, and more.
Watch John Crupi on Enterprise SOA (28 minutes).
Watch John Crupi on Enterprise SOA (28 minutes).
What differentiates service oriented architecture from simply using web services?See also InfoQ's free downloadable book on the same subject: Enterprise SOA Adoption Strategies.
Crupi: I think it's about the architecture in place. SOA does not equal web services, and web services don't equal SOA. We've been trying to do service oriented architecture for a long time, it's about loose coupling, we think asynchronous exchange, it can be synchronous, and it doesn't really matter. We think that web services tend to lend themselves this, because they are based on open standards and it gets into tools, so tools know how to consume from a registry, we get things into standard based registry, we pulll them out, all the work is done. We can have zero deployment and we can literally do that and it's amazing because we can have multiple tools pull this up. I think this is really one of the key elements understanding how web services really leverage. But to put it all together as an over-arching architecture, that's the SOA part. Just because I put a bunch of services there, doesn't mean that I'm creating an architecture around these services. Some services lend themselves to being atomic, maybe Google puts out a service, Amazon where I can go look for a book, do a search and I get it back, but in business where you have to have an architecture and really what puts us all together are the processes that we expose via composite applications is being able to put the exposed services and to be able to orchestrate these services to create a higher value or bigger service in itself. The process layer that we've exposed is itself also a service, but to the user that is consuming it and they don't know that the service is orchestrated with the multiple services, web services underneath. I think it's really a difference of one has really a bigger architecture built around it and one is more of an implementation detail.
