Thursday, June 5, 2008

Apache CXF: What the future holds for Web services frameworks and dynamic languages

Listen to the podcast. Read a full transcript. Sponsor: IONA Technologies.

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.

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.
Listen to the podcast. Read a full transcript. Sponsor: IONA Technologies.

Wednesday, June 4, 2008

JustSystems moves dynamic document management deeper into enterprise

Structured authoring -- it's not just for technical documents any more. JustSystems today announced XMetaL for Enterprise Content Management (ECM), which integrates with more than 20 commercial repositories and file systems.

This new offering provides seamless integration to all leading content management systems, including repositories from IBM FileNet, EMC Documentum, OpenText, Interwoven, and Microsoft. [Disclosure: JustSystems is a sponsor of BriefingsDirect podcasts.]

JustSystems has also announced an original equipment manufacturer (OEM) agreement with IBM, under which the company will embed and resell IBM WebSphere Information Integrator Content Edition (IICE) with the new XMetaL product. This is designed to allow companies to broaden XMetaL deployments and to leverage repositories they're currently using to store and manage content.

According to JustSystems, XMetaL for ECM will allow companies to start using structured authoring, no matter which repositories are already in place. Companies will also be able to deploy it across departments without disrupting current content management, as well as integrate and automate content creation and publishing across repositories.

Structured documents can be a valuable ally of service-oriented architecture (SOA) by providing data to workers in the document formats to which they are accustomed, and, at the same time, allowing them to focus on authoritative data and content, while eliminating the drudgery of validating and reconciling documents.

I recently wrote a white paper on the role of structured authoring, dynamic documents, and their connection to SOA. Read the whole paper here.

Back in April, I recorded a podcast with Jake Sorofman, senior vice president of marketing and business development, for JustSystems North America. The sponsored podcast described the tactical benefits of recognizing the dynamic nature of documents, while identifying the strategic value of exposing documents and making them accessible through applications and composite services viaSOA.

In the podcast, Sorofman explained the value of structured authoring in the enterprise:

"There are really a couple of different issues at work here. The first is the complexity of a document makes it very difficult to keep it up to date. It’s drawing from many different sources of record, both structured and unstructured, and the problem is that when one of the data elements changes, the whole document needs to be republished. You simply can’t keep it up-to-date.

"This notion of the dynamic documents ensures that what you’re presenting is always an authoritative reflection of the latest version of the truth within the enterprise. You never run the risk of introducing inaccurate, out of date, or stale information to field base personnel."

You can listen to the podcast here or read a full transcript here.

Tuesday, June 3, 2008

Spike in enterprise 'events' spurs debut of Event Processing Technical Society

The recent growth -- and expected spike -- in business event data in enterprises has led a group of IT industry leaders to form the Event Processing Technical Society (EPTS), designed to encourage adoption and effective use of event processing methods and technology in applications.

Among the founding members are such heavy hitters as IBM, Oracle, TIBCO Software, Inc., Gartner Research, Coral8 Inc., Progress Software, and StreamBase.

Event processing pioneer Dr. David Luckham, a founding member of EPTS, explained in a press release:

“We've had decades of development of event processing technology for simulation systems, networking, and operations management. Now, the explosion in the amount of business event data being generated in modern enterprises demands a new event processing technology foundation for business intelligence and enterprise management applications.”

EPTS has five initial goals:
  • Document usage scenarios where event processing brings business benefit

  • Develop a common event-processing glossary for its members and the community-at-large to use when dealing with event processing

  • Accelerate the development and dissemination of best practices for event processing

  • Encourage academic research to help establish event processing as a research discipline and encourage the funding of applied research

  • Work with existing standards development organizations such as Object Management Group (OMG), OASIS and W3C to assist in developing standards in the areas of: event formats, event processing interoperability, event processing (meta) modeling and (meta) languages.
EPTS, which does not plan to develop standards itself, has already begun work on an initial draft of the proposed glossary. A use-case work group is generating templates around documentation and presentation of the use cases.

Event processing was a hot topic at the recent TIBCO user conference, TUCON. (Disclosure: TIBCO is a sponsor of BriefingsDirect podcasts.)

Fellow ZDNet blogger Joe McKendrick has some thoughts on event processing, too.

The new consortium plans three additional work groups. The first will focus on developing information on event processing architecture. Another will identify requirements for the interoperability among event processing applications and platforms. The third will collaborate with the academic community to develop courses in this area.

The advance in the scale and complexity of streams of events will place a greater burden on infrastructure and architects. But the ability to manage and harvest analysis from these events could be extremely powerful, and provide a lasting differentiator for expert practitioners.

While the processing of such events has its roots in financial companies and transactions, the engine for dealing with such throughputs and variable paths will find uses in many places. The vaulting commerce expected as always-on mobile Web, GPS location and social graph data collide is a prime example.

We hit on these types of transactions as the progeny of online advertising in a recent BriefingsDirect Analyst Insights roundtable podcast.

Consumers and end users should begin to enjoy what they may well perceive as "intelligent" services -- based on the fruits of complex events processing -- from their devices and providers. Harvesting and using more data from sensors and device meshes will also require the scale that event processing requires.

We should also chalk this up to yet another facet of the growing definition of cloud computing, as event processing as a service within a larger set of cloud-based services will also build out in the coming years. The whole trend of event processing bears close monitoring.

EPTS will hold its next meeting Sept, 17-19 in Stamford, Conn. More information on the consortium can be found at the EPTS Web site.