Transcript of BriefingsDirect Podcast on SOA and Open Source Community Development

Edited transcript of BriefingsDirect[TM/SM] podcast with host Dana Gardner, recorded March 27, 2007. Podcast sponsor: IONA Technologies.

Listen to the podcast here.

Dana Gardner: Hello, this is Dana Gardner, principal analyst at Interarbor Solutions and you are listening to a sponsored BriefingsDirect podcast. Today, a discussion about Services Oriented Architecture (SOA) and open-source software -- how incubation projects and the development of community-based code are a big part of the ongoing maturation of SOA. We’re specifically going to be discussing the incubation Apache CXF project. And here to help us profile and understand this project, its goals and its implications are two representatives from IONA Technologies.

First, we have Dan Kulp. Dan is a principal engineer at IONA Technologies, and he’s been concentrating on Java and Web services technologies. He is also a community lead for IONA’s open-source initiatives, and is furthermore a committer on the Maven Project for plug-ins, Apache Tuscany and Apache Yoko projects.

Also joining us is Debbie Moynihan, the director of open source programs at IONA. I want to welcome both Dan and Debbie.

Debbie Moynihan: Thank you, Dana.

Dan Kulp: Thank you.

Gardner: As we mentioned, there’s an interesting -- and perhaps unprecedented -- intersection between the maturation of SOA as a concept, a philosophy and an approach to computing, and also the role of open source in community-based development. Many times in the past, we’ve seen the commercial development of products that are spun off into open-source projects of a similar nature. But with SOA it seems that things are different. We’ve got a fairly wide variety of projects happening simultaneously as many of the commercial vendors are also putting together products, approaches, frameworks, standards and specifications to help companies develop and manage SOA.

So tell us a little bit about the playing field for open source and SOA, and particularly CXF, which is an ESB project. First let me go to Dan. We’ve seen a variety of different products out there. Why do you think it is that SOA is different from the past, and why do we have so many open source projects simultaneous with commercial products?

Kulp: The open source 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 like SOA. With SOA being very new, there are a lot of ideas flying around, and people are coming up with new ideas and technologies just about every day. The open-source communities that are popping up are very good places to foster those ideas and solidify them into something that’s maybe not just usable by that particular developer’s applications, but also across a wide variety of customer- and user-driven problems.

Gardner: We’re also seeing a combination of best-of-breed, more discreet components standing on their own for SOA activities, as well as more of an integrated stack or suite approach by many vendors. At the same time, we’re seeing open source and commercial. So, there’s a real mixture, a hodgepodge of code, component and infrastructure for those that are evaluating and working toward SOA. Why is that? Is it that SOA is, by definition, more of a componentized undertaking? I’ll throw this out to either Debbie or Dan.

Kulp: It definitely is. If you look at the goals of SOA, you may have some older legacy systems that you want to expose into your SOA, so that newer applications or newer development efforts can talk to those, but you also have all this new stuff that’s popping up. You have all these brand new AJAX applications and other applications that basically present a whole new set of challenges, a whole new set of connectivity options -- just a lot of technologies to connect all these things.

That’s why you see a bunch of these stacks producing different types of connectivity options. Obviously, a lot of commercial vendors are creating large stacks that are designed to target their customers with things that they have supported in the past, and obviously they have to bring their customers up to the newer technologies. When you look toward the open-source stuff, it’s more about connecting newer systems and newer technologies that are really hot and sexy today.

Gardner: So, a little bit of the old and the new -- the more the merrier.

Kulp: Exactly.

Gardner: I suppose that the good news is that it’s "the more the merrier," and there are lots of options, but I think for some people who are traditional IT folks that that many options and that much choice can be daunting and confusing. How do we look at the current landscape of best-of-breed and suites of open-source and commercial and make some sense of that?

Moynihan: Well, one of the things we're trying to do at IONA is help users with the best-of-breed SOA infrastructure technologies that are out there in open source, and to integrate those together in a certified and tested package. This makes it easier for them to leverage multiple projects together. Because there are quite a few best-of-breed approaches and there are a lot of different options. The other thing is that certain communities seem to attract SOA types of technologies, and we participate in each of those -- Apache, Eclipse Foundation, ObjectWeb, to name three of them -- and that’s a good place for people to start. I think with SOA also there are a lot of loosely coupled components, and that actually lends itself well to best-of-breed, and it allows multiple vendors to participate, with each providing what they're really good at.

Gardner: Maybe we should point out here that CXF has a certain legacy and heritage that is close to IONA. Why don’t we briefly give an overview, Debbie maybe from you, on the lineage and history of CXF?

Moynihan: Sure, about a year and a half ago IONA made a proactive decision to initiate the creation of an open-source project called Celtix in the ObjectWeb community to focus on building an open-source ESB. We got that to the first milestone and got a really good foundation. It was following along the same architectural path as IONA’s other offerings, a lightweight, standards-based approach, allowing you to lay on top of any technology that you already have in place, rather than taking a stack type of approach. At one point we wanted to grow the community. We had a lot of interest from other projects in the Apache community. And there was another project called XFire, with which we had a lot of synergies and shared goals.

That led to some discussions, and we eventually made the decision to merge XFire with Celtix and moved them over to the Apache community. We thought it made sense to start a new community with the merged project, and that evolved into CXF. Dan can go into a lot more detail about where we are with the CXF project, but we’ve taken what we had with Celtix and XFire and brought the best of both of those together. And we continue to make a lot of progress there.

Gardner: One thing I want to understand is why open source is a strong approach for the development of certain products, in this case SOA-type products. As I said, I looked at the incubator page for CXF and I see the goals are, "support for standards," "multiple transports," "bindings," "data bindings," "formats," "flexible deployment," and "support for multiple programming languages."

It seems as if, by nature, an open-source approach to SOA has advantages. A commercial vendor and private-code vendor might have some of these goals as well, but they are also going to be mindful of their heritage and their legacy. Is there, from an open-source community level, an advantage to developing an ESB, for example, in a more inclusive way -- to create an ecology, to create a community, where people will contribute? And let me throw that out to Dan.

Kulp: Oh, definitely. There’s a lot of functionality that ends up in a lot of open-source projects that really wasn’t a priority -- or even sometimes a consideration -- when those projects where originally created by the various vendors that push to get these projects started. One of the things about closed-source projects is anything that’s really developed is specific to that vendor’s customers. If their customers have various requirements, that’s what gets developed. They're trying to get new customers. That’s always a goal. But if one of their customer says, “Hey, I need this now,” a lot of other things don’t get developed.

Whereas 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.

Gardner: I suppose one of the tricky parts about any private source or closed source or commercial development and requirements phases is where we draw the line. We’ve got a deadline to meet, there are only certain things we can do within that timeframe, and those are going to be dependent upon our business goals. That’s fine -- there's nothing wrong with that. But it’s a different beast when you’re developing your requirements within an open-source ecology of contributors.

Kulp: Definitely. 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.

Gardner: I suppose it’s also a two-way street. If there’s an ecology that contributors can bring into these definitions and capabilities, they can have many more integration points, many more approaches of how this relates to different implementations in the field. That’s one direction. The other direction is that developers can say, "Listen, we want to be able to work with what this project produces -- and we happen to be of a certain flavor of development" ... like, "I am a Spring developer" or "I am a J2EE developer."

Tell us a little bit about why this makes sense for developers. They can set this project up so that they can better take advantage of what it does, right?

Kulp: Right. You bring up a good example with the Spring stuff that you just mentioned. Originally, when we were doing a lot of the Celtix stuff, we were still in 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.

Gardner: I suppose that many times, from a commercial perspective, you’ll get the vendor saying, "Here are the tools we’re going to use."

Kulp: Exactly.

Gardner: Let’s dig a little more deeply into Apache CXF. Explain what it encompasses. I referred to it earlier as an ESB, but it seems that with this expanding definition set that it might be larger than that.

Kulp: 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.

Gardner: So we’re getting one of those good-news, bad-news things, right? The good news is that we’ve got a lot of people interested, and they want lots of different things. The bad news is that we've got to try to address all those different things.

Kulp: Right, but being open source if we don’t have time to do something and they want to devote some resources to it we definitely welcome that.

Gardner: Who are the primary contributors and innovators within the CXF project? Obviously, we have IONA involved, but are there any others that you can share with us?

Moynihan: We also have Envoi Solutions participating. We have individuals from various Apache projects, like Geronimo, who are also contributing, because they would like to integrate their projects with CXF. At Apache it’s really more the individual versus a particular corporation.

Gardner: There seems to be quite a bit of other ancillary development in terms of Yoko, Tuscany, and ServiceMix that bring a whole other family of contributors into it. Right?

Kulp: Definitely. 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.

That’s one of the fascinating things about Apache. There’s a lot of neat stuff there.

Gardner: Going back to that earlier point about so many choices in the marketplace today, if I am a chief technology officer or enterprise architect and I am moving toward SOA, I am going to be evaluating projects and products and looking at best-of-breed versus suite and so forth. I would want to know the flavor of CXF as an ESB? How does it fit and compare to others? What characterizes this as an ESB? Is this a high-performance or is it a low-latency? What is it designed for?

Kulp: CXF is really designed for high performance, kind of like a request-response style of interaction for one way, asynchronous messaging, and things like that. But it’s really designed for taking data in from a variety of transports and message formats, such as SOAP or just raw XML. If you bring in the Apache Yoko project, we have CORBA objects coming in off the wire. It basically processes them through the system as quickly as possible with very little memory and processing overhead. We can get it to the final destination of where that data is supposed to be, whether it’s off to another service or a user-developed code, whether it’s in JavaScript or JAX-WS/JAXB code.

That’s the goal of what the CXF runtime is -- just get that data into the form that the service needs, no matter where it came from and what format it came from in, and do that as quickly as possible.

Gardner: So, breadth, versatility, high performance -- are these adjectives that we would use here?

Kulp: Oh, definitely, yes.

Gardner: What are some others?

Kulp: Flexibility. 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.

Gardner: So, we have this rich canvas, and we’ve got lots of different oils and paint that we can apply to it and come up with our own unique painting, if you will, for various use-case scenarios. I'm curious as to what vertical, either industries or use-case scenarios, you think that this level of flexibility and versatility is best designed for? Is this something that an ISV will gravitate to? Is this what a software-as-a-service (SaaS) organization should be looking at? If I'm a business applications systems integrator and I'm looking to pull these together in an SOA, what’s the best fit for this as it is evolving in the current incubation process?

Moynihan: Well, we've definitely seen interest from a few different types of developers and other vertical industries. IONA traditionally has had a lot of customers in telecommunications, financial services, and manufacturing. From our engineers' perspective, they bring a lot of those requirements to the project, but we have also seen interest from a lot of different industries. So I wouldn’t say it's specific to a particular industry. From a developer perspective, what’s nice about the technology is that it's really flexible, as Dan said, in that there are multiple programming models that it can apply to. Also, from a deployment perspective, if you are a developer who is implementing it, you can deploy it in a lot of different types of technology.

Whether you like Spring or you are really focused on application servers and have a deep knowledge of JBoss, you can leverage CXF within any of those types of environments. I do think there is a huge opportunity for ISVs to look at this as something that they could include within their products. That’s something that we have seen with Celtix. So definitely that will be interesting. I hope that we see a lot of people joining and providing feedback on the types of requirements we need to continue to develop for that market as well.

Gardner: I suppose the CXF project has the performance characteristics and flexibility that can be taken in a number of directions, and it’s up to the market where they want to take it.

Kulp: Exactly. Obviously the developers who are contributing have a large say in that. But, if a user is going to get more involved, we definitely encourage them to start looking at our mailing list and our Website and start providing extra suggestions of where they think we are deficient or lacking something that they need, and we’ll address it.

Gardner: I suppose that’s another benefit of open source -- you don’t have a big SKU drop to develop to. It’s an ongoing journey, right?

Kulp: Exactly. It’s not big leaps like you have in your commercial versions. They come out every six months with big leaps with them. With open source, if somebody wants to commit something today, they’re obviously able to download the source, build it themselves, and they would have a solution for themselves today. They wouldn’t have to wait two or three months for the commercial vendors to spin the whole release and do all of the stuff that's required for release.

Gardner: For those folks who now have their appetite whetted a little bit and want to learn some more as to why this might be applicable for their needs, can we get into a little bit about what’s technically going on in terms of inclusiveness and adaptation to what’s new and interesting in the market these days? There has been a lot of interest around rich Internet applications (RIAs) and Web 2.0-types of interfaces and applications. Dan, tell us a little bit about what’s going on in that direction.

Kulp: 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.

Gardner: It may be the most popular language in the history of development, right?

Kulp: The way the Web is today, maybe, yes. A lot of people out there are familiar with JavaScript. Having that capability built into the product opens up the project to a whole new breed of developers because we are not restricting it, saying, “Okay, you must know Java JDK 1.5 with JAX-WS."

We do support that too -- we’re not discounting that, but we’re not restricting you to that level of development. With the JavaScript capability, it’s a whole new breed of developers that this opens up to. We have some plans in place for adding things like Jython, and JRuby, and other scripting to broaden that and get more of those people in to open up the opportunities for a wider range of developers.

Gardner: How about specifications and standards? Has there been some more adaptation to what’s being asked for? I guess I’m thinking of some of the WS-* types of specs.

Kulp: Definitely. When we first started the Celtix project at ObjectWeb, JAX-WS itself and the Java API for XML Web Services, the JAX-WS 2.0 spec, wasn’t even finalized. Since then it’s been finalized, and there’s another revision coming up shortly that’s in final draft. Then there are a lot of new Web services specs such as WS-Reliable Messaging, WS-Security, WS-Policy. A lot of new specifications have come out in the last year and a half that provide a standard way of doing a lot of the things that we are trying to do in CXF.

CXF is trying to use those standards whenever possible. Right now in Apache CXF we do support JAX-WS and are working on trying to get it to pass the [compliance test]. It doesn’t right now, but it’s definitely a priority. We are supporting WS-Reliable Messaging, WS-Addressing and WS-Policy. We have started some discussions around WS-Context and WS-Transactions. So, there are a lot of Web service specifications that we are keeping our eyes on and following. As they evolve and finalize, we’re basically trying to get them into CXF.

Now, that said, a lot of those specifications that I just mentioned may or may not be finalized. All this Web service stuff evolves on a day-to-day basis, and it’s actually a lot of work to keep track of those. But from a user standpoint the fact that the project’s doing that, instead of the user doing it, is probably a good thing.

Gardner: Is it fair to predict that these things, when they are ready, would find themselves in CXF before they’d find themselves in commercial ESBs?

Kulp: Potentially, yes. 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.

Gardner: I suppose Eclipse is the most popular "belle at the ball" these days, as well as the SOA Tools project that’s going on there. What would be the relationship between what’s going with SOA Tools and Eclipse and the CXF incubation in Apache? How about to you, Debbie?

Moynihan: The SOA Tools project is geared to provide a broad spectrum of tooling based on the Eclipse platform. It provides a lot of different capabilities for building out SOA services and other types of infrastructure as well. Within that project there is a component that consists of tools that work with CXF specifically. Right now we have JAX-WS tooling, and we’ll continue to expand the tooling part of the SOA Tools project to work with the different capabilities that were built out in CXF.

What’s nice about the SOA Tools project is that it has a lot of other capabilities that are integrated -- like orchestration for BPEL, process modeling using the BPMN standard, and things like building up Service Component Architecture (SCA) tooling and other complementary capabilities; as you have talked about earlier, bringing together the best-of-breed.

Gardner: I suppose another thing we need to look at is the relationship between CXF and the IONA commercial products. I'm thinking of Artix and some of your other offerings. For those people listening who are trying to understand that, can you lay out the land in terms of the relationship between these two? What are your business goals by having such a large active role in the CXF project?

Moynihan: We would like to offer what our customers are looking for, and our customers are looking to elaborate the latest standards in open source. They also have some other needs, which are not being developed in open source. So we have a dual-strategy where we are doing open-source development and then also company-developed or commercial development. We look at both the open-source development and the commercial-development. It’s very complementary from an R&D perspective, in that we’d like to leverage the CXF technology within our commercial offerings.

Also we’d like for all of the Artix plug-ins to work with the open-source technology and to interoperate with the Artix runtime. From a development perspective, we may choose over time to move some of those capabilities into open source. We develop everything so that it can be moved into open source, if and when we decide that it makes sense.

Kulp: This comes back a lot to the flexible nature of the Apache CXF project. One of the design goals of Apache CXF, as I mentioned earlier, was to provide a lot of touch points for plugging in new functionality or to extend the system to customize a little bit. Part of what IONA is doing is using some of those touch points to provide more unique solutions for IONA-specific problems or problems that the IONA customers have been dealing with. The flexibility of Apache CXF provides a lot of capabilities to do that.

Gardner: Okay, who should be interested in CXF in terms of a deploying organization? We talked a little bit about the use-case scenarios. How do you get started, and whom would the people be to do that -- I guess a champion or a maven? Who is the decision-maker that this needs to be appealing to? And then how would those people start taking advantage of what CXF is offering?

Moynihan: What’s nice about CXF is it's small, flexible, and can be consumed in a lot of different ways. Individual developers can actually be the champions, and you see it accepted in their projects. So one group of key users would be corporate developers, people who are working within businesses and building applications and want to service-enable those. On the other end of the platform are people who want to receive and connect with those services.

If you have an application, you want to connect with these new services that are being created and that consume services. Also there are a lot of system integration firms out there who do this type of work.

Those will be the big ones. Then over time you may see more adoption of a particular standard across the organization as people learn about the flexibility and high-performance of the CXF project.

Gardner: To you, Dan ... I suppose if you are downloading an open-source component as a developer, you might be used to things a little less daunting or substantial as an ESB. Or am I reading this wrong? Perhaps there is a perception out there that needs to be adjusted, that it’s okay for me as an individual developer to download an ESB? Do you expect that to be the case? Or is this more of a larger architectural undertaking?

Kulp: It’s definitely good to be able to have a developer download it and get their hands wet immediately. Apache CXF does provide a lot of getting-started-type samples that walk you through the first steps of getting up and running as quickly as possible.

We try to provide a lot of capabilities for developers to get started very quickly with something that's simple, but at least get them started, and then from there to grow their capabilities slowly, and get them more into the advanced features. But you have to start small, and we’re trying to provide samples that will help you do that.

Gardner: That might be something that’s in the best interest of developers for their career. We're certainly seeing a lot of interest in SOA. One of the big question marks in looking at the landscape for SOA is whether there’ll be sufficient manpower or human resources for moving into the role of a SOA architect. One of the best trajectories toward that is from the developer perspective. They might have to learn a lot about a specific business, a domain, and the ins-and-outs of what’s going on in that business. But I would imagine that there are some significant career opportunities for folks who were able to take the developer role, embrace understanding of such products as CXF, and then take that into a business. Do you have any feedback on that in terms of the human resources potential?

Kulp: As in almost all cases, the more you learn, the more potential you have. So, if you can dig into various products and learn more capabilities -- with CXF supporting a bunch of the new Web services standards -- it does give you the opportunity to start using JAX-WS, WS-Addressing, WS-Reliable Messaging, and REST -- all these neat buzz words that you hear on a day-to-day basis.

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.

Gardner: It's hard to argue with that. Well, we’ve had a good discussion on the Apache Incubator CXF project, an open-source ESB. We have been talking with two representatives from IONA technologies, Dan Kulp, principal engineer, and Debbie Moynihan, director of open-source programs.

You've been listening to a BriefingsDirect sponsored podcast. I'm your moderator and host, Dana Gardner, principal analyst at Interarbor Solutions. Thanks for listening.

Listen to the podcast here.

Podcast sponsor: IONA Technologies.

Transcript of Dana Gardner’s BriefingsDirect podcast on SOA and open source community development. Copyright Interarbor Solutions, LLC, 2005-2007. All rights reserved.