BT

InfoQ Interview: John Crupi on Enterprise SOA

by Floyd Marinescu on Oct 12, 2006 |
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).
What differentiates service oriented architecture from simply using web services?
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.
See also InfoQ's free downloadable book on the same subject: Enterprise SOA Adoption Strategies.

Hello stranger!

You need to Register an InfoQ account or to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread
Community comments

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Discuss

Educational Content

General Feedback
Bugs
Advertising
Editorial
InfoQ.com and all content copyright © 2006-2013 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT