Where are you at with the Eclipse SOA project and where do you think it's headed in 2006? We just had the project...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
approved by the board of directors. I think that will be announced soon after some procedural matters are taken care of. We just had our first project meeting. So we're starting to sketch out the project in respect to what it's going to deliver. Our goal is, over the next year, to deliver the first few releases of a graphical user interface for SOA projects, which will dramatically simplify a developer's task, and a deployer's task, for creating and managing some aspects of SOA. We want to focus this project on the development and the description of services, so this is a service-oriented project, not an object-oriented project. It adds core design to define and describe services that are interrelated and deployable by various runtimes, such as app servers or ESBs. We should see the first phases of that during the coming year.
What benefit does Eclipse bring to SOA? What's the magic of Eclipse going into this area?
Eclipse represents probably the most widely used tool set today for development of applications in the Java world and there's nothing else that comes close. The benefit to customers is really to have an independent, vendor-neutral standard established through open source for the design, development and deployment of service-oriented applications. Our goal is to ensure that this is a vendor-neutral tooling project so that customers can really work with the tools across a variety of runtimes. To really get a benefit out of service-oriented architecture, you want it to be compatible with today's heterogeneous software world and you want the tools to be compatible across a variety of different products at the service layer so that you can really get the value out of SOA that you need. You want to have a common way of interfacing to any existing or new application in a common or interoperable way and, if you have an Eclipse-based tool set, you've got a good, low-cost, sturdy, well-established model for connecting ease-of-use aides to your existing architecture.
You've also been involved with the development of Service Component Architecture (SCA), which currently isn't in a formal standards body. Is there any overlap between that and the Eclipse project? Can it be of any help with the Eclipse project?
Absolutely, SCA is an important component of the Eclipse tools project, especially as you begin to trade, divide and assemble collections of related services. We're definitely using the SCA metadata model for service assembly and from that we're going to figure out how you map that SCA metadata model down to various runtimes.
So the Eclipse group will essentially be the first open working group to implement part of SCA?
Though it's not a housing for SCA specifications, we're deriving aspects of the tools project that are related to the SCA from the SCA specs. You could try to invent this metadata model we need, but there's actually a metadata model that already exists in the SCA specs. So we're taking from the SCA specification and it's being drilled into the tools project, but that doesn't imply that we are advancing the specifications through Eclipse at all. That's going to be a separate and parallel effort, conducted by the author companies and later under the aegis of a standards body.
Just to clarify, this metadata model in SCA, is that the same as or different from Service Data Objects (SDO)?
SDO has its own metadata model related to data services. SDO will have its place in the tools project, as well when data services are required. The SCA metadata model is the one that tells you how to compose services together whereas SDO is, as the name implies, more of a data access and abstraction technology.
What's the hardest thing you're trying to do with the SOA project? What's the thing that if you can do it, you're going to be thrilled?
That's going to be if we can really make it vendor, technology and platform neutral and still highly productive for developers. You're talking about trying to maintain an interesting level of features and functionality across a variety of vendor products and uniting them through a common tool framework and that's going to be a big challenge. We think we have a good start and the right collection of collaborators to make that happen.
For those who aren't familiar with it, what's the difference between the Apache Synapse project and an open source ESB project? And at what level do they connect?
Synapse is pretty strongly focused on Axis 2, which is a second-generation SOAP stack coming out of Apache. It's focused on creating a mediation layer or mediation capabilities, including, in a very basic sense, things like logging or implementation of policies. So there's some overlap with what's going on in other areas, but Synapse is focused more on Axis 2, whereas in the SOA tools project and other places, you'll see more of a runtime agnostic mediation layer that runs across every type of execution engine.
If you had to explain mediation to someone during an elevator ride how would you do it?
The easiest way to explain it is probably to compare it to gateways. Gateways are pretty well known, where you have maybe one transport protocol coming out and the gateway transforms it to another protocol on the other side. For instance, you used to have LU62 gateways all over the place years ago with mainframes, but of course mainframes now have native TCP/IP stacks so you don't really need that type of mediation anymore between the TCP world and the mainframe world. It's that kind of concept where you're trying to take things that don't naturally talk to each other or naturally understand how to work with each other.
How critical do you think mediation is going to be once people start to grasp the concept?
I think it's going to be an important part of any service-oriented architecture network or service-oriented architecture system where you have a collection of endpoints that need to talk to each other. Many times services will be able to talk to each other directly, other times they may need to go through an intermediary, proxy or gateway to translate to different flavors of a security protocol or to translate between different types of communications protocols. So I think over time in SOA deployments we're going to see this concept of an SOA network where you have a collection of endpointed intermediaries you can deploy to solve various problems.