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 IONA. Show all posts
Showing posts with label IONA. Show all posts
Thursday, August 16, 2007
Monday, August 13, 2007
BriefingsDirect SOA Insights Analysts on IBM’s Telelogic Deal and Open Source ESBs
Edited transcript of weekly BriefingsDirect[TM] SOA Insights Edition podcast, recorded June 15, 2007 .
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: Hello, and welcome to the latest BriefingsDirect SOA Insights Edition, Vol. 20, a weekly discussion and dissection of Services Oriented Architecture (SOA) related news and events with a panel of industry analysts and guests. I’m your host and moderator, Dana Gardner, principal analyst at Interarbor Solutions.
Our panel this week consists of Jim Kobielus, principal analyst at Current Analysis. Welcome back, Jim.
Jim Kobielus: Thanks, Dana. Hi, everybody.
Todd Biske: Thanks Dana.
Brad Shimmin: Thanks for having me, Dana. I focus on application infrastructure and spend most of my time thinking about middleware and SOA.
Dave Linthicum: It’s Dave Linthicum.
As I was saying, we’re just getting into our topics, and we’re going to look at some of the IBM news this week that came out of the Rational Division. There was the intent to buy Telelogic, a Swedish firm that’s got a lot of product across requirements, tests, QA, architecture and modeling, as well as embedded and system development. So, we’ll talk a little bit about that.
We’ll look at some of the announcements out of the Rational Developer Conference, including the Jazz Community, an innovative commercial/open-source community approach to development. Also, one of the more interesting product announcements was Rational Asset Manager, essentially a design-time metadata repository that can be used in conjunction with an operational or run-time registry and repository for a lifecycle approach to services.
What’s more, we’ll go around the table and look at what research folks have been conducting this week. That might include a look at WS02, the IONA Artix announcement, and some announcements also from BEA.
So, let’s start with the Telelogic acquisition. Telelogic is a publicly held company in
Why don’t we start with Jim Kobielus? IBM and embedded -- we haven't seen anything along those lines for a while. They jettisoned the Rational embedded drive before IBM had acquired Rational, but now they seem to have a new-found interest in embedded. That's increasingly focused on end-to-end development, recognizing that the entertainment and media sectors are going to be creating devices different from a personal computer. IBM doesn’t want to miss out on the opportunity to leverage its back-end systems vis-Ã -vis these new types of devices. Any thoughts, Jim?
Kobielus: Clearly, IBM over the last few years has made stronger moves into the appliance space and really helped to define it. Obviously, with the DataPower acquisition a few years ago and increasingly taking their data warehousing appliances -- I think they’ve already revamped that entire product family -- they can scale from very small, or relatively small, data warehouses to very large ones.
IBM is trying to fuse their chief software products and technologies with their hardware engineering expertise to develop products for various markets. Embedded operating systems, embedded application components, and so forth, are key to all that.
So, when I saw that they were acquiring Telelogic, it made perfect sense. IBM is very much bringing together the hardware and software worlds into appliances, both for the business and potentially for the consumer market.
I think they see a wide-open opportunity in embedded that is still a fairly wide-open, roll-your-own test, roll-your-own tools, even roll-your-own IDE or real-time operating system. So, I wonder if anyone else has some thoughts on the embedded angle on this?
Shimmin: Well, Dana, not so much about the embedded angle, sorry to say, but perhaps something that might transition us into talking about Rational. When I look at what IBM is doing here -- and this is pursuant to what Jim was just saying about their synergies between hardware and software -- I see IBM doing two things.
One is renewing the focus on software development on the design time and development time side of things. Then, I see them taking their expertise in hardware and putting the two together to build what a lot of the software companies or platform companies really wish they had in the space, and that is the ability to do two things: create well-performing software and actually have software that performs well in the production environment. They’re going to be pretty well positioned to take advantage of those two things.
They seem to be involved now more and more with getting very close to the application, almost to the point of being in a position to be dominant in terms of custom application development. Do you have any sense from your perspective, Brad, about the whole notion of the shift in the definition of applications and how to create them?
Shimmin: Absolutely, Dana. It’s funny. Both IBM and Oracle are the two companies leading the chart with what you just said there. They’re taking tentative baby steps, because this is a pretty daunting task they’ve undertaken. That is, as you said, dive deep into a given vertical and a given set of business processes within that vertical to provide literally out-of-the-box functionality. You’ve got your data models. You’ve got your actual BPEL processes. You’ve got everything that surrounds whatever it is you need to actually get some sort of process up and running within their environments.
Maybe five years ago or so, platform vendors really focused on the foundation infrastructure of what these applications run on. They’ve realized in maybe the last six months that the success that they’re going to enjoy is going to come from their ability to save their customers money from the exorbitant consulting and professional engagement fees that usually come hand-in-hand with rolling out software like this.
So, what they're doing is pretty cool, and I applaud them for it. As I was saying a second ago it’s a pretty long row to hoe and it’s going to take a lot of energy on Oracle’s and IBM’s part to actually fulfill this and to say, “Okay, we’re going to give you a set of business processes with all the data you need to set them up and get them running for your vertical.”
Shimmin: I think IBM is actually leaning that way and they have a very strong ecosystem already in place.
Biske: I have not evaluated it myself. Momentum’s CEO, Jeff Schneider, said maybe we’ll see some more activity on that product. It’s interesting, because I’ve yet to run into an organization that’s really leveraging some of the EA-specific products that are out there. They still tend to do 90 percent of what they need to do in Visio, rather than some of the specialized tools in that area, but, as the discipline matures, we’re going to see a lot more of that.
I want to talk a little more about this notion of it bringing IBM closer to the application business that you first commented about in your blog. At least, that was the first time that that was brought to my attention.
I have a friend from college who has worked in the embedded space pretty much since we graduated, and he contacted me recently about applying SOA to some of the work that he was doing. It surprised me a little bit, because it’s not a space that I’ve had to deal with. I’ve typically been in big IT and big enterprises. It opened my eyes that their environment for developing is maturing as well. They are getting to higher levels of abstraction and taking advantage of the same types of programming models a typical enterprise developer is.
I thought they were going to be so focused on performance and real-time behavior of these systems, that they may not have a strong interest in some of the things that Web service standards and XML have to offer, because of the tradeoffs from a performance standpoint. He said, “No, we are looking at all of that.”
Now, with IBM making this acquisition of a company that’s dealt in the embedded space, it really shows that development is still development. IBM is now recognizing that it’s not all just about “build whatever you want.” We are getting more specialized, and maybe the right way to get into the applications market is to create specialized tools for particular vertical domains, rather than providing the applications themselves.
It’s definitely something to pay attention to, as we go along. They did it on the tool side; they did it on the software side with the Webify acquisition last year; and I would guess that we’ll continue to see more in this direction.
Linthicum: What’s missing in the space is a holistic design tool around SOA. I looked at Telelogic at the EA Conference in
Linthicum: I did look at it from the online piece, and I think that it’s going to have value in this space as well. The folks at IBM are not dumb. They’re out in the back, trying to figure out how all this stuff is going to fit together. They want to have not only the mega-stack in terms of deploying technology and development technology, but the mega-stack in terms of the design time stuff, including holistic enterprise architecture, asset management, service management, and SOA governance.
So, it’s going to be very difficult not to see IBM in almost all the larger SOA implementations out there, once they have a critical mass of tools. They’re investing right now. They see this as a long term strategy and a way to gain revenue 10-15 years down the line. I think they’re making some smart moves. I would have acquired Telelogic as well, if I were IBM.
Linthicum: Oh, it’s a bargain. They did very well buying it, and they’re going to reap a lot of benefits from it. This is the right move from IBM and the investors are going to love that three or four years down the line.
Kobielus: That’s exactly what I’ve seen too, Dana. Rational is becoming the crown jewel within IBM. In my area of focus, master data management (MDM), the Rational tool has become the primary master data modeling and domain modeling tool for all of IBM’s MDM products. I agree. It was probably their most important acquisition in the last 10 years.
One last item in the IBM news. They announced this Jazz community, jazz.org, and it’s essentially an open environment, which people can join and help contribute to the development of Rational products. This is somewhat of a trial balloon with IBM saying, “Wow. Look, how successful Eclipse was as a governance environment and a community development force in the market. How can we take what was good about Eclipse, but apply it to commercial product development, not just open-source development?”
It strikes me that if the companies who partner with IBM that have a vested interest in how their products relate to the Rational products contribute and help define the Rational products, then the same model could be applied to other commercial aspects within IBM, and they could then perhaps even take the model to other products. Has anyone had a chance to look at Jazz? Do you think that this is a wacky idea, or do you think it will get traction?
Shimmin: I looked at it a little bit. This is not the first time this has been done, and it certainly won’t be the last. As you said, they saw the success of Eclipse and they saw that it was an environment that fostered innovation. As we all know, it’s very hard for large closed-source vendors to innovate quickly, while maintaining a customer base accustomed to once-a-year big upgrades, punctuated with little patch here and there.
I look at what IBM has done, as well as TIBCO, Sun, BEA, and Red Hat -- even though they’re not closed source -- and I see them using the tools that the open-source community fostered in order to collaborate over a large-scale network of developers, and they’re applying it, just as you said, to closed source. There are many benefits to that.
First and foremost is a quicker turnaround on bug fixes and getting to a GA. When you’re dealing with the traditional closed-source development cycle, you build your software, you send it out to maybe 10 trusted customers. They hammer on it a little, and you have your own internal people hammering on it, and that’s maybe a three month venture.
Using 10 customers, who have their own jobs to do and don’t give this a lot of shrift, sets you up for failure. That’s why we see so many post-release patches going out. What this is going to do, if it succeeds and can be applied to closed source, is let these large vendors get their code out quicker in a much more tip-top, enterprise-ready fashion.
Shimmin: Absolutely. IBM is taking a tiered approach to it, and some of the others have too. As we were saying with these trusted customers and partners, partners in particular are going to play a big role in this, but they would get access to source code at deeper levels. Folks that maybe are smaller customers or just interested parties, who want to make this product go forward, will have more limited access, unlike a traditional open source. They’ll have more limited access to the details of the source code.
Shimmin: Should we be thanking Microsoft, Novell and SUSE for that a little bit?
Shimmin: Absolutely.
Biske: It’s an interesting idea. I wonder how different it is from some of the efforts already going on. Clearly, we have commercial efforts built on open-source products. The key question here involves open-source products that are not available for free. If developers are working on it and they can build it and use it, how is that model going to come together if they say, “No, you only have a license to run it in a development mode and nothing more than that?” Is that going to be followed or not? Are they going to bother to enforce it, or do they really know in the long run it’s going to take the same direction that Eclipse did.
IBM has a commercial version of Eclipse, but largely people just go with the free product, because they can still include all the plug-ins that they need to. If they need to buy add-ins to it, they’re okay with that. So, they can focus their attention on Eclipse and create a framework, and can plug-in commercial components as they need to.
The other risk that they take is that the community is just going to look at this and think they’re just looking for free work. trying to take advantage of developers who just love to code and could care less whether they’re getting paid for it or not.
Shimmin: There are no selfless acts. Right, guys? When I scroll some message boards for these development efforts, I see people in enterprises saying, “I need access to this API because I need to extend the product to work with something I’ve built in-house.” I think that’s the kind of work that’s going to drive us forward.
[[[Speaker:]]] It’s the same phenomenon as the developers who are employed by a vendor like IBM. They quite often work excessive unpaid overtime, just because they’re committed to their jobs, their products, etc. In a sense, now you’re roping in the partner ecosystem as well. They’re putting in essentially unpaid overtime to help out the mother-ship vendor get its products debugged and developed.
Okay, let’s move on to some other topics. WS02 announced ESB 1, which is largely based on the Apache Synapse ESB. I want to make a disclosure that WS02 is a client of mine, and we should consider that as I present comments. I wonder if anyone else took a look at this, and had some thoughts on, “Wow. Yet another ESB and yet another open-source support maintenance business model entrant in the SOA ecology?”
Shimmin: Dana, I talked to them briefly about this before they released it. Like you, I saw this as, “Oh, yes, here’s another one, and maybe Red Hat should worry.” But, I don’t think anyone else is going to worry, except maybe the pure play ESB vendors like
They’re focusing on what everybody in this space is trying to focus on, performance. Everyone has realized that ESB is at its level of maturity. You need to really be focusing on availability, reliance, reliability -- the “ilities” -- of deployment. This is the third vendor in the last month -- this would include
Shimmin: I got the same vibe from them too, but I feel as if every vendor with an ESB these days feels the same way. They realize that, as with databases, you’re going into a heterogeneous environment regardless, and most likely inter-departmental, inter-company you’re going to have multiple ESBs and different messaging platforms that need to interoperate.
Biske: It doesn’t bother me. I’d rather see a lot more in the open-source space. They’ve got the freedom to keep it more focused on some of the target areas. In the case of WS02, they really are focused more on what I call the middle capabilities, rather than on service development and execution capabilities. You see a lot of the commercial ESBs going in the direction of giving you an orchestration platform and a composition platform. All of it is about building new services, and not about connecting existing consumers and existing service providers.
Some of these open-source ones are keeping it a little bit more constrained and targeted. Now, with the open-source model, if an enterprise needs to augment that for their particular needs it gives them the ability to do so. I’ve run into a few clients who are looking at some of these products and have a potential need to do that. The openness is a plus for them.
I don’t necessarily see it as too many ESBs out there. The market naturally will shake them out on its own. This is just the way these product spaces work. I don’t view it as an SOA bad thing.
Biske: Absolutely. At Momentum, we’re vendor neutral, and I know Dave talked in a recent podcast about the importance, when dealing with system integrators, of having one that is not closely tied to a particular partner, unless your company has already decided that you’re married to this particular vendor. Then, it makes sense.
If you’re looking for your pure systems integrator, you have got to select solutions that are in the best interests of the client, not the best interests of the consulting company or the partner ecosystem around this. Having open-source products gives us a lot more flexibility in meeting the needs of the clients.
Linthicum: I don’t put as much value as everybody else does into the open-source equation. In fact, my client base -- and it’s Global 2000 and government folks -- are indeed buying ESBs and other things based on the notion of having access to the source code. I just can’t imagine in my lifetime that they would ever want to become a product development vendor and would have the skill set to actually maintain a middleware product, having built a bunch of those in my lifetime. I’m a little skeptical about the ultimate value there. To me, open-source needs to have marketing value. I’m not sure it’s going to have a lot of technical value going forward.
My larger concern with the number of ESBs out there is that, in many instances, these have a tendency to be queuing systems with service interfaces on top of them. Therefore, they’re more information- or data- oriented than transaction-oriented. That has a tendency to limit some of the emerging patterns I’m seeing within SOA. People are looking basically to automate these high-end business transactional systems well beyond just data consumption and production.
Most of the ESBs don’t really address that. They basically become queuing systems with a nice interface on them. To Todd’s point, they do have orchestration layers and other development technology. Some of the higher ESBs out there definitely have that capability. That seems to be nice, but it still seems to be limited by the underlying infrastructure that they’re selling.
I’m concerned about the number of the ESBs in the market, and I’m concerned about the ability of those ESBs to deliver the ultimate value as the SOA we’re building becomes much more sophisticated.
Shimmin: This week I looked at two things primarily. One was the release AmberPoint made regarding their SOA validation system and their SOA management system. They have two products and they just versioned them to 6. I found what they were talking about very interesting, because, as I was just saying a second ago, they too are focusing on performance.
What they’ve gotten at is their desire to be in a run-time environment, because, as you guys know, they are like the Switzerland of SOA run-time governance in our industry. They are focusing on being able to scale their platform, and they have a number of partnerships and potential partnerships with hardware manufacturers, going back to our earlier discussion about IBM and their DataPower acquisition.
They seem to have this idea of, “Well, we’re run-time governance only, and we have the capability to be design-time governance as well, but we’re not going to get into that space.” I found that interesting, because they’ve just announced this as a part of this pre-flight check that they do. This is similar to the type of the service that
In the AmberPoint product, but a little bit more predominantly positioned, they actually go look at that WSDL as it relates to other processes across the entire application and looks for any interdependencies, broken relationships, and anything within the production environment that may cause a problem.
I think about companies like CA, HP, and IBM, who all really are trying to come at the same problem, but from the design and development side, and I think of AmberPoint coming at it from the run-time side. I feel like, “Well, why don’t you guys just get together? Let’s put these two notions together and make it so that we have a more coherent lifecycle management of our codes for SOA implementations that starts in design and ends in run-time.”
Shimmin: It’s a combination. When I talked to AmberPoint about that very question, Dana, we were talking about it with regards to this throttling technology they have, where they can look at PKIs and SOAs that have been defined inside the Registry Repository and tell the process to slow down on Thursday afternoons, for example, because I need these other process to take priority on that date and time.
I said to them, “Well, gosh, I know there are a lot of tools out there at designed/development time – a lot of BPM products for example -- let me establish these and stick them in a registry. You just pick those up automatically and start executing them.” They said, no, because the schema and the amount of data that comes from this is not really enough to do it.
Shimmin: Right.
Kobielus: One of the glues, of course, is a common registry and repository infrastructure between the design-time and the run-time environments, but just as important is the wetware, as you indicated, a common governance environment with roles and workflows. People who are doing the design and optimization of the Web services and the people who are administering the services in a run-time can be collaborating on a ongoing basis.
The common rules and policies of this common infrastructure, be it AmberPoint on the run time or tons of other vendors on the design time, they can all share. So, it’s a bit of the registry and it’s a bit of the governance human administrative workflow.
Biske: It’s interesting that you bring that up, Jim, because one of the things that I wanted to come back to was the Rational Asset Manager. It seems to be typical of IBM that in their SOA offerings they’ve got three of everything. If the registry repository is the key, and I agree with you that this is really the unifying component on some of these things that are dealing with policy on the metadata, they’ve got Rational Asset Manager, which is effectively a metadata repository, and then they’ve got WebSphere Registry Repository, which is another metadata repository.
I’ve had conversations with them going back a couple of years on this subject, asking “How are you going bridge those, and what’s
Brad hit on the other point, in his conversation with AmberPoint, that it’s not the fact that you have a metadata repository out there, but it’s the information that’s going into it. Until there’s some standard level of policy domain languages that these tools can leverage, you’re going to still see people just building their own fiefdoms and saying, “Well, you’ve got to have either AmberPoint everywhere or HP everywhere -- or whatever your management system of choice is -- to be able to do some of these things, like throttling across systems, and some of the run-time policy enforcement. It does need to bridge all the way back into the development tools.” So, again, IBM’s in a great position, providing products in all of those spaces, but it’s going to be difficult to pull off.
Linthicum: It’s possible for the newer offering, but they will have some pushback, given the fact that every domain is extremely different. One challenge that people have, when they try to get out in the market with this kind of stuff, is that ultimately what they think they’re implementing is different than what’s actually being implemented. I see a huge chasm between the perceptions.
For example, I was at the Gartner event this week to do a talk on ROI, and I got a chance to wander around and talk to a number of the people who are pushing in the market, both customers and users. There’s a very different perception as to what vendors think the problems are and what the problems are that users are actually experiencing. There’s going to be a bit of a sobering [[[-- come to Jesus --]]] that’s going to happen over the next year or so, when these guys push out there.
Linthicum: In the user community, all the problem domains I’m seeing, definitely in my client base, are unique. There doesn’t seem to be any one set of solution patterns you can apply across the board. You see bits and pieces of a stack and how simplistic those problem domains are. The vendors don’t see that when they design SOA in general. They typically give you the same stack and the same problem description. I’m not seeing a consistent problem description out there to work with the client.
Linthicum: You can’t do that, and that’s the problem people are running into right now. I saw the same thing back in the integration days, back in the AI days. We tried to take one problem domain, all the spaghetti code, and put it through a single hub. While that was applicable to a small percentage of the problem domains, it wasn’t widely applicable. It wasn’t applicable to all problem domains. SOA is even more complex than that. Vendors are going to find that they’re missing the boat in terms of understanding the needs of the people they’re trying to serve.
Linthicum: Dana, it’s all about people. As I’m getting further along in this stuff and learning more about it, I find that the people issues are really the core of all this all. I can solve any problem with technology, and probably everybody in this space can do the same thing. However, getting people aligned with how that’s going to happen and setting them up for success is the ultimate challenge right now, and the vendors need to understand that.
Shimmin: Back to our example of AmberPoint. If I have a nice BPM tool that lets me find my PKIs and SOAs, and if it’s not in my best interest to include that additional data the additional artifacts that AmberPoint is going to need to make that throttling automatic, why am I going to do it? I won’t.
Kobielus: That explains why I’m seeing more emphasis in the SOA space on pre-built domain models, essentially solutions that package up the rules, the best practices templates, the workflows, the policies, and so forth, for a particular problem domain, be it in the MDM space or be it in the ESB space. The customers are demanding these accelerators so they don’t need to hire people who are smart enough to build all that stuff from scratch. If the vendor and their partner ecosystem have already frozen all that expertise into the solution, the customer can be productive from day one. So, the customer could have a little bit longer to go find the appropriate smart people, wherever they happened to be, whether in
Shimmin: That’s why you look at the Rational and Jazz announcements this week and you see the reality that IBM is seeing, which is that, although we want to have this deep knowledge that’s in-house, that’s not likely to happen. You need to go where the talent is. So, the software is hopefully bridging those gaps.
Back to what you were saying earlier, Dana, about even Lotus being able to play in this, I think what’s going to become a much more predominant paradigm is that sort of telepresence for the entire life cycle of software for all involved in that.
Biske: I have a little bit different take on this. I still feel that it’s not that we need better developers, but that the technologists need to become more business aware and more business savvy.
There are a lot of businesses that may be looking offshore for a lot of these efforts, strictly from a cost reduction effort, but that doesn’t necessarily mean they’re going to get any better technical solutions than they would have with resources in-house. It just may mean that they’re going to get it less expensively, and even that is debatable.
So, they haven’t really improved things from that standpoint. In terms of business agility, they’ve reduced their cost, but is the IT solutions actually helping the business any more than it did before when all the work was being done internally? The only thing that’s really going to help push it along is to get people who are both knowledgeable about the business, as well as knowledgeable about the technology, and being able to bring those two worlds together.
Shimmin: I don’t think BPEL is the only way to do that, but that seems like that’s all vendors are focusing on right now.
Maybe we should be thinking about this as small pods or teams, where you’ve got a business person who is savvy, you’ve got a technologist who is savvy. And, then you’ve got a facilitator, a person who is very good at motivating and communicating, and create three-person pods to approach this, rather than think you’re going to get it in just one individual.
Kobielus:[[[???]]] Right, because these are all separate domains of complexity. You can be really astute on business issues, if you focus on that and you continue to refresh your understanding and the nuances of all of that day in and day out. Likewise, all the technology areas are themselves entirely stand-alone spheres of complexity. Imagine one person trying to juggle those different spheres of complexity all day, every day, and do a good job of it. That’s really hard from a wetware perspective.
Shimmin: Do you guys know the notion of extreme programming? The idea is to have these micro teams with two people who are always working on a given aspect of a project. Why not have one of them be the IT technologist and the other one be the business analyst?
Gardner: There’s an opportunity here for someone like a McKinsey to come in and start analyzing the organizational dynamics of approaching SOA, what sort of teams should be put together, and what sort of people should have certain skills. This whole notion of one person doing it seems to me as farfetched. These teams could be much more capable and much more distributed. You could push them into different activities within this problem set and they won’t necessarily have to be physically there.
Biske: Companies that have started to practice user-centered design and some formal usability practices are probably in a much better position. One thing you find in doing that is that you immediately have to get out of this customer-supplier relationship and into a team environment, as you describe, for developing solutions for business users. They’re part of the team. They’re not a customer.
Pointing to other potential groups, someone like Patricia Seybold Group, and their focus on customer innovation, some of those concepts really need to be brought in here to stop viewing IT as a supplier to the business and instead as a partner and working from a team standpoint.
You’re absolutely right that the T can be built by creating a team, rather than looking for one superstar individual that understands it all, because there aren’t too many of them.
Kobielus: My pleasure.
Biske: Thank you.
Shimmin: It’s been a pleasure everyone, thank you.
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 BriefingsDirect SOA Insights Edition, Vol. 20. 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)
