More open source server components and frameworks continue to emerge from developer communities. One of the latest, Apache CXF, an open-source Web services framework, graduated from incubation recently to become a full Apache Foundation project.
The progeny of the previous merger of the ObjectWeb-managed Celtix project and the XFire Project at Codehaus, CXF joins a growing pool of Apache and other open source projects supporting services oriented architect (SOA) infrastructure. Many, like CXF, also enjoy commercial support and associated commercial products, such as IONA Technologies' FUSE.
CXF is on the cusp of broadening beyond conventional Web services, however, as users seek to align the framework with JavaScript, and perhaps more dynamic programming languages, such as Groovy and Ruby. Interoperability is the goal, with both backward and forward messaging compatibility, with an expanding set of technologies supported. Community-based open source development is adept at adding such breadth and depth to the benefit of all users, and CXF is no exception.
To learn more about CXF and the direction for SOA, middleware and open source development, I recently spoke with Dan Kulp, a principal engineer at IONA who has been deeply involved with CXF; Raven Zachary, the open-source research director at The 451 Group, and Benson Margulies, the CTO of Basis Technology.
Here are some excerpts:
If you are doing any type of SOA stuff, you really need some sort of Web-service stack. There are applications written for ServiceMix and JBI that don't do any type of SOAP calls or anything like that, but those are becoming fewer and farther between. Part of what our Web services bring is the ability to go outside of your little container and talk to other services that are available, or even within your company or maybe with a business partner or something like that.Listen to the podcast. Read a full transcript. Sponsor: IONA Technologies.
The whole Apache model is mix and match, when you are talking about not only a licensing scheme. The Apache license, is a little easier for commercial vendors to digest, modify, and add in, compared to the GPL, but also I think it's the inherent nature of the underlying infrastructure technologies.
When you deploy an application, especially using open source, it tends to be several dozen distinct components that are being deployed. This is especially true in Java apps, where you have a lot of components or frameworks that are bundled into an application. So, you would certainly see CXF being deployed alongside of other technologies to make that work. Things like ServiceMix or Camel, as you mentioned, ActiveMQ, Tomcat, certainly Apache Web Server, these sorts of technologies, are the instrument to which these services are exposed.
A lot of these projects, like Camel and ServiceMix, require some sort of Web-services stack, and they've basically come to CXF as a very easy-to-use and very embeddable service stack that they are using to meet their Web-services needs. ... One of CXF's advantages is what you want to do is deliver to some third-party a stack that they put up containing your stuff that interacts with all of their existing stuff in a nice light-weight fashion. CXF is non-intrusive in that regard.
CXF gets a lot of attention because it is a full open-source framework, which is completely committed to standards. It gives easy-to-use, relatively speaking, support for them and, as in many other areas, focuses on what the people in the outside world seem to want to use the kit for -- as opposed to some particular theoretical idea ... about what to use it for.
Apache CXF has is a fairly different approach of making the code-first aspect primary. ... So, a lot of these more junior-level developers can pick up and start working with Web services very quickly and very easily, without having to learn a lot of these more technical details.
It's actually kind of fascinating, and one of the neatest things about working in an open-source project is seeing where it pops up. ... One of the examples of that is Groovy Web service. Groovy is another dynamic language built in Java that allows you to do dynamic things. I'm not a big Groovy user, but they actually had some requirements to be able to use Groovy to talk to some Web services, and they immediately started working with CXF.
They liked what they saw, and they hit a few bugs, which was expected, but they contributed back to CXF community. I kept getting bug reports from people, but was wondering what they were doing. It turns out that Groovy's Web-services stack is now based on CXF. That's type of thing is very fascinating from my standpoint, just to see that that type of stuff developed.
Apache CXF 2.1 was released about a week after we graduated, and it brought forth a whole bunch of new functionality. The JavaScript was one of them. A whole new tooling was another thing, also CORBA binding, and there is a whole bunch of new stuff, some REST-based APIs. So, 2.1 was a major step forward.
Now that they we're graduated, there are a lot more people looking at it, which is good. We're getting a lot more input from users. There are a lot of people submitting other ideas. So, there is a certain track of people just trying to get some bug fixes and getting some support in place for those other people.
I like the fact that in CXF they are looking at a variety of protocols. It's not just one implementation of Web services. There's SOAP, REST, CORBA, other technologies, and then a number of transports, not just HTTP. The fact is that when you talk to enterprises, there's not a one-size-fits-all implementation for Web services. You need to really look at services, exposing them through a variety of technologies.
I like that approach. It really matches the needs of a larger variety of enterprise organizations and just it's a specific technology implementation of Web services. I mean, that's the approach that you're going to see from open-source projects in the space. The ones that provide the greatest diversity of protocols and transports are going to do quite well.
There's a whole bunch of other ideas that we're working on and fleshing out. The code first stuff that I mentioned earlier, we have a bunch of other ideas about how to make code-first even better.
There are certain tool kits that you kind of have to delve down into either configuration or WSDL documents to accomplish what you want. It would be nice if you could just embed some annotations on your code, or something like that, to accomplish some of that stuff. We're going to be moving some of those ideas forward.
There's also a whole bunch of Web-services standards such as WS-I and WS-SecureConversation that we don't support today, but we are going to be working on to make sure that they are supported.
When you look at growth opportunities, back in 2001, JBoss app server was a single-digit market share, compared to the leading technologies at the time, WebSphere from IBM and WebLogic from BEA. In the course of four years, that technology went from single-digit market share to actually being the number one deployed Java app server in the market. I think it doesn't take much time for a technology like CXF to capture the market opportunity.
So, watch this space. I think this technology and other technologies like it, have a very bright future.
No comments:
Post a Comment