Newcomer: SCA, JAX-WS and Ajax in Eclipse SOA project |
 |
By Rich Seeley, News Writer
28 Aug 2006 | SearchWebServices.com |
|
|
Back in January, SearchWebServices.com talked to Iona Technologies Inc. chief technology officer Eric Newcomer shortly after the first committee meeting for the the Eclipse Foundation SOA Tools Project (STP). As the STP committee prepares to make as progress report at EclipseWorld in Cambridge, MA the first week of September, we asked Newcomer for a preview. In the first of this two-part interview, he discussed how the work has been progressing. In part two, he talks about underlying technologies including the Service Component Architecture (SCA) standard, JAX-WS runtime, other runtimes and where Ajax may eventually fit into the project.
Where does SCA fit into the Eclipse SOA Tools Project?
Eric Newccomer: SCA is part of what we call the Core Subproject in the SOA Tools Project. The Core part of the project is really how you create components out of services. The purpose of SCA is to take the service description such as WSDL and create a component out of it, which includes the information needed to map it into a runtime. So the SCA part of the SOA Tools Project is really about adding to a service the information that is necessary for deploying or mapping it into a runtime.
How does that work?
Newcomer: There's a three-step process in the SOA Tools Project. The first is finding the service for creation. The second is adding the metadata to it, which is called the SCA assembly metadata. That assembly metadata is what is interpreted for the runtimes. The third step is how you map it onto a runtime. SCA is being used as the intermediate, the middle step between description and deployment. It contains the metadata necessary for a runtime to figure out how to deploy the services as a component. There will be multiple runtimes support. The first one we're working on now as kind of a proof of concept is the JAX-WS runtime, which is the latest set of Java APIs for Java Web services support.
How are you working with SCA to make that happen?
Newcomer: Part of what's going on with SCA right now is to understand how to create multiple mappings of the SCA metadata to various runtimes. So the SCA project is pretty well aligned with SOA Tools on the goal: How do I transform a generic or standard Web services definition into something which is a component type that can be deployed in a runtime and deployed in various runtimes? In that case, the SCA project is progressing along similar lines to the SOA Tools Project needs, which is how do I get this SCA assembly metadata to be compatible with various runtimes out there that people want to use for SOA deployment.
Is SCA, which isn't yet in a standards body, mature enough for this kind of implementation?
Newcomer: The assembly specification in SCA is really the key spec. Certainly there's still some change occurring there, but the main feature of the assembly metadata is the component type definition and we feel that's reasonably stable – stable enough to start the work within the SOA Tool Project.
for runtimes, why did you select JAX-WS?
Newcomer: Part of it had to do with the fact that we had the code that we could contribute to that from Iona. It matched up well with the initial code contributions from Sybase and IBM. Just as a practical matter to give the first test to the integration of the subprojects we were able to supply the JAX-WS code for that. It may have been just a matter of practicality being able to work with the code we have available within the project, but I think it's also correct that JAX-WS is becoming widely adopted in the Java community as an SOA runtime. There's really the two goals. Take something we could have as a practical measure to check the concepts and check the integration of the various subprojects. At the same time provide a proof of concept using a widely-adopted SOA runtime.
After this proof of concept with JAX-WS what other runtimes do you plan to support?
Newcomer: We expect to see mappings for Spring, EJB 3 and various ESB runtimes. This will depend somewhat on the contributions from the vendors. At the moment we're working primarily with code from the three initial founders of the project – IONA, IBM and Sybase. As the project goes on we would expect contributions from other folks to widen the scope of the supported runtimes.
Are you doing anything to integrate Ajax functionality into this tools project?
Newcomer:
Ajax is more on the client side. What we're doing in the SOA Tools Project is really much more around the deployment of a service rather than access to the service by a client. Of course, that part is important and we'll be looking at that later. But the focus of the SOA Tool Project is if I'm going to have an SOA project how do I go about – once I've done my design for my services that meets the needs of my business – how to I go about creating those services, assembling them together where we need multiple services to work together in combination and how do I go about deploying those to a variety of runtimes? We're really focused on once you've done your design for your SOA, how do you get your service created, how do you get it assembled into components with other services and how do you get that deployed into a runtime. Of course, Ajax is important for accessing the services, but I think where the SOA Tools Project is focused is much more around creation, assembly and deployment. Of course, we'll be looking at the (Eclipse) Ajax project along with some portal projects with respect to how they can access those services.
|
|
|
|
