Edited transcript of BriefingsDirect[tm/sm] podcast with Dana Gardner, recorded July 27, 2007.
Listen to the podcast here. Podcast sponsor: IONA Technologies.
Dana Gardner: Hi, this is Dana Gardner, principal analyst at Interarbor Solutions, and you’re listening to BriefingsDirect. Today, a sponsored podcast discussion on a top level Apache Software Foundation project, known as Apache Camel.
It’s a way to help developers do better integration and mediation for routing in software-intense environments, and moving lots of objects and component services around, but also relying on rules and patterns to do so.
To help us understand more about Apache Camel, we’re joined today by James Strachan, technical director of engineering at IONA Technologies. Welcome, James.
James Strachan: Hi.
Gardner: Tell us a little bit about Apache Camel. It seems to be a subset of many other integration and infrastructure projects in the open-source community. Tell us a little bit about the history of how Apache Camel came to be.
Strachan: Earlier this year, Apache Camel grew organically from code and ideas from a bunch of other Apache projects, particularly Apache ActiveMQ and Apache ServiceMix. We found that people wanted to create and use patterns from the "Enterprise Integration Patterns" book in many different scenarios.
Some people wanted to use these patterns inside an Enterprise Service Bus (ESB), some people wanted to use these patterns inside a message broker, and other people wanted to use these patterns inside an application itself or to talk between messaging providers. Still other people wanted to use them inside a Web services framework or some other communication platform. So, rather than tie this routing code to a particular message broker or ESB, we tried to extract this code to be a standalone framework that can be used in any project.
Gardner: I assume that this is to simplify it and make it easier for developers? Is that right?
Strachan: Definitely. What we tried to do with Camel was give it the smallest footprint possible, so that it can be reused anywhere, whether in a servlet, in the Web services stack, inside a full ESB, or a messaging application.
Gardner: And, this is a plain old Java object (POJO), I believe, also built in Java. Is that correct?
Strachan: Absolutely.
Gardner: Tell us a bit about the team behind this and perhaps a little background for yourself?
Strachan: I'm an Apache committer. I’ve been in Apache for over five years now, and I am an Apache member for a few years too. I can’t remember how many. The Camel team is comprised mostly of people from the ActiveMQ team and also from ServiceMix and Apache CXF communities. Plus, a bunch of other people have joined since then.
Gardner: Tell us a little bit about your relationship with Apache. You’re involved with a number of activities there. Is that right?
Strachan: I've been around Apache for many years now, and I am involved in all kinds of different projects -- ActiveMQ, ServiceMix are the big ones -- but also on a bunch of others, like Jakarta Commons, Maven, and many others.
Gardner: There are a number of terms we’ve been bandying around. Let’s assume that not everyone listening is that deeply into technology. When we talk about mediation and patterns, let’s flesh some of these out. Mediation and routing, how is that different from what people might understand generally under enterprise integration?
Strachan: I definitely recommend people read Gregor Hohpe's book "Enterprise Integration Patterns." He offers a really good patterns catalog of how people should do mediation and integration. Rather like the original Gang of Four "Design Patterns" book, which describes low-level programming things, Gregor’s book describes very well how enterprise integration patterns (EIPs) can work and gives us a language for describing them.
Aggregate, re-sequencer, message filter, and message translator generally describe patterns people commonly want to do within an integration solution. One of the simplest patterns is "content-based router," where you want to route messages around your network, based on the content. It might be, for example, that for gold-level customers you want to use the big, shiny, fast machines in your data center, but for bronze-level customers you use the crappy, old, worn Linux box in the corner of the basement.
Gardner: You mentioned earlier ESB, enterprise service bus. Explain to me how this works in terms of other ESBs. This is ESB-agnostic. Is it something that people will use to complement ESBs or perhaps replace them in some instances? What’s the relationship between Camel and an ESB?
Strachan: That’s a good question. In some ways the term "ESB" is a little bit like the terms "object" and "component," in that ESB is used for many different things. It has kind of lost a lot of its meaning. We typically don’t tend to think of Camel as being an ESB. We think of it as a rules-based routing and mediation framework that you may deploy inside an ESB.
We work very closely with the ServiceMix community at Apache which has created a complete Java Business Integration (JBI)-compliant container of JBI components. Camel can be deployed within the ServiceMix ESB among JBI components, but some people don’t use JBI and they may just use Java Message Service (JMS) or they may just use Web services or they may just be JAX-WS clients or whatever. So, we try to make Camel agnostic to technologies. You can use it within patterns like Spring, or JBI or OSGi, or you can use it within any application.
Gardner: I’ve also heard you refer to this as a domain-specific language project. What do you mean by that?
Strachan: Programming languages are often very general purpose. They can be used to solve any kind of problem. Domain-specific languages have become popular lately, and they’re basically tied to typically a business domain, such as investment banking, telco, or whatever. In Camel’s case, we’ve made a domain-specific language that focuses purely on the EIPs.
The language itself describes how to do the various things you typically do in the patterns, such as wire tap, aggregator, content-based router. These are first-class concepts within the language itself. We’ve implemented this domain-specific language in both Java and XML, so you can stick to a Java IDE if you prefer, or, if you’d rather, you can use XML to describe this language and deploy it inside your Spring XML.
Gardner: So, we’ve had vertical industry domain-specific languages. This seems to be more of a functionally domain-specific language. Is that a correct statement?
Strachan: Yes. The EIP is the functional domain, or rather the business domain.
Gardner: And, this is all about getting more granularity, more specialization for integration that nonetheless can play across a more general or horizontal capability. Is that fair?
Strachan: Definitely. Across all of IT we’re seeing increased specialization in many different areas, where the specialization helps us solve a problem at a higher level. If you spend your life solving problems, with, say, JavaBeans everywhere, you have a lot of code to comprehend and understand, and things can get quite complicated. The higher level of abstraction helps us solve problems easily.
Gardner: And, because we’re doing it an open-source environment where there’s a community involved, the more likelihood that this will be applied across many other different types of platforms and technology?
Strachan: Exactly. The other benefit of being with Apache is that we have a very liberal license, so this can be embedded in any commercial product very easily. We've seen lots of partners using this technology.
Gardner: Right. A few moments ago, we talked about ESBs. There has been, as you say, some divergence in the term ESB. There are also a number of products and approaches in the field. How about for Camel as a rules-based routing and mediation engine? Are there many others of those? Who else is trying to solve the same problem, or can we safely say that the Camel is unique?
Strachan: It depends on how wide you cast that net. Camel is unique in a number of ways. What we’re doing with Camel is defining a high-level language to describe EIPs, which I don’t think anybody else has done before. The other thing that’s unique is that this language very closely maps to components that work inside Spring 2.
We use a lot Spring 2 features, such as declarative transactions, inversion of control configuration, and various utility classes for working, with such things as JMS and JDBC and Java Persistence API (JPA). What we’re doing is raising the abstraction level to make things very simple, reducing the amount of XML we have to write, but still exposing the wire-level access if you need to do the really hard stuff and roll your sleeves up and get down and dirty.
Gardner: Let’s move this a bit closer to the business side. I wonder what sort of a problem set it is that we’re facing here. Is this a new approach to older problems or a new approach to newer problems? What's the problem solution fit here in the market?
Strachan: The problem we’re trying to address is the routing and mediation problem, which lots of people have. They're taking data from various components and sources -- whether it’s files, databases, message queues, Web services, instant messaging, or other data systems, integrating them together, formatting them, and connecting them to the systems. From a higher level perspective, this could be for legacy integration of systems, for smart routing, performance, monitoring, or testing or monitoring transaction flows.
In general, integration is a very old problem. As soon as we relate to couple of different computer programs, we already have an integration problem and that just grows with time. The thing that’s new is the approach that’s used. We're increasing the abstraction level by making it very easy to work at the EIP layer.
People don’t have to worry about the low-level details of how to use JMS, how to use JBI, or how to wire together the Spring components correctly, and so forth. We're giving people a nice, simple, high-level abstraction, but yet we are exposing all the power of frameworks like Spring and still exposing the low-level details if you need them.
Gardner: Over the last couple of years, because of the popularity and use of Web services, the business side wants to expand the interactions across not only applications, but organizations, and perhaps in a supply chain setting. It sounds like this helps solve the issue of inclusiveness across domains and businesses, and then adds the opportunity to start moving toward event-driven computing. Does that sound fair?
Strachan: Definitely. And, as soon as people start moving toward distributed systems, service oriented architecture (SOA), event-driven architectures, and all these other terms, the one thing that keeps happening is that people need a pervasive technology they can apply anywhere. Camel is lightweight, and can be used anywhere, in a smart end point, in an ESB, or a message broker.
ActiveMQ5 is coming out in [August, 2007]. That's going to have EIPs integrated in the client and the broker by Camel. ServiceMix has integration with Camel and CXF, as a project at Apache, which implements the JAX-WS standard that’s got EIP integration via Camel. We’re seeing a large number of projects that have EIP integration via Camel. It’s already proven in the open-source world that it’s very easy to reuse this routing and mediation technology anywhere. Hopefully, we'll see this just grow and grow.
Gardner: It’s curious to me. It seems like yesterday, but I suppose we're going on 10 years now, that a lot of these functions -- singular, distributed, perhaps even proprietary -- were combined into what became conceptually the application server. Now, it seems like we’re decoupling things. That one large application server approach might not be the best fit, as we get more types of routing and messaging in these integration patterns.
Can you expand on that? What's been the larger trend, in terms of architecture?
Strachan: There’s been a definite move away from J2EE apps, the big application servers, and people are looking for small, lightweight solutions that solve only the problem they have and not problems they don’t have. A lot of software vendors suffered from the kitchen-sink syndrome, where they tried to have one of everything in a big box. That just led to lots of complexity and redundancy.
People really want small and simple-to-use components that solve the problems they have. I've seen that throughout all of our customers. People ask for very specific solutions. They don’t say, "Give me a SOA." They say, "I need a message router," "I need a message bus," "I need an ESB," or "I need a services framework." Often, people have very specific requirements and are very much cherry-picking the best-of-breed components from the open-source tool set.
Gardner: So, it’s the Swiss Army Knife approach.
Strachan: Exactly.
Gardner: That works well for developers. I wonder over time how Camel might find itself being used in terms of operators, specifiers, and architects on the operational side of things. Do you see this moving in that direction? What’s the short-, medium-, and long-term implementation roadmap that you foresee for Camel?
Strachan: Today it's very much developer-focused. The current Camel is aimed at developers who are savvy with Java, XML, or Spring. What we want then is to gradually raise the abstraction level, so the architects and operational people can monitor services, monitor business processes, perform operational behavior, plus be able to design and deploy EIPs in a simple way.
For example, building tools and making it easier to design EIPs, as well as to choose a monitoring tool, are important.
Gardner: How would the specifying roadmap shake out? Do you think this is something that would get bundled in or integrated? How would this be something easily rationalized in production environments for those people that are going to be looking at large data center implementations?
Is this something that would be part of another grouping of products, other Apache kind of projects? How would this combine to make a whole larger than the sum of the parts?
Strachan: What we’ve seen over the last few years is a huge diversity in how people actually deploy products. Maybe five years ago, people assumed the world was J2EE app servers and everything would deploy in a J2EE deployment unit. These days, we see people make their own deployment units. We're seeing a lot of people move towards OSGi bundles. So we see a huge difference in the ways in which people deploy software now.
One of the reasons we’ve taken extreme steps to split Camel up and make it a very simple and easy to use bundle is that we know that there is a huge range of deployment platforms. Some people want to use Camel within their own smart end points. Some people want to host it inside the message broker, in the ESB and so forth. So, we see it going into production in many guises and many different forms.
Gardner: In IONA’s case, how would this be used in the context of its offering? I'm assuming that, as with other IONA offerings, it will be the commercial open-source support approach.
Strachan: Yes. Camel’s pretty much the core foundation for smart routing and mediation within an entire product suite. We have a product called FUSE, an open-source SOA backplane that provides a services framework, a message broker, an ESB, and a mediation and routing engine. The mediation and routing engine is based very heavily on Apache Camel, and we're using Apache Camel throughout other projects as well.
Gardner: Are there forums or community sites? How are some of the dialog and collaboration around this taking place?
Strachan: If you go to http://open.iona.com, there is a whole raft of documentation online forums, a wiki, and so forth.
Gardner: I know this is fairly early, but maybe this will be a good time to lay out some of the milestones. Are we expecting some significant developments and/or visions within the overall Camel project? Can you give us a bit of a timeline?
Strachan: It’s still fairly early for the timeline, but the next version of Camel 1.2 should be out fairly soon, and it's going to offer improved monitoring and management tools and particularly improved visualization and tooling.
Toward the end of the year, we’re hoping to improve various other capabilities we’ve added recently for extract, transform and load (ETL). It’s a way of loading data into systems and load testing systems with data. Plus, another area we’ve been developing what we call business activity monitoring (BAM), which helps monitor transaction flows across different systems.
For example, you might want to track that a purchase order in a system maps through to an invoice that comes out of another system. You might be processing a 100,000 of those a day, but there is one that goes along every few hours, and you want to find out which one that is within a small time window. That’s another area where we are extending the reach of Camel to do very complex and powerful monitoring.
Gardner: That's interesting, because this provides the actual routing mechanisms that provide a window into what's good, and also what's not good about how those processes are being built and used.
Strachan: Definitely. We’ve found that as soon as you have this very flexible and reusable integration patterns, it’s very easy to build on that, to build higher level abstractions, whether this is powerful testing frameworks, stimulation frameworks, ETL or BAM. We’re seeing the levels of abstraction increase to remove layers and layers of complexity.
Gardner: Is this something that could be applied to the ongoing -- and I imagine increasingly arduous -- task of dealing with semantic issues in terms of data across applications? That is to say, helping to define a mediation and a rules-based approach, such as this help in how companies can deal with that diversity and then come up with more common approaches to data and content that can then be injected into a business process.
Strachan: Definitely. This is a very large and complex topic. There are just a few bullet points on the top, and we’ve already got a range of transformation and validation capabilities in Camel, but we’re looking to improve this in various ways.
IONA recently acquired a company, called C24, which has a whole range of technologies for doing semantic mapping and transformation of different data formats. For example, they've got models for pretty much all the standard financial formats, like SWIFT, FpML, FIX, and all these other things. And, they've got other models for telcos. We’re looking to open source some of that and integrate that into Camel for doing lots of data service type integration.
Another area that’s kind of similar, but slightly different, is in the business activity monitoring ground, where you sometimes want to just check the effect of systems. So, it’s a little bit like I am doing real time reconciliation systems, and you’re doing all this transformation between systems, but you want to make sure of the end results, like that final purchase order or that final settlement instruction does contain the values that you expect. For example, we might want to check that the purchase order amount matches the invoice amount, or whatever.
Gardner: As you say, it’s early in the evaluation of Camel, but are there instances where we can see how it's being used or how developers have identified this as a productivity benefit, or are there metrics of productivity? How is it helping in terms of getting a better job done?
Strachan: We’ve got a bunch of different customers using Camel in different ways. We seem to have a few different kinds of customers finding Camel for the first time. Some come from an ActiveMQ background. They're doing lots of messaging, and they want something a bit more powerful to do more complex routing within the message broker itself.
Some come from the ServiceMix background. They are very ESB focused. They love JBI. They like the idea of standards-based ESB. They’ve got a bunch of standards-based integration components, but they’re working together, and they just want a slightly more powerful routing engine to work with.
Some of our customers have been using Mule. They found Camel a little bit easier, and they’ve migrated across. Finally, there are people who’ve just found Camel, that's all they know, and they just dive straight into it.
One of the things we’re seeing from customers is that using APIs, like JMS and JBI in particular, and to a lesser extent JAX-WS, could often become complicated, but people find that wiring things together with Camel is almost trivial. People get things going really quickly without having to read pages and pages of specifications for things like JMS or JBI, or dealing with the lower-level details of Spring.
We see quite a rapid productivity gain, and it means that people can then use lots of different technologies, whether it’s JMS or JBI without having to spend a long time figuring out things in the Spring manuals.
Gardner: Among these early users are there any vertical industries popping out, where it seems to be making sense first, perhaps financial services?
Strachan: Yes, finance and telcos definitely are big markets, but we’re also fairly strong in the e-tailers. Those areas will be our big three markets right now.
Gardner: Can you explain the business problems that they're using it for?
Strachan: Pretty much all of our customers have similar kinds of problems. They have lots of silos in applications. There are lots of messages being exchanged between systems, whether those are messages via flat files, email, JMS, legacy message brokers, or web services. They generally want to do one or more of the patterns, whether counter-based routing, or message transformations. We see more people starting to investigate a business activity monitoring feature of Camel, and that’s something I'm quite excited about.
Lots of companies, once they realize they can tie together messages to business processes, start running rules off the back of that. That has been extremely useful for people. One thing about SOA that’s quite difficult is knowing what’s really happening in your system.
Today, people have often done such things as monitor message queues or use a JMX-based management console to look at numbers and statistics. Being able to tie together all the different things flowing through your SOA to actual business processes is extremely useful and valuable for customers.
Gardner: There seems to be some murkiness in how feedback will occur, when you have events-driven architectures, and how to create common approaches to runtime and design time with this BAM emphasis that we are seeing associated with Camel. Do you expect that Camel could fill some of that role in terms of a balancing act between what takes place in operations and what needs to be brought into a service level agreement of some kind?
Strachan: Definitely. I have worked with quite a few customers on various BAM-related problems, and it does seem that BAM solves those problems. It’s quite hard to have an off-the-shelf tool to do everything people need. Almost as soon as people start doing any kind of BAM, they find that they want to put their own code in there. You might be in financing, and maybe there is a trade in U.S. dollars. You want to take that trade to the settlement instruction, but you want to do a foreign exchange conversion in there.
Almost as soon as you start doing the “hello world,” BAM-type scenarios, you tend to want to roll your sleeves up and actually do some coding of some kind, to do custom reconciliation, custom calculations, custom visualizations. BAM is very much a framework-driven thing, rather then a black-box tool. Certainly, we see people take on the Camel framework itself and then expand and extend it to do more powerful things.
Gardner: I suppose that’s part and parcel of open source, community-driven projects. They tend to be pushed out in a variety of directions. Do you have any sense of what other functional parts or functional capabilities we might see brought into Camel?
Strachan: A big area is visualization. It’s incredibly hard for people to follow what’s happening in general. Once you can create a wire tap into any system, it’s very easy to glean information from it and find out what’s happening, what its throughput is, what it is actually doing. You can then do things like trace messages around the system, correlate messages to business processes, reverse engineer whole business flows from legacy systems.
That whole area is a visualization and tooling problem. I see that as a very large area of research with the Camel project. We hope to be to be rolling out in Q4 the first batch of visualization tools. It's very much a work in progress in the next few years to get even better, more powerful operational controls and visualization engines.
Gardner: By getting more visual, it seems like we can bring more people into the process, and that maybe elevates us beyond BAM into business intelligence. Is that fair?
Strachan: Definitely. Absolutely.
Gardner: I think a lot of business people would like to get more of a real-time sense of what’s going on among these processes to provide more confidence, as they move processes from manual and older message into this new SOA approach.
Strachan: Definitely. Plus people want early warning notice of any kind of failure. One of the nice things is that you can be alerted that maybe something's going on that hasn't been found yet. Maybe it's running a bit slow today, or maybe it’s just a heavy trading day. But, it might not be, and maybe something is really wrong. So, rather than waiting for some extreme failure that results in a fine or extra interest being paid, you can respond more rapidly than that.
Gardner: Let’s just circle back quickly. Developers seem to be the core short- to medium-term audience for this. What sort of developers specifically should be more aware of what Camel’s capable of?
Strachan: I’d say anyone who’s doing any kind of SOA or distributed programming. They should at least take a good look. Definitely, anybody who ever read the EIP book. If you read that book, you’d probably just see Camel and you’ll immediately just figure out exactly what it’s doing. It’s very simple.
If you're doing Web services, you might need mediation. If you're doing any kind of messaging using multiple databases, if you have any kind of integration problems, and certainly if you’re using any kind of ESB, then definitely take Camel for a ride.
Gardner: Now, when we look toward getting more information on this, we have the resources at Apache Foundation, and also, as you mentioned, http://open.iona.com?
Strachan: Yes.
Gardner: Any other resources? You mentioned the book. Are there any other resources on this that people should be aware of?
Strachan: Those are the big three. There’s also my blog: http://macstrac.blogspot.com/.
Gardner: Very good. Well, we’ve been discussing a budding Apache Foundation project known as Apache Camel. It’s a rules-based routing and mediation engine for POJO-based implementation of EIPs.
Discussing this with us today, we had James Strachan, technical director of engineering at IONA Technologies.
I'm your host and moderator Dana Gardner, principal analyst at Interarbor Solutions. Thanks for listening and learning more about Apache Camel.
Listen to the podcast here. Podcast sponsor: IONA Technologies.
Transcript of Dana Gardner’s BriefingsDirect podcast on Apache Camel. Copyright Interarbor Solutions, LLC, 2005-2007. All rights reserved.
Showing posts with label podcasts. Show all posts
Showing posts with label podcasts. Show all posts
Thursday, August 16, 2007
Tuesday, July 10, 2007
Content Becomes King Once More – This Time of Search Marketing
Edited transcript of BriefingsDirect[TM] podcast with Media Survey's Sam Whitmore, recorded
Listen to the podcast here. If you'd like to learn more about BriefingsDirect B2B informational podcasts, or to become a sponsor of this or other B2B podcasts, contact Interarbor Solutions at 603-528-2435.
Dana Gardner: Hi. This is Dana Gardner, principal analyst at Interarbor Solutions, and you're listening to BriefingsDirect. Today, a podcast discussion about the future of marketing -- maybe we can call it Marketing 2.0?
We're going to talk about content creation as a strategic activity, and we're going to talk about what the PR and marketing folks in the field, in the enterprises, in businesses, are making of all of this.
Joining us to sift through it all, we have Sam Whitmore, founder and editor of Sam Whitmore’s Media Survey. Welcome to the show again, Sam.
Sam Whitmore: It’s great to be back, Dana.
Whitmore: It’s as close to substantial as it’s ever been. There are many segments, and we should be careful about generalizing, but in our world are the people that are likely to listen to this podcast. People understand about RSS feeds now. Microsoft Vista, entering the market with Web feeds, moved the marble a little bit -- and it's a very exciting time.
Whitmore: We're now getting people to understand the concept of "You don’t have to browse anymore." They still search, of course, probably more than ever before. But think about the two ways that people get their information now. It's either through RSS syndication, or through search. And it’s almost quaint to think back about, "Yeah, I think I am going to go through my bookmarks and see what I haven’t visited in a while." I don’t know anybody who does that anymore.
What’s been interesting for me is that as I have created content -- some of it of by my own creation and, and other content that is sponsored -- people want help in creating content. As an analyst, I can moderate a panel or discuss something with users, and then make that available to many people. But that content has now become a very powerful force in search, and I did not intend it that way.
I intended this content to be something that had more of an RSS play value. But what’s happened is that the content is a search-ranking benefit for the topics we cover. I will blog about this content on three blogs, and I share it with distribution partners who are often IT media companies like TechTarget and E-Commerce Times. I also share it with direct subscription-based content deliverers to IT decision buyers, including Books24by7, AnalystPerspectives, Gerson Lehrman Group's News, and Insight24.
There are a number of channels that this audio and text content then finds its way into -- where it's tagged, has a different URL, and is associated with a different Web domain. The search engine crawlers and the algorithms that rank content take a look at this content and say, “Wow, it's going across multiple domains, it's been tagged a lot, it’s been put into bookmarks, and linked to -- so it must be highly relevant." And this content tends to move up swiftly in the search ranks.
So, my question to you, Sam, is: Are you seeing search marketing as I am seeing search marketing -- that it is becoming as important as advertising?
Whitmore: In a word, yes. I'll know a lot more in a couple of weeks, because at the end of the month, out in
Whitmore: So, you tell me. How are you doing with that? Is it driving your business?
That’s sort of led me to another concept, which I call the "content pyramid." Interestingly enough, I’ve stumbled onto this in the same fashion that I stumbled onto search as an important element. Because I look at software development and deployment strategies as my main domain area for coverage -- and then I am more of a practitioner of Web 2.0 in terms of how I deliver content -- I’ve noticed over the past five years or so, a more strategic approach to software development.
That is to say, there's a new way, instead of small groups off doing their own thing, creating their applications that run autonomously on a monolithic stack of some kind, that have no real relationship to one another, and that at some point I might have to integrate and/or assimilate the data that they contain and create. The idea is to take a strategic overview and to think about applications from an architectural perspective.
The idea is to think of applications from their lifecycle, not just how we create them -- but how we might want to use them in the future, or even sunset them. Then think what we’re going to do with this pile of data that, in many cases, is about the same customer or the same product, but in a different format in a different application? This one-off approach is just not productive, and it’s expensive.
Companies are spending 70 to 80 percent of their IT dollars just on maintenance of these existing applications, and are not doing innovative new things. There has been a whole host of things that have happened around, "Hey, let’s create components, let’s use standards, and let’s develop around a common framework such as Eclipse." So, there’s more of a strategic approach to software.
Ultimately, the goal is a Service Oriented Architecture (SOA) where you have lots of different business services that you can then package, mash up, and aggregate to create different processes. Then, you can tear them apart and build them up again. It’s more of a use-reuse, common-repository mentality, and not just one-off production.
Whitmore: All right, so let’s see how you pull this off with content.
But when you think about content more strategically, and can plan for and create core content that can be reused and extended across different uses -- like marketing literature, the documentation you provide for your services and products, your advertising, as well as your communications with your investors, with analysts, with the press -- you create more of a coordinated core set of messages and documents and content. We'll be seeing more audio and video increasingly in this mix.
If a company can create this content core and allow people to use it and make it accessible -- in the same way as with the development of software tools and components -- you can better control your costs. You can better control your message, because more of your messaging will be in sync, because it's all coming off of the same core. You can create a lot of this core without having to go through a sixth-month review process, and without taking up your experts’ and your company’s time by forcing them to write 80-page papers.
Maybe this whole notion of the conversation that is prominent in social networking and in Web 2.0 -- of having a series of conversations, capturing it as audio, turning it into text, reusing it across different aspects of your communications, and increasingly, capturing it as video as well -- will allow for a much easier way of gathering knowledge from your experts and users, keeping it on message, and then making that available as a set of core content.
Now, it’s a vision. There is always going to be a lot of need for exceptions, but conceptually starting to think about content strategically to me makes a lot of sense now.
Whitmore: Well, I know that Netflix has somebody in the CCO position, Chief Content Officer, and that they have looked into that as a fundamental principle of communicating to their constituencies, their prospects, their customers, their investors, and people like that. So, it is a good idea.
We now have the ability to distribute content far more widely, but, at the same time, in a more granular sense -- that long-tail concept -- more widely, yet more targeted, and more cheaply than ever. So, you can create a 30-minute movie, put it on YouTube, and almost anyone on the planet has access to it. Anyone, by the way, who does a search on the key issues about your value, your products, or your company gets to the content.
More companies will be making some pretty high-quality, interesting, 30-minute, maybe 15-minute movies. We are already seeing this. There was a great one on SOA that IBM did not too long ago. Are you, as a marketer, going to want to have someone else define your messaging for you? Or are you going to start thinking about doing this yourselves?
Again, IBM is a bellwether in this, at least in the IT space. They’re just creating scads of content. And when you go to Google, if you type in "SOA" or "Services Oriented Architecture," which is an important direction and business opportunity for IBM, the left hand side of the search page, that free-content stuff, is littered with IBM content. Discussions with developers, whitepapers, mentions in press – these are the things that get vetted by the search engine algorithms as being relevant.
Any company that has a strategic direction in which they are taking their business should say, “What are the keywords that relate to our future? What is the content we can create that will drive recognition from those keywords of our value, specifically as an individual company? And how can we create an ongoing process by which we’re feeding that algorithm machine over and over again to retain that high ranking?"
That to me is Marketing 2.0.
Whitmore: That model works hand-in-glove in uber-search environments like a Yahoo!, YouTube, or Google. But in the world that I follow, you've got the IT and tech media really trying to drive their brand, because they don’t want you to go to Google and type in “SOA.” That would be a terrible defeat for them.
Whitmore: But as you get closer to, “I've got to make a decision on a reseller or a solution provider or vendor," then I think that I am not going to trust IBM. They are not going to be my goal because they are going to be omitting the stuff about BEA and its competitors.
Whitmore: It absolutely is. They can work in parallel, and these IT trade titles and these people that are being rapidly disintermediated need to figure out how to get some of their content to rank well in generic search environments. That brings us back to SEO and the fact that you can subscribe to RSS search results. These people really are getting hammered.
Whitmore: I have an editorial bias, when I hear the word "content." I think about generic, by-the-pound content. Whitepapers have their place, and product documentation too, but as the 20-somethings and 30-somethings take over the world – and that’s happening – they are not going to accept the same blandness and pseudo-authority that a lot of content has for us.
Why not give the long tail its due, put up a series of five key discussions with the experts you would have interviewed anyway for the whitepaper, let people either read the transcript or glance at the executive summary of each individual interview or discussion, and then pick and choose? To me, that’s just a better way to learn. And it's also a lot easier for the experts as well as the authors. So, it really is a discussion.
There are more young people thinking about community and social networking, and so why not combine all of this into a happy discussion that is also substantive and educates at the same time?
Whitmore: It reflects real people with real attitudes, and not created by the lawyers and the PR people and the conservative forces within companies because that’s simply not going to work. One of my last points questions is, when are we going to see an example of a company relying on "content pyramid" philosophy, and could we prove that they were successful doing so? When are we going to see that?
The scale is much greater and the cost can be comparable or even lower. You are going to start to see what works in the field. When people recognize that if they are number one or assumed to be in the top several media outlets, they are going to have to be there. Vendors will cultivate the search option too through PR and AR and Investor relations and operate among different channels or distributions of content to reach their end-users and communities.
I can see "search relations (SR)" as another possible definition of people’s approach to this.
Whitmore: That’s a very interesting concept, but from a VP of sales perspective, Dana, I don’t want 30,000 leads. I want the 25 that are in an advanced state of consideration for the product that I sell.
Then, if they listen to the podcast, you get down to the where it’s a lead generation benefit. That’s where you separate the wheat from the chaff and you get real leads. It's also where the content pyramid works. You need the content to walk them down that path of self-selection.
But, I would rather start with a large universe and work it down, creating brand affinity and relationships with those people, and then find the content and the mechanisms that then bring them to the point where they are ready to sign up for the product or service.
The pyramid is, in that case, inverse – you start wide and you go narrow. But the content creation process should start specific and narrow and then go wide. It has to be two-way discussion. Once you engage the people on a discussion, that’s where you have a myriad of opportunities for bringing them into your business.
Whitmore: Are there examples of people that are prospering with this philosophy?
I’d look at some companies that are good at that. I'd again bring up IBM, but I have also noticed that BMC has a very good page, where you can go for information. And this page has got a listing of all sorts of content that has to do with specific values about what they bring their customers.
And they're saying, "Here’s the content that we have created. Here’s content that we found out there that others have created. Here are links to blogs and podcasts that we think are relevant to this. Here’s a download of whitepapers in the traditional marketing literature." It's really just a site or a destination around a topic that’s a subset of their business that people can go to, and then they could get an RSS feed from.
In a sense, BMC is doing their community a service through a knowledge triage around a specific topic that then hopefully will engage the community. So, BMC is a good example. They still have to populate this. People who come back, people who have a subscription to RSS, are going to need something new and fresh coming down their pipe every week or two.
But, they're creating this funnel, qualifying people, and then hopefully getting them into an engagement. It therefore requires these companies to become publishers themselves.
Whitmore: But, most companies don’t have the headcount for that.
Whitmore: Because usually the executives are going to say, “If I had any spare headcount, I'm going to put it in sales and field marketing and they're not going to get into the publishing business.” They might subcontract it out, but I don’t think they're going to bring it in-house. I’d be very surprised.
Whitmore: What kinds of companies?
Whitmore: That’s interesting, because they live in a viral world. And Apple’s the same way.
It will be a mixture. Some companies aren't going to be interested in being in the content business. They’ll outsource the whole thing. Other companies will say, “Listen, it just makes more sense for us to make this a core competency. We'll still use traditional media, but we're going to create our own media too.”
Let’s think about the numbers here. Let’s say you're a $5 billion-a-year company, revenue-wise, in the IT space. You and I have worked for large IT publications. What was the total editorial budget?
Whitmore: Back in my day? It was at least $1 million.
Whitmore: If I had strong enough leadership, I would.
Whitmore: Being a student of media, I have observed a collective lack of will across most segments most of the time. When you see the exceptions to this, that’s when you see a feature story. That’s when you see a Q&A. The journalists are out there beating the bushes to find people with spines who do something other than what's expected of them.
Whitmore: I love that site. That is the absolute archetype for vendor publishing, as far as I'm concerned.
Whitmore: Well, that’s a good place to send people. It’s newsroom.cisco.com I believe or is it news.cisco.com?
Whitmore: Well, I guess I’m old school and I never realized it. I tried to think of the destination but you're right, I don’t need to, and that sort of makes your point.
Well, we've been having an interesting discussion. I want to thank you Sam, but we're out of time. We have covered some Marketing 2.0, maybe even some press release 2.0. I've been tracking what folks like Shift and Edelman and some of these other firms are doing, where they create a whole slew of rich content that becomes available when a press release or a news event happens, I think it’s very similar thinking to what we've been describing.
Whitmore: That’s right, a content stack. We probably don’t have the time to get into that, but here are the two things, the two litmus tests, that I would point to regarding this social media press-release thing. Number one, who are the vendors using this approach and do they continue to use it once they have started? Do they stick with it?
The other thing is, are journalists publicly saying, "This helps me do my job better and I'm inclined to write longer or richer pieces when I'm communicated to in this new way?" When I start to see critical mass in both of those areas, then we’ll know that the trend is taking hold. Until we see that, I'm still skeptical
Whitmore: You've done it to me again. I didn’t think of "search" first.
Whitmore: Even though I started with it in this podcast interestingly enough.
Whitmore: That’s right. Well, Dana, I enjoyed it as always. It’s great to talk with you.
This is Dana Gardner, principal analyst at Interarbor Solutions, and you have been listening to BriefingsDirect. Thanks.
Listen to the podcast here. Produced as a courtesy of Interarbor Solutions: analysis, consulting and rich new-media content production.
If any of our listeners are interested in learning more about BriefingsDirect B2B informational podcasts or to become a sponsor of this or other B2B podcasts, please fill free to contact Interarbor Solutions at 603-528-2435.
Transcript of Dana Gardner’s Podcast on Marketing 2.0 with Sam Whitmore. Copyright Interarbor Solutions, LLC, 2005-2007. All rights reserved.
Thursday, May 03, 2007
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.
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.
Subscribe to:
Posts (Atom)
