May 4th, 2007
Open source projects increasingly empower SOA infrastructure definition and development
Read a full transcript of the discussion. Sponsor: IONA Technologies.
Unlike earlier open source initiatives, which often trailed commercial development of crucial software infrastructure, today’s many community-based services oriented architecture (SOA) projects are early-on defining the means through which SOA can be realized.
Development of commercial and open source versions of essential SOA components are happening concurrently. Open source SOA projects are providing a unique opportunity for developers to get their hands dirty and learn a little bit about the field, as well as contribute back some of their ideas in a form that is very healthy for new technologies.
Many commercial vendors are creating large software infrastructure stacks that are designed to target their customers with things that they have supported in the past. But a lot of new technologies and methods are also popping up, from rich Internet applications using AJAX applications, to new ways of using master data services. These then present a new set of challenges, and a new set of connectivity options, that community development is great at evaluating and solving.
To explore why this is true and how open source will shape the future of SOA infrastructure, join Dan Kulp, principal engineer and community lead at IONA Technologies, and Debbie Moynihan, IONA’s director of open source programs, for a sponsored BriefingsDirect podcast discussion, hosted by me. IONA Technologies is taking an active role in several open source SOA initiatives, including the Apache incubation CXF enterprise service bus (ESB) framework project.
Here are some excerpts:
One of the goals of an open-source community is to bring new developers in. And a lot of times those new developers have different priorities or different ideas of what an ESB should do. They can provide a lot of expertise and new and fresh ideas that can make the open-source project a bit different than closed source, and provide some unique features.
One of the most fascinating things about the open-source community is something may not be my number-one requirement. But if it’s one of the other developer’s number-one requirements, they’re more than welcome to work on it and get it done. So in my mind it would have slipped. But in his mind it would have gotten done. It’s a fascinating environment.
For example, originally, when we were doing a lot of the Celtix stuff, we were still ObjectWeb, and Spring wasn’t really one of our priorities. From IONA’s standpoint, it’s not something that we’ve really experienced much with our customers. But as part of the merge with XFire, that user base was a little different than the Celtix user base.
Priorities got shifted, and we started developing more flexible models for deployment that allow the use of Spring, if you’re a Spring person. If you’re not a Spring developer, we have other options that are available to deploy your applications in a very different format that provides a lot of flexibility when you get that broad community throwing ideas out there.
There are definitely a lot of features being added that target a variety of users and use cases that really work into our original definition of what CXF was going to be. If you take a look at that Apache incubation project page, there’s a list of stuff. It was the original design of what this project was going to be. It’s going to have multiple bindings and multiple transports. We do have that, and that’s good. But with our growing list of cool features that developers keep coming up with, we’ve been adding all these multi-deployment capabilities. We’ve been adding a lot of these new WS specs like WS-Addressing and WS-Reliable Messaging.
Some of them weren’t even really anywhere close to final specs when we started the Apache CXF project. It’s a never-ending battle of more ideas coming at us, which is great — there are no complaints about that. But there’s definitely a lot of work to be done and a lot of new ideas. So, it’s a growing project with a growing list of features.
One of the other neat things about Apache is how many top-level projects they have. It’s in the 30s now, and a lot of the top-level projects have subprojects. So, there’s a lot of various functionality and different projects. One of the things that we’re trying to do from Apache’s success standpoint is reach out to some of those other communities, get involved with them, and help them get involved with CXF. Hopefully, we can work together to figure out the gaps that we have. Maybe we can use some of their technology, and they can use some of the CXF stuff.
The CXF runtime provides a lot of flexibility. We have a lot of interceptor points where core developers, who really know what they’re doing, can intercept various points of that message as it’s going through the system to do some partial processing or validation. We have some work in progress to do, like partial message encryption on some of the XML stuff. That’s done via some of these flexibility touch points, where developers can just take a part of the message and say, “Okay, we are going to encrypt this.” So, flexibility is another big word that’s important from a developer’s standpoint.
We’ve been working on some new features that we haven’t had in some of the previous generations of IONA’s SOA tool. Some of the main ones we have are the REST integrations. If you are not familiar with the Web 2.0/REST stuff, AJAX is the popular word that actually uses it. It’s a different style of interaction, where you do “gets” to get your XML data. Then it is a little bit processed on the client side, a little bit processed on the server side. There’s a lot of scripting going on in the marketplace today. There are a lot of JavaScript developers working with AJAX or doing other types of JavaScript, even on the server side. So, a lot of what we’ve done with CXF is to give those file developers some new tools to produce applications.
We’ve created a set of REST annotations. If you have existing Java services that you want to expose via REST capabilities, your AJAX clients can talk to them. You can annotate the code with these REST annotations, and CXF will pick up on them and do the REST or the SOAP interactions. We also provide support for writing your SOA applications in JavaScript. JavaScript is one of those neat interpreted things for rapid development, where you avoid some of that compile-repackage-redeploy cycle.
With the commercial product there are release cycles of six months or a year, or something like that. A lot of commercial vendors try to figure out what’s going into a particular release six months before it’s even released. So if those Web services specs aren’t finalized six months before release, they may not make that release cycle. In an open-source environment, where you have a constantly evolving development, as soon as these things get finalized, it can be made available almost immediately.
For developers that aren’t familiar with these things, it does give an opportunity to learn about them and use them in something that’s relatively easy. Expanding their knowledge is always a good thing from a career perspective. The more you know, the better off you are.
Read a full transcript of the podcast. Sponsor: IONA Technologies.
Listeners or readers of this podcast are invited to learn more about sponsored B2B podcasts.
Dana Gardner is principal analyst of Interarbor Solutions. For disclosures on Dana's industry affiliations, click here or to view his full profile click here.
Subscribe to BriefingsDirect via Email alerts or RSS.
Link to BriefingsDirect podcast. Subscribe to the podcast Feed. Subscribe with iTunes.
