Transcript of BriefingsDirect podcast on service performance management recorded live at TUCON 2008 in San Francisco on April 30, 2008.
Listen to the podcast here. Sponsor: TIBCO Software.
Dana Gardner: Hi, this is Dana Gardner, principal analyst at Interarbor Solutions, and you’re listening to BriefingsDirect. Today, a sponsored podcast discussion about service performance management in support of service-oriented architecture (SOA).
We are here live at the TUCON 2008 conference, TIBCO Software’s user event in San Francisco, to look into the issues around SOA integrity, particularly in the context of widespread enterprise use, the myriad demands that are going to be put on services, and how infrastructure is going to need to adapt and perform in a way that probably has not been the case for infrastructure up until now.
Helping us to weed through service performance management and how it relates to SOA governance and other issues of total architecture, we are joined by a panel of industry analysts, experts and representatives from TIBCO.
Let's start by introducing our panel. We are joined by Joe McKendrick, an independent analyst and SOA blogger. Welcome to the show, Joe.
Joe McKendrick: Hi, Dana, happy to be here.
Gardner: We are also joined by Sandy Rogers, the program director for SOA, Web services and integration at IDC. Welcome, Sandy.
Sandy Rogers: Thanks, Dana.
Gardner: We are also joined by Anthony Abbattista, the vice president of enterprise technology strategy and planning for Allstate Insurance Co. Welcome to the show, Anthony.
Anthony Abbattista: It’s good to be here, Thanks.
Gardner: And also joining us, Rourke McNamara, director of product marketing for TIBCO Software. Welcome Rourke.
Rourke McNamara: Thank you, Dana.
Gardner: We saw and listened to some presentations this morning at the TIBCO conference. One of the things that struck me is this notion of pulling together what had been not only in disparate technology silos -- but really joining what had been in functional and organizational silos. Particularly, I mean the design and process creation phases that we have heard so much about with SOA.
And then how that relates to the secondary aspect of functional activities, which is the operations -- keeping the trains running on time, and making sure that service-level agreements (SLAs) are met. That means making sure that users get very fine-grained services coming through uninterrupted in aggregated applications -- without hiccups, without slowdowns.
These processes are moving to mission-critical, and so there needs to be more opportunity for these two aspects of SOA, design and operations, to work together. Performance management of services gives more insight into what takes place beneath those services, and is, therefore, becoming essential.
First, let's take a look at this landscape of what's going on in SOA, and why, as we move toward enterprise-wide deployment, service performance management becomes so important.
Sandy at IDC, what do you see in terms of enterprises that are early adopters of SOA? How concerned are they that, when they throw the switch, so to speak, with these composite business processes -- made up of services from a variety of different sources with a variety of different support infrastructure -- that they really feel confident that this is going to hold up in real world situations?
Rogers: What I find is interesting is that even if you have one service that you have deployed, you need to have as much information as possible around how it is being used and how the trending is happening regarding the up-tick in the consumption of the service across different applications, across different processes.
So, most organizations need to present an environment where individuals and stakeholders in the company feel more comfortable in relying on services and also allowing others to potentially handle the operational dynamics of those services, once they are in production.
They need a lot more visibility and an understanding of the strains that are happening on the system, and they need to really build up a level of trust. Once they can add on to the amount of individuals that have that visibility, that trust starts to develop, more reuse starts to happen, and it starts to take off.
Eventually they get to a stage, where they are concerned about the scalability and how far they can push the limits of these deployments. It could be the way that they’ve designed it architecturally, or it could be just that they are getting familiar with the new technologies to support SOA infrastructure.
Gardner: It seems that at the very time when SOA is putting more emphasis on a diversified portfolio of services -- repurposing those services, extending visibility -- that, at the same time, IT as an organization is being tasked with behaving more maturely as a business within a business.
The Information Technology Infrastructure Library (ITIL) and other compliance standards are being placed on IT departments, so they behave more like we would expect a human resources department to behave. Let's go to Joe McKendrick.
Joe, just now that we are looking at the need for IT to perform like a mature business, is there a risk here of finger-pointing -- that when something goes wrong and so many constituents are involved with the support of a service, that no one will really be able to take responsibility?
McKendrick: Yes, that’s been a problem all along. There is always a lot of finger-pointing, and IT tends to get blamed for everything. Sandy made an excellent point that the foundation of SOA is trust.
The business units are being asked to sign on to a SOA to provide support, and perhaps even some of them to provide funding, and they are looking to the services that they will consume to be scalable, looking to the services to have uptime to be available, perhaps 24x7. And if this trust is not there, the SOA, the whole foundation of the SOA, breaks down and IT will get the blame again.
It very much hinges on IT and performance management. We're actually talking about two levels here, governance and performance management. They are integrated, and they need each other. But governance deals more with how the business addresses SOA. Performance management is an IT challenge and is rightly put into the IT "sphere of influence."
Gardner: I was struck, when I heard Anthony’s presentation this morning, by your example of what things used to be like, where you would get 40 people on a conference call when something went wrong, and you would be yelling out URLs in order to find the right server to either shut down or replace.
What's the issue from your perspective now on solving this issue when things go wrong? Is this something that we can rely on people to solve, or do we need to move more toward a systems-based approach?
Abbattista: First, I'd like to wind through an earlier question you asked. When we went to SOA, when we put in our enterprise service bus (ESB), and when we chose TIBCO for our bus, a lot of people thought of SOA as, "Well, I am just going to construct some WSDL and call some SOAP or HTTP, and that’s SOA."
But the first thing we did is talk through the governance part of why we want to "get on the toll road" and "pay a toll for the bus," and really that became the consistency in measurement and governance, and lets us operate the things once we have created them.
So the first thing we had to do was get through the whole idea of that. It was worth it, and it wasn’t a matter of whether the bus would work or not. For the first year-and-a-half that we put our ESB in and we started to market services on it, we would hear the words, "TIBCO is down."
It didn’t matter whether the back-end service is down. It didn’t matter whether the mainframe was broken, they would say "TIBCO is down." We finally started to get the root cause, saying, "No, so and so service is down." The basis for us having good measurement of performance is helping to "pay the toll," of getting on the bus and actually having measurement points that are well understood.
I also don’t agree exactly that governance is a business-unit thing. Governance for us is also a lot about the SLAs around the services, of having good expectations up front about how they will behave and how they will be called. That way, we have a benchmark or baseline to compare ourselves to on this. All of sudden, if we get a 100,000 calls a day to something that is designed for, or is expected to have, 1,000 -- we at least understand what to be looking for.
Gardner: Let's provide a level-set for our listeners. You are representing Allstate, which is a very large organization, with 17 million customers, $156 billion in assets. Give us a sense of the scale that we are talking about in terms of your IT organization?
Abbattista: Our claims organization, for example, has an IT shop of about 400 people that are employees, and we are not counting offshore or other people to support that. Each of our business units is a substantial IT shop in of itself, each with 500 to 1,000 people.
Then, what we choose to federate becomes an issue, because they need to talk to each other. They need to talk to themselves. They need to talk to the outside world. So what we layer then in my area is an infrastructure of components on how to do those tasks.
The massiveness of it is how do you measure and monitor that to get end-to-end composite services that we really can monitor and supply a good customer experience from? The massiveness is amazing. We have about 5,000 servers -- UNIX, Windows, mainframes, AS400s -- we have them all at this point.
Gardner: How many services do you have that have to "pay their toll" on the service bus, so to speak?
Abbattista: About 750.
Gardner: Wow! That’s pretty good.
Abbattista: We actually front our document management services and collapse all that into Oracle, but we fronted that with TIBCO. We did that so that we would have the measurement from day one, and it’s worked amazingly well.
People argued it would be just as easy to shove the document to the database and make an HTTP-SOAP call, but this governed ESB approach has paid off a 1,000 times over, because we now predicatively know when something is going awry.
Gardner: All right, now let's go to Rourke. We understand that enterprises are hesitant about going toward SOA on a holistic basis, if they haven’t got performance backstops in place. We are a little bit weary of finger pointing, because there is such a complex stew of components and services that makes it very difficult after the fact to point out and say who is responsible.
And, we're dealing with organizations like Allstate, which have massive size and scale, with 750 services. What do people need to be considering, as we moving into to yet more complexity with virtualization, cloud computing, utility grids? Give us a little bit of level-set about what's important to consider when moving toward a solution before the fact?
McNamara: SOA, virtualization, and governance -- all of these technologies have pluses and minuses. And, on the whole, when you finish computing out the equation, you are definitely on the plus side, you are definitely on the positive side.
But, you need to make sure that, as you move from the older ways of doing things -- from the siloed applications, the siloed business unit way of doing things -- to the SOA, services-based way of doing things, you don’t ignore the new complexities you are introducing.
Don’t ignore the new problems that you are introducing. Have a strategy in place to mitigate those issues. Make sure you address that, so that you really do get the advantage, the benefits of SOA.
What I mean by that is with SOA you are reusing services. You are making services available, so that that functionality, that code, doesn’t need to be rewritten time and time again. In doing so you reduce the amount of work, you reduce the cost of building new applications, of building new functionality for your business organization.
You increase agility, because you have reduced the amount of time it takes to build new functionality for your business organization. But, in so doing, you have taken what was one large application, or three large applications, and you have broken them down into dozens or tens of separate smaller units that all need to intercommunicate, play nice with each other, and talk the same language.
Even once you have that in production, you now have a greater possibility for finger-pointing, because, if the business functionality goes down, you can’t say that that application that we just put on is down.
The big question now is what part of that application is down? Whose service is it? Your service, or someone else’s service? Is it the actual servers that support that? Is it the infrastructure that supports that? If you are using virtualization technology, is it the hardware that’s down, or is it the virtualization layer? Is it the software that runs on top of that?
You have this added complexity, and you need to make sure that doesn’t prevent you from seeing the real benefit of doing SOA.
Gardner: So after the fact of failures, in trying to do forensics and root cause analysis and putting more agents and agent-less systems in place, if it's all telling you what's wrong after the fact that it’s wrong, it’s probably too late.
McNamara: Absolutely.
Gardner: How do we get to this vision of proactive, anticipatory systems awareness via service performance management? Let me first take this to Sandy. How important is it for us to get to this sense that something isn't quite right, in advance of it failing?
Rogers: Obviously, there are different use cases and different companies that are really interested in that dynamic, autonomic type of environment, where you can adjust to the demands of the environment, but we are also becoming much more Web-based.
What we are seeing is that, as services are exposed externally to customers, partners, and other systems, it affects the ability to fail-over, to have redundant services deployed out, to be able to track the trends, and be able to plan, going forward, what needs to be supported in the infrastructure, and to even go back to issues of funding. How are you going to prove what's being used by whom to understand what's happening?
So, first, yes, it is visibility. But, from there, it has to be about receiving the information as it is happening, and to be able to adjust the behavior of the services and the behavior of the infrastructure that is supporting. It starts to become very important. There are levels of importance in criticality with different services in the infrastructure that’s supporting it right now.
But, the way that we want to move to being able to deploy anywhere and leverage virtualization technologies is to break away from the static configuration of the hardware, to the databases, to where all this is being stored now, and to have more of that dynamic resourcing. To leverage services that are deployed external to an organization you need to have more real-time communication.
Gardner: So, the proposition remains, how do you do that? It’s clear that you want to get out in front of these problems, but with so many interdependencies, the large scale in number of services, different environments, probably inside and outside the organization, it raises questions. How do we move up in abstraction toward understanding the context of an entire business process, in order to go back and look for the signals that will tell us when something is approaching a breakdown, or when we need to provision more hardware and software resources?
Let me take this to you, Anthony. Where do you think that abstraction needs to be in order to forecast appropriately issues of SOA integrity?
Abbattista: I'll go back to the point on having some expectations or benchmarks of how the service should run when it’s designed and deployed in the first place. Then, you can understand if your baseline is correct and then, over time, you can look for fragmented behavior. But, I do think you need some level of end-to-end view of the process and of who is the customer on the end.
Ultimately, where these things show up en masse is at the end-points, and typically that’s in the consumer space, as we are frustrating an employee or someone on a website with a bad client experience. Those are unforgivable.
So, starting with the customer at the end-point of that business process and looking at some of those interactions, is part and parcel of deploying the service in the first place. If you don’t do that, you will be chasing your tail for the rest of your life in operations, until you go back and do that mapping. So I think it pays to do it upfront.
Gardner: You mentioned in your presentation that the "Walls must come down" between IT operations and development-deployment-requirements-test functions. It sounds like you're also saying it needs to go from end-to-end, beyond just that wall, but also across the entire event-processing landscape.
Abbattista: In that respect, I view our function in running the applications and supplying the applications as a utility. It's our job to point back to the groups that deploy the stuff. If I let them deploy junk, I am as complicit in that junk being delivered as anybody else. That’s a responsibility we take seriously. If you're going to put it in the shop and expect us to run it, I won't take junk.
Gardner: Right. So there is the adage of, "Garbage in, garbage out." Now, if garbage appears anywhere in the context of a complex process, it's garbage out. That’s even more difficult.
Let's go to Joe McKendrick. Tell us about the concept of complex event processing (CEP). How do you get any handle on a process? Do you look for the description of the process from a modeling perspective, through what's been done on the ESB, all of the above?
McKendrick: Definitely all of the above. CEP is something that’s just coming into the SOA realm. It is said that that’s the next phase for SOA. As was pointed out this morning, real time is not enough for a business. Business needs to be able to react and predict.
Rourke and I were talking about that a little bit earlier. You need to be able to predict what's going to happen, not only in the business, but in the systems. TIBCO is making some progress in this area in terms of being able to predict when the system may go down or when there will be spikes in demand. Predictive analytics, which is a subset of business intelligence (BI), is now moving into the systems management space.
Gardner: We're actually moving above the systems management space by an abstraction level or two. Let's go back to Rourke. You had a couple of product enhancement announcements today here at the TIBCO conference. You are getting out in front of service performance management, and your interest is to accomplish some of the things we have been describing, provide what the market is demanding for SOA in order to be trusted.
Tell us about CEP and why that is an important part of this predictive solution.
McNamara: One of our customers said it best last night over dinner, when I introduced the concept of the product I am going to mention in just a second. They saw immediately what problem it solved for them.
They said that their biggest fear is that their SOA initiative will be a victim of its own success. A service will be reused so many times so rapidly that the hardware it's deployed on, the manner in which it was deployed, won't be able to handle the load. That service, which is now used in a dozen different business applications, or exposed in a dozen different business applications, will go down or will degrade in its performance level.
That could make SOA a victim of its own success. They will have successfully sold the service, had it reused over and over and over and over again. But, then, because of that reuse, because they were successful in achieving the SOA dream, they now are going to suffer. All that business users will see from that is that "SOA is bad," it makes my applications more fragile, it makes my applications slow down because so many people are using the same stuff.
Gardner: What is it about CEP that gives us more visibility at the right abstraction, so that we can predict among all of these different complex components and assets where a problem is developing?
McNamara: The key is that we just can’t simply wait for the problem to develop or the problem to happen, because it will happen very quickly. We won't have a week’s warning, a month’s warning, or even necessarily a few hours’ warning. And we won't understand, when we deploy that service, all the places or all the manners in which it will used. So, we need to be able to predict these problems before they occur and do something to prevent those problems from occurring.
TIBCO is taking our CEP technology, the business events technology that we have, and applying the problem to our internal software, our infrastructure, the same way our customers apply it to their business problems.
We are using business events to monitor what's going on with service load and performance -- what the load profiles look like in a given organization, allowing it to understand some of the programs and marketing efforts that are going on within that company. Then, when it sees that a service load is approaching a dangerous level; when it sees that based on the events that are occurring that the service will become overloaded and will violate its SLAs, it’s able to tell other parts of the infrastructure to take action to prevent that problem.
Gardner: Let me see if I understand this. This sounds like a schematic about a business process and, by reverse engineering from that process down to the constituent ingredients to support it, you can predict where the loads will be building or will become erratic. Therefore, you can also detect what's going on within that system, put the two together, and come up with a heads-up?
McNamara: That’s exactly right. You need to understand what the interdependencies are between your services and what the load characteristics of the different component parts in that dependency graph in that environment are. Then, based on that, you need to understand what sort of events in your business or in your IT infrastructure will cause performance problems or overload conditions.
Gardner: Let's go back to Sandy. You mentioned earlier about how to automate toward these goals. It sounds like it’s going to be a bit of journey to get to full automation. On the other hand, having 40 people on a conference call to try to manually bear-wrestle these problems down doesn’t work either. How do we find a balance between too much automation, automation that can’t be attained, and purely manual, after-the-fact approaches?
Rogers: Everyone has to walk before they run with any type of new technology implementation. But, we are finding that most organizations are keying in on those services that are most important, and making sure that they are instrumented appropriately regarding the technologies that support management as being able to define what those thresholds are.
Being able to correlate those thresholds to real business needs and business value -- that’s one of the interesting things about what we were doing in a service level. We can start to associate the services that are most relevant and what there are going to have the most impact for.
We can make sure that information that is contained either in the payload or form the service itself as provided. So, you have that insight. I think that organizations are starting to realize that, in order to prove the value of the services, in order to prove that the value of having this level of coordination around management, they need to be able to make that association.
From an inventing point of view, what’s interesting is that there are a lot of parallel types of processing going on in this environment. Rather than wait until something happens in some linear, straight-through process, we're seeing the ability to watch and correlate some of those events vis-à-vis the thresholds, understand which thresholds are the most important, and start automating how to define the behavior, how the system is going to react to those conditions, and do it from a cost-benefit perspective in moving forward.
Gardner: Okay, so companies can take this approach, use a moderate pace, learn as they go, and use complex event processing to offer insights into the context of what’s going on. But, if human nature is any indication, people usually react to whatever the rules are about their job, and for IT this is going to be the view from the SLAs.
It strikes me that what’s going to happen is a lot of these organizations are going to reverse-engineer from the SLA, and that the rules and the models in the SLA become extremely important. Am I going out on the limb here, Anthony, or do you think that it will pan out that the SLAs will be the rules that the service performance management then needs to line up around?
Abbattista: That’s right. Again, it's back to what do you expect, and are you living up to it? You talk about failure not being from the SOA, but we could have a case where a service got deployed, people learned about it, and, before you know it, we are taking 100,000 hits a day on a service that no body ever gave any design thought to.
I would have to reach in there and get some agent information once in a while. And all the sudden, the supplier of the service, who did us a favor, put this on the bus, and then did a point-to-point interface, calls up and says, "Help!"
Someone might publish this thing and it had no modeling, because they thought it was some low-volume thing and it wasn’t important. All of a sudden, it becomes important because everybody found it. So, as we get to composite services, SOA performance is about the service expectation.
Gardner: And the governance?
Abbattista: The governance, and do you let them do it? Do you have governors? Do you have a cost model that burdens the caller, rather than the supplier? These are real questions we'll get into, and they are why I was talking about breaking down the walls. If it's truly a valuable service, then it's my job to figure out and pay for upgrades -- or to help you redesign it.
We take very much an advocate approach to, "Okay, if you come on the bus, we will help you with being successful." And the SLA is the baseline for that. But it also sets up that, "Hey, did you do a good enough job? And what if you are wildly successful?"
Gardner: Right. Let's throw this back to TIBCO. There's clearly a need in the market for a full lifecycle approach, feedback loops, many moving parts. What is it that you can do from a product perspective that helps get to that level of automation? That, in a sense, fills in the cracks about whom and what performs some of these necessary communications between the operations side and those associated with the ongoing requirements?
McNamara: Taking a step back, TIBCO offers a single user interface from the business analyst all the way through to the operational administrators who are running our applications. The idea is that, when you sit down to build out your services, when you sit down to build out your business processes, you use one tool to define what the business processes look like, what the touch points are between folks. Then, that diagram gets handed off from the business analyst to the implementer, who sits down and actually builds the services or builds the business process management (BPM) process that meets those requirements.
There is a direct link between the two. There is a round-tripping built into that tool, largely because it's a single data model and a single user interface with different views for people with different roles in your enterprise. That’s one major thing we do to help facilitate that communication, and that’s part of what we call the TIBCO ONE initiative. The product in question is the TIBCO Business Studio product, which forms that single user interface.
Gardner: And you’ve got hooks in a lot of the other parts of the SOA infrastructure for service enablement and delivery. How do you pull these parts together in a concerted effort?
McNamara: The other side of things is, even once you’ve built things out and deployed things to production, you need to make sure you can keep track, because a number of the folks on this panel have said exactly what’s going on. Ideally, you want to identify early on, as Sandy and Anthony said, which services are important to your enterprise and which services will have heavy load.
Unfortunately, you can’t always do that. Sometimes a little service, as Anthony said, where you think it's just helpful turns out to be a service used in 60 percent of the applications you are deploying. All of a sudden, you’ve got an issue.
You need to understand what the usage characteristics are on your services, not just the designed usage characteristics on your services. We’ve embedded both policy and performance management capabilities in our underlying service infrastructure. All the TIBCO ActiveMatrix products, all of our SOA enablement products, will transparently monitor for performance and usage of the services deployed in that environment.
Anything that you build in TIBCO ActiveMatrix BusinessWorks, ActiveMatrix Service Bus, ActiveMatrix Service Grid, and so on, is automatically monitored. And, you can automatically do some things around policy and access and control and rules.
So, even if you build that little service and you don’t think it's important, and you don’t want to go to the extra trouble to build some governance into it, it's there. It's already been embedded in that infrastructure. When you need it, you can just turn it on and make use of it, and you will automatically have some information about how people are using it with a fairly nice visual dashboard?
The key here is not just the ability to see some numbers in a report, because people miss that. You can have a report on, as Anthony said, more than 750 services running. By going through the performance numbers on each of those services on a regular basis, things get lost if it's just numbers. You need to have very good visualization tool, so you can see in "living color" what's going on with those services and how that relates to the SLAs and the rules you’ve set -- the expectations you’ve set for those services.
Gardner: All right, let's go back to Allstate. Anthony you’ve heard the announcements today, you’ve understood this vision, and you understand the need very well. Do you think that we are getting very close to realizing more of an automated approach to service performance management in an SOA environment?
Abbattista: Yes, we are getting closer and making rapid strides. We need to be careful though. We are being careful to manage the service deployment, the service bus grid, and the parts about how to operate it. What makes me a little nervous or restless is the idea that we start taking all that back into the system parameters and the Java environments and Oracle databases, and that sort of thing. I would hate to see us not solve this first.
I really don’t think we’re at a stage where I want to automatically be adjusting heap sizes in Java virtual machines, or Oracle database parameters, which could be a next logical extension. I did see a little twinkle in people's eyes today, when they looked at products like the BMC Suite and Matrix. I don’t know that I want to have system programmer types around, trying to debug the debugging environment. I think it could become very complicated, very quickly.
Gardner: So we need to keep this at that higher abstraction in order to appreciate the whole and not get down into the weeds?
Abbattista: That’s my belief. I would say that if this service is not performing, then maybe we get the three people on the phone, the database administrator, the platform person, and the network person -- and we take a look at it. But I don’t think we should drill too far into that, until we solve the other layer.
Gardner: I suppose the good news and bad news about all of this is that the metrics for success or failure will be quite evident. You are not going to be able to cover this up across a service-support environment and the business processes that those contribute to, if it doesn’t work. Any failures are going to be readily apparent, not just to a systems administrator, but also to the entire organization that’s affected.
Joe, let's go to you on this whole notion of metrics of success. We have seen some caution, but we also see great promise around SOA. If we got into an economic environment where the pressure becomes higher for better productivity -- of doing more with less -- it's likely we are going to see more companies look to virtualization, outsourced services, software as a service. When do you think the switch on wider SOA use will get thrown, and to what degree does service performance management contribute to that?
McKendrick: Wow, that’s the $64-billion question. It's interesting, I was speaking with the enterprise architect for a major distribution company a little bit earlier. She pointed out to me that, when they started out their service enablement years ago, even before Web services came on the scene and evolved over the past 10 years, they built their infrastructure to be service-enabled from the get-go.
There was no effort to identify what can be service enabled and try to build a service around and try to get acceptance of it. And I asked her, "Well, what do you consider to be success in terms of adoption of the SOA, and in terms of reuse -- and do you even measure a reuse success?"
Basically, to that company, if a service gets reused, fine. If it doesn’t get reused at all, that’s fine too. It doesn’t matter. The reason I'm bringing that up is because reuse is often brought up as the ultimate metric for a SOA success, as the most tangible metric, I should say. But, I think the best approach is to design applications or pieces of applications from the initial start to be service-enabled and employing the latest standards.
Gardner: Okay, so the risks are high, the rewards are high. It sounds like we are getting closer to a less manual, more automated approach, something that has visibility and hooks up and down, deep and wide. Let's wrap up with some last thoughts on this subject.
Sandy, if you are a CIO, a decision maker in the enterprise, and you are listening to this, what do you think that you want to hear that’s going to make you confident, given that you’ve already made a lot of investments in services-enablement? You have to recognize that this is the way for the future, but what are you going to want to put in place in order to start protecting yourself when it comes to your performance management?
Rogers: What we are seeing with IT executives today is a real interest in leveraging what you have, of being able to have speed for deployment, not having to worry about all of the issues, and to have people on board that understand all of the technical dynamics of how everything needs to be implemented from an infrastructure point of view.
So, they need to be able to support fast time to market, and not worry about throwing something out there. When you are deploying it, you have to step back and make sure all of the resources that you need are lined up to make that happen. You want to have an automated way to handle deployment, to handle governance, to handle all of these different issues.
There is also the self-service nature that’s starting to happen -- the ability to create services and allow anyone in the enterprise to be able to get at the information they need as quickly as possible, not have to have a whole army of developers out there. That means you need to feel comfortable that you are creating an infrastructure that could be consumed by multiple parties.
Setting up that infrastructure is really going to save cost. It's going to save time to market, and you need that level of assurance, so that you don’t need to baby sit every single service. There is also an issue of being able to outsource to different parties. You want to be able to leverage that, cost-effectively.
You need to set up an infrastructure, all the processes and rules that everyone needs to follow. And by doing that, you can now leverage whatever resources you want to develop and create what's necessary, and not have to worry about everyone falling in line and having their own infrastructure and having all of that reference architecture put together at each different resource.
It’s really that whole concept of creating a centralized type of platform and a framework to consume all these services. It’s going to be very, very important going forward. Everyone is talking about the issues of the economy, and it’s really the trade-offs of what do you need to do in order to move forward and think about things in more of a total cost of ownership (TCO) manner versus that of direct return on investment (ROI) -- that immediate cost-per-service type of measurement.
Gardner: It sounds like we are describing what could be thought of as insurance. You’ve already gone on the journey of SOA. It’s like going on a plane ride. Are you going to spend the extra few dollars and get insurance? And wouldn't you want to do that before you get into the plane, rather than afterward? Is that how you look at this? Is service performance management insurance for SOA? I am throwing that out to Anthony at Allstate.
Abbattista: It’s interesting to think of it as insurance. I think it’s a necessary operational device, for lack of better words.
Gardner: Service performance management -- not an option?
Abbattista: I don’t think it’s an option, because what will hurt if you fall down has been proven over and over again. As the guy who has to run an SOA now that's on insurance -- it’s not an option not to do it.
Gardner: Last words from you, Rourke? Do you view this as an insurance policy? I guess you have the choice of different insurers, right?
McNamara: I do. I actually do look at service performance management as insurance -- but along the lines of medical insurance. Anthony said people fall down and people get hurt. You want to have medical insurance. It shouldn't be something that is optional. It shouldn't be something you consider optional.
It’s something that you need to have, and something that people should look at from the beginning when they go on this SOA journey. But it is insurance, Dana. That’s exactly what it does. It prevents you from running into problems. You could theoretically go down this SOA path, build out your services, deploy them, and just get lucky. Nothing will ever happen. But how many go through life without ever needing to see a doctor?
Gardner: Okay, now we are going to take some questions from the audience.
Tony Baer: This is Tony Baer with OnStrategies. I want to seize on something that Anthony Abbattista from Allstate had mentioned before, which is that you hope that service performance management doesn’t degrade into getting down to "Java heap sizes." I surely don’t blame you on that one, but what I am wondering is, at what point does this become an IT service management issue?
Abbattista: Because we have gathered that responsibility together, I guess it all falls under one roof in our particular organization. I would think it was external services. One thing we are doing is measuring some of our external providers outside the organization. I guess it’s sort of the same phone call. You are calling yourself or you are calling the person who is responsible and holding him accountable. So, I don’t know it changes much.
McNamara: I would like to add something to that. With something like a Tivoli or a BMC solution, something like a business service management technology, your operational administrators are monitoring your infrastructure.
They are monitoring the application at the application layer and they understand, based on those things, when some thing is wrong. The problem is that’s the wrong level of granularity to automatically fix problems. And it’s the wrong level of granularity to know where to point that finger, to know whom to call to resolve the problem.
It’s right, if what's wrong is a piece of your infrastructure or an entire application. But if it’s a service that’s causing the problem, you need to understand which service -- and those products and that sort of technology won’t do that for you. So, the level of granularity required is at the service level. That’s really where you need to look.
Rogers: What I find is that it’s inevitable that we are going to go down that path, but standards between the systems that do IT management traditionally and this level of detail really haven’t been fleshed out. Most organizations are looking for a single, unified type of dashboard on some of the key indicators. They might want to have that for the operations team that has traditionally run IT service management.
A lot of the initiatives around ITIL Version 3.0 are starting to get some of those teams thinking in terms of how to associate the business requirements for how services are being supported by the infrastructure, and how they are supported by the utility of the team itself. But, we're a long way away from having everything all lined up, and then having it automatically amend itself. People are very nervous about relinquishing control to an automated system.
So, it is going to be step-by-step, and the first step is getting that familiarity, getting those integrations starting to happen and then starting to let loose. What's interesting is in some of the areas of virtualization technologies, where you might have some level of management that’s abstracted from the physical infrastructure, and then you have this level of abstracted management of services how they come together. It hasn't really been defined in the industry, but down the road -- two, three, four, five years from now -- I think you will be seeing a lot more around that.
McKendrick: Let me add that we're still in the very early stages of SOA. In fact, a lot of companies out there think they have SOA, when they actually have just the bunch of Web services, JBoss architecture, and point-to-point types of interfaces and implementations. A lot of companies are just starting to get their arms around exactly what SOA is and what it isn't.
Gardner: Very good. We have been discussing the issues around service performance management for SOA environments. We are talking with a panel of industry analysts and practitioners. I want to thank our panelists, Joe McKendrick, Sandy Rogers, Anthony Abbattista, and Rourke McNamara. Thanks.
This is Dana Gardner, principal analyst at Interarbor Solutions, and you have been listening to a sponsored BriefingsDirect podcast. Thanks and come back next time.
Listen to the podcast here. Sponsor: TIBCO Software.
Transcript of BriefingsDirect podcast on service performance management recorded live at TUCON 2008 in San Francisco on April 30, 2008. Copyright Interarbor Solutions, LLC, 2005-2008. All rights reserved.
Wednesday, June 11, 2008
Thursday, June 05, 2008
Apache CXF: Where it's Been and What the Future Holds for Web Services Frameworks
Transcript of BriefingsDirect podcast on IONA Apache CXF and open-source Web services frameworks.
Listen to the 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 about Apache CXF, an open-source Web services framework that recently emerged from incubation into a full project. We are going to be discussing where CXF is, what are the next steps, how it is being used, what the market is accepting from open-source Web services and service-oriented architecture (SOA) infrastructure, and then, lastly, a road map of where CXF might be headed next.
Joining us to help us understand more about CXF, is Dan Kulp, a principal engineer who has been deeply involved with CXF for a number of years. He works at IONA Technologies. Welcome back to the show, Dan.
Dan Kulp: Thank you, it's good to be here.
Gardner: We are also joined by Raven Zachary, the open-source research director at The 451 Group. Welcome to the show, Raven.
Raven Zachary: Thank you.
Gardner: And we are joined by Benson Margulies, the CTO of Basis Technology. Welcome, Benson.
Benson Margulies: Thank you, good day.
Gardner: Let's start with you, Benson. Tell us a little bit about Basis Technology. I want to hear more about your company, because I understand you are a CXF user.
Margulies: Basis is about a 50-person company in what we call linguistic technologies. We build software components that do things like make high-quality, full-text search possible in languages such as Arabic and Chinese -- or do things like tag names and text, which is part of information retrieval.
We have customers in the commercial and government spaces and we wound up getting interested in CXF for two different reasons. One is that some of our customers have been asking us over time to provide some of our components for integration into a SOA, rather than through a direct application programming interface (API), or some sort of chewing gum and baling wire approach. So, we were looking for a friendly framework for this purpose, and CXF proved to be such.
The other reason is that, for our own internal purposes, we had developed a code generator that could read a Web-service description file WSDL and produce a client for that in JavaScript that could be loaded into a browser and tied back to a Web service. Having built it, we suddenly felt that we would like some help maintaining it. We went looking for an open-source framework to which we could contribute it, and CXF proved to be a friendly place for that too.
Over a period of time, to make a long story short, I wound up as a CXF committer. So, Basis is now both a corporate user of CXF as a delivery vehicle for our product, and also I am a committer focused on this JavaScript stuff.
Gardner: Great. You used the word "friendly" a couple of times. Let's go to Raven Zachary. Raven, why do people who go to open-source code and projects view it as friendly? What's this "friendly" business?
Zachary: Well, there are different motivations for participating in an open-source community. Generally, when you look at why businesses participate, they have a common problem among a peer set. It could be an underlying technology that they don't consider strategic. There are benefits and strength in numbers here, where companies pool together resources to work together on a common problem.
I think that for individual developers, they see it as a chance to do creative problem-solving in off hours, being involved in the team project. Maybe they want to build up their current opportunities of expertise in another area.
In the case of a CXF, it certainly has been driven heavily by IONA and its acquisition of LogicBlaze, but you had other individuals and companies involved -- Red Hat, BEA, folks from Amazon and IBM, and Benson from Basis, who is here talking about his participation. The value of this opportunity for many different commercial entities is coming together to solve a common set of problems.
Gardner: Let's go to Dan Kulp. Dan, tell us a little bit about CXF and its current iteration. You emerged from incubation not that long ago. Why don't you give our listeners, for those who are not familiar with it, a little bit of the lineage, the history of how CXF came together, and a little bit about the current state of affairs in terms of its Apache condition or position?
Kulp: CXF was basically a merger of the Celtix project that we had at ObjectWeb, which was IONA sponsored. We had lot of IONA engineers producing a framework there. There was also the XFire Project that was at Codehaus. Both of these projects were thinking about doing a 2.0 version, and there was a lot of overlap between the two. So, there was a decision between the two communities to pool the resources and produce a better 2.0 version of both XFire and Celtix
As part of that whole process of merging the communities, we decided to take it to Apache and work with the Apache communities as a well-respected open-source community.
So that's the long-term history of CXF. We spent about 20 months in the incubator at Apache. The incubator is where all the new projects come in. There are a couple of main points there, and one is the legal vetting of the code. Apache has very strong requirements about making sure all of the code is properly licensed, but is compatible with the Apache license, that the people that are contributing it to have done all of the legal requirements to make sure that the code meets those things. That's to protect the users of the Apache projects, which, from a company and user standpoint, is very important.
A lot of other projects don't do that type of legal requirement. So, there are always iffy statements around that. That was one important thing. Another very important part of the Apache incubator is building the community. One of the things they like to make sure is that any project that goes out of the incubator is in a very diverse community.
There are people representing a wide range of companies with a wide range of requirements, and the idea is to make sure that that community is long-term stable. If one company should suddenly be acquired by another company, just goes bankrupt and out of business, or whatever, the community is going to still be there in a healthy state. This is so that you can know that that the Apache project is a long-term thing not a short term.
Gardner: Could I pause there, and could you tell us who are the major contributors involved with CXF at this point?
Kulp: IONA is still heavily involved, as is Basis Technology, a couple of IBMers, as was mentioned earlier, and a couple of Red Hat people. There is one person who is now working for eBay who is contributing things, and there are a few people who I don't even know what company they work for. And that's a good thing. I don't really need to know. They have a lot of very good ideas, they are doing a lot of great work, and that's what's important about the community. It's not really that important, as long as the people are there participating.
Gardner: Okay. Things move quickly in this business. I wonder if any of our panelists recognize any shifts in the marketplace that have changed what may have been the optimum requirement set for a fully open-source Web-services framework from, say, two or three years ago, when these projects came together. What has shifted in the market? Does anyone have some thoughts on that?
Margulies: Well, Dan and Glen, who was another one of our contributors, and I, were having a lunch today and we were discussing the shift in the direction from old JAX-RPC framework to JAX-WS/JAXB, the current generation of SOA standards. That has very much become the driving factor behind the kits.
CXF gets a lot of attention, because it is a full open-source framework, which is completely committed to those standards and gives easy-to-use, relatively speaking, support for them and, as in many other areas, focuses on what the people in the outside world seem to want to use the kit for, as opposed to some particular theoretical idea than any of ours about what they ought to want to use it for.
Gardner: Thank you, Benson. Anyone else?
Kulp: Yes, one of the big things that comes to mind when this question comes up is, is the whole "code first" mentality. Several years ago, in order to do Web services, you had to know a lot of stuff about WSDL, extensible markup language (XML) schema. You had to know a lot of XMLisms. When you started talking about interop with other Web Services stacks, it was really a big deal, because these toolkits exposed all of this raw stuff to you.
Apache CXF has is a fairly different approach of making the code-first aspect a primary thing that you can think about. So, a lot of these more junior level developers can pick up and start working with Web services very quickly and very easily, without having to learn a lot of these more technical details.
Gardner: Now, SOA is a concept, a methodology, and an approach to computing, but there are a number of different infrastructure components that come together in various flexible ways, depending on the end user's concepts and direction. Tell us a little bit about how CXF fits into this, Dan, within other SOA infrastructure projects, like ServiceMix, Camel, ActiveMQ. Give us the larger SOA view, the role CXF plays in that. Then, I am going to ask you how that relates to IONA and FUSE?
Kulp: Obviously, nowadays, if you are doing any type of SOA stuff, you really need some sort of Web-service stack. There are applications written for ServiceMix and JBI that don't do any type of SOAP calls or anything like that, but those are becoming fewer and farther between. Part of what our Web services bring is the ability to go outside of your little container and talk to other services that are available, or even within your company or maybe with a business partner or something like that.
A lot of these projects, like Camel and ServiceMix, require some sort of Web-services stack, and they've basically come to CXF as a very easy-to-use and very embeddable service stack that they are using to meet their Web-services needs.
Gardner: Alright, so it fits into other Apache projects and code infrastructure bases, but as you say "plug-in-able," this probably makes it quite relevant and interesting for a lot of other users where Web-services stack is required. Can you name a couple of likely scenarios for that?
Kulp: It's actually kind of fascinating, and one of the neatest things about working in an open-source project is seeing where it pops up. Obviously, with open-source people, anybody can just kind of grab it and start using it without really telling you, "Hey, I'm using this," until suddenly they come to you one day saying, "Hey, isn't this neat?"
One of the examples of that is Groovy Web service. Groovy is another dynamic language built in Java that allows you to do dynamic things. I'm not a big Groovy user, but they actually had some requirements to be able to use Groovy to talk to some Web services, and they immediately started working with CXF.
They liked what they saw, and they hit a few bugs, which was expected, but they contributed back to CXF community. I kept getting bug reports from people, but was wondering what they were doing. It turns out that Groovy's Web-services stack is now based on CXF. That's type of thing is very fascinating from my standpoint, just to see that that type of stuff developed.
Margulies: I should point out that there has been a tendency in some of the older Web-service platforms to make the platform into a rather heavy monolithic item. There's a presumption that what you do for a living with a Web service is stand up a service on the Web in one place. One of CXF's advantages is what you want to do is deliver to some third party a stack that they put up containing your stuff that interacts with all of their existing stuff in a nice light-weight fashion. CXF is un-intrusive in that regard.
Gardner: And, just as a level-set reality check, over to Raven. Tell me a little bit about how this mix-and-match thing is working among and between the third parties, but also among and between commercial and open source, the infrastructure components.
Zachary: The whole Apache model is mix and match, when you are talking about not only a licensing scheme. The Apache license, is a little easier for commercial vendors to digest, modify, and add in, compared to the GPL, but also I think it's the inherent nature of the underlying infrastructure technologies.
When you deploy an application, especially using open source, it tends to be several dozen distinct components that are being deployed. This is especially true in Java apps, where you have a lot of components or frameworks that are bundled into an application. So, you would certainly see CXF being deployed alongside of other technologies to make that work. Things like ServiceMix or Camel, as you mentioned, ActiveMQ, Tomcat, certainly Apache Web Server, these sorts of technologies, are the instrument to which these services are exposed.
Gardner: Now, let's juxtapose this to the FUSE set. This is a commercially supported, certified, and tested SOA and Web-services component set. The FUSE services framework is derived from CXF. Dan, tell us a little bit about what is going on with FUSE and how has that now benefited from CXF moving from incubation into full Apache?
Kulp: As you mentioned, the FUSE services framework is basically a re-branded version of Apache CXF. If you go into a lot of these big customers, like banks or any of the major type of customers, and they deploy an application, they want to have some level of support agreement with somebody that says if a bug is found or a problem crops up, can they get somebody on the phone and get a bug fixed relatively quickly.
That's what the FUSE product line is basically all about. It's all open-source, and anybody can download and use the stuff, but you may not get the same level of support from the Apache community, as you do with the FUSE product.
The Apache communities are pretty much all volunteer-type people. Pretty much everybody is working on whatever their own agenda is, but they have their own expertise. So, they may not even have time, and they may be out on leave or on vacation or something like that. Getting the commercial-level of support from the Apache community can sometimes be a hard sell for a lot of these corporations, and that's why what FUSE really brings is a support agreement. You know that there is somebody there to call when there is a problem.
It's a two-way relationship. Obviously, if any of those customers come back with bugs and stuff, the IONA people will fix them and get them pushed into both Apache and FUSE. So, the bugs and stuff get fixed, but the other thing that IONA gets from this is that there's a lot of ideas in the Apache communities that we may not have thought of ourselves.
One good example of this is that JavaScript thing that Benson mentioned earlier. That's not something IONA really would have thought of at the beginning, but this is something that we can give back to our customers saying, "Hey, isn't this a neat idea?" So, there are a lot of benefits coming from the other people that aren't IONA in these communities actually providing new features and new ideas for the IONA customers.
Gardner: Okay, you came off incubation in April, is that correct?
Kulp: Yes.
Gardner: Tell us about what's going on now. What's the next step, now that it's out of that. Is this sort of a maintenance period, and when will we start to think about seeing additional requirements and functionality coming in?
Kulp: There are two parts to that question. Raven and I graduated, and we were ready to push out 2.1. Apache CXF 2.1 was released about a week after we graduated, and it brought forth a whole bunch of new functionality. The JavaScript was one of them. A whole new tooling was another thing, also CORBA binding, and there is a whole bunch of new stuff, some REST-based APIs. So, 2.1 was a major step forward, compared to the 2.0 version that was ready last August, I believe.
Right now, there are basically two tracks of stuff going on. There are obviously a lot of bug fixes. One of the things about graduating is that there are a lot of people who don't really understand what the incubator is about, and so they weren't looking in the incubator.
The incubator has nothing to do with the quality of the code. It has more to do with the state of the community, but people see the word "incubator" and just say, "No, I'm not going to touch that." But, now that they we're graduated, there are a lot more people looking at it, which is good. We're getting a lot more input from users. There are a lot of people submitting other ideas. So, there is a certain track of people just trying to get some bug fixes and getting some support in place for those other people.
Gardner: I am impressed that you say "bug fixes" and not "refinement." That's very upfront of you.
Kulp: Well, a lot of it is refinement too, and, to be honest, there is a bit of documentation refinement that is going on as well, because with new people using it, there are new expectations. Their old toolkits may have done things one way, and the documentation may not reflect well enough, "Okay, if you did it this way in the old toolkit, this is how you do the same thing in CXF."
Margulies: If I could pipe up with a sociological issue here with open source which says, it's a lot easier to motivate someone to run in and diagnose a defect or a missing feature in the code and make the fix than to get the additional motivation to go over to the "doc" side and think through, "How the heck are we going to explain this, and who needs to have it explained to them." We're really lucky, in fact. We have at least one person in the community who almost entirely focuses on improving the doc as opposed to the code.
Gardner: Okay. So, we're into this maturity move. We've got a lot more people poking at it and using it. We're going to benefit from that community involvement. We've mentioned a couple of things that struck me a little earlier -- the Groovy experience and JavaScript. I guess there's this perception by many whom I've talked to that Web services is interesting, but there's a certain interest level too in moving into more dynamic languages, the use of RESTful for getting out to clients, and thinking about Web services in a broader context.
So, first let's go to Benson. Tell us why this JavaScript element was important to you and where you think the kind of mindset is in the field around Web services and traditional Web services-star specifications and standards?
Margulies: We went here originally, because while we built these components to go into the middle of things, we have to show them off to people, who just want to see the naked functionality. So, we built a certain amount of demo functionality as Web applications, with things from Web pages. And, the whole staff was saying, "Oh gosh, first we have to write a JSP page, and then we have to write some Beans, and then we have to package it all up, and then we have to deploy it."
It got really tiresome. So we went looking for a much thinner technology for taking our core functionality and making it visible. It dawned on us that perhaps you could just call a Web service from a browser.
Historically, there's been such a mentality in the broad community because you "couldn't possibly do that." "Those Web service, XML messages, they are so complicated." "Oh, we could never do that." And, several of the dynamic languages, SOAP, or Web-service kits that have shown up from time to time in the community were really weak. They barely worked, because they're very old versions of the Web-service universe. As Web-service standards have moved into stronger XML, they got left behind.
So, not knowing any better, we went ahead and built a code generator for JavaScript that could actually talk to a JAX-WS Web service, and I think that's an important direction for things to go. REST is a great thing. It allows very simple clients to get some data in and out of Web services, but, people are building really big complicated applications and dynamic languages these days, things like Ruby. For Web services to succeed in that environment, we need more of what we just did with the JavaScript. We need first class citizenship for dynamic languages as clients and even servers of Web services.
Gardner: Let's take it over to Raven. Tell us, from the analyst perspective, what you see going on mentality wise and mindshare wise with Web-services specs, and do you think that there's a sort of "match made in heaven" here between something like CXF and some of these dynamic languages?
Zachary: Well, looking back on the history of CXF being the merging of two initiatives -- Celtix from IONA and XFire from Codehaus -- and spending last few years in the incubator, and now coming out of the incubator in April, bringing together those two initiatives is very telling in terms of the stronger initiative, based on the basis of two existing open-source initiatives.
I like the fact that in CXF they are looking at a variety of protocols. It's not just one implementation of Web services. There's SOAP, REST, CORBA, other technologies, and then a number of transports, not just HTTP. The fact is that when you talk to enterprises, there's not a one-size-fits-all implementation for Web services. You need to really look at services, exposing them through a variety of technologies.
I like that approach. It really matches the needs of a larger variety of enterprise organizations and just it's a specific technology implementation of Web services. I mean, that's the approach that you're going to see from open-source projects in the space. The ones that provide the greatest diversity of protocols and transports are going to do quite well.
Gardner: Dan, you've probably heard this. Some of the folks who are doing more development with dynamic languages and who are trying to move toward light-weight webby applications have kind of an attitude going on with Web-services specs. Have you noticed that and what do you think is up with that? Has that perhaps prevented some of them from looking at CXF in evaluating it?
Kulp: Yeah, in a way, it has prevented them, but Web Services are pretty much everywhere now. So, even though they may not really agree with some of Web-service ideas, for their own user base to be able to grow, they have to start thinking about how do we solve that problem, because the fact is that they are there.
Now, going forward, REST is obviously a big word. So, whatever toolkit you're looking at you need to be able to talk REST as well, and CXF is doing a little bit there. If you go back, there's CORBA stuff that needs to be talked to. With CXF, you don't just get the SOAP part of SOA, you get some of these additional technologies that can help you solve a wider range of problems. That's very important to certain people, especially if you're trying to grow a user base.
Gardner: Alright, so you've obviously benefited, the community has benefited from Benson and Basis Technology offering in what they did with JavaScript. I assume you'll be interested in committers to further that across more languages and more technologies?
Kulp: Oh, definitely. One of the nicest things about working in Apache projects is that it's an ongoing effort to try to keep the community growing and getting new ideas. As you get more people in, they have different viewpoints, different experiences, and all that can contribute to producing new ideas and new technologies, and making it easier to solve a different set of problems.
I always encourage people that, if they're looking in the CXF code, and they hit a bug, it's great if we see them submit a patch for that, because that shows that they're actually digging in there. Eventually, they may say, "Okay, I kind of like how you did that, but wouldn't it be neat if you could just do this?" And then maybe they submit some ideas around that and become a committer. It's always a great thing to see that go forward.
Gardner: Let's go around the table one last time and try to predict the future when it comes to open-source Apache projects, this webby application environment, and the larger undertaking of SOA. Dan, any prophecies about what we might expect in the CXF community over, say, the next 12 months?
Kulp: Obviously, there's going to be this ongoing track of refinements and fixes. One of nice things of the CXF community is that we're very committed to supporting our existing users and making sure that any bug fixes or bugs that they encounter get fixed in a relatively timely manner. CFX has a very good history of doing very frequent patch releases to get fixes out there. So, that's an ongoing thing that should remain in place and it's a benefit to the communities and to the users.
Beyond that, there's a whole bunch of other ideas that we're working on and fleshing out. The code first stuff that I mentioned earlier, we have a bunch of other ideas about how to make code-first even better.
There are certain tool kits that you kind of have to delve down into either configuration or WSDL documents to accomplish what you want. It would be nice if you could just embed some annotations on your code, or something like that, to accomplish some of that stuff. We're going to be moving some of those ideas forward.
There's also a whole bunch of Web-services standards such as WS-I and WS-SecureConversation that we don't support today, but we are going to be working on to make sure that they are supported. As customers or users start demanding other WS technologies, we'll start considering them, as well. Obviously, if new people come along, they'll have other great ideas, and we would welcome those as well.
Gardner: Alright. Raven Zachary, what do you see as some of the trends that we should expect in Open Source infrastructure particularly around SOA and Web services interoperability over, say, the next 12 months?
Zachary: We've had for the last decade or so a number of very successful open-source infrastructure initiatives. Certainly, Apache Web Server Linux as an operating system and the application middleware stack -- Tomcat, Geronimo, JBoss -- have done very well. Open source has been a great opportunity for these technologies to advance, and we're still going to see commercial innovation in the space. But, I think the majority of the software infrastructure will be based on open standards and open source over time and then you'll see commercialization occur around the services side for that.
We're just starting to see the emergence of open-source Web services to a large extent and I think you're going to see projects coming out of the Apache Software Foundation leading that charge as other areas of the software infrastructure have been filled out.
When you look at growth opportunities, back in 2001, JBoss app server was a single-digit market share, compared to the leading technologies at the time, WebSphere from IBM and WebLogic from BEA. In the course of four years, that technology went from single-digit market share to actually being the number one deployed Java app server in the market. I think it doesn't take much time for a technology like CXF to capture the market opportunity.
So, watch this space. I think this technology and other technologies like it, have a very bright future.
Gardner: I was impressed and I wrote a blog recently about this emerging from incubation. I got some really high numbers, which indicated some significant interest.
Last, I am going to Benson at Basis Technology as a user and a committer. How do you expect that you'll be using something like CXF in your implementations over the next 12 months?
Margulies: Well, we're looking at a particular problem, which is coming up with a high-performance Web-service interface to some of our functions, where you put a document and you get some results out. That's quite challenging, because documents are sort of heavyweight, large objects, and the toolkits have not been wildly helpful on this.
So, I've scratched some of the necessary services on CXF and I expect to be digging deeper. The other thing I put in as a comment as a committer is that one of the most important things we're going to see is a user support community.
Long before you get to the point where someone is a possible committer on the program, there is the fact that the users help each other in using the product and using the package, and that's a critical success factor. That community of people who read the mailing list just pitch in and help those newbies find their way from one end to the other.
Gardner: Well, great. Thank you so much. I think we've caught up with CXF, and have quite a bit to look forward to over the coming quarters and months. I want to thank our panel. We've been joined by Dan Kulp, principal engineer at IONA Technologies; Raven Zachary, open source research director for The 451 Group; and Benson Margulies, the CTO at Basis Technology. Thank, everyone.
Kulp: You're very welcome.
Zachary: Thank you.
Margulies: Thank you.
Gardner: This is Dana Gardner, principal analyst at Interarbor Solutions. You have been listening to a sponsored BriefingsDirect Podcast on Apache CXF. Thanks and come back next time.
Listen to the podcast. Sponsor: IONA Technologies.
Transcript of BriefingsDirect podcast on IONA Apache CXF and open-source frameworks. Copyright Interarbor Solutions, LLC, 2005-2008. All rights reserved.
Listen to the 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 about Apache CXF, an open-source Web services framework that recently emerged from incubation into a full project. We are going to be discussing where CXF is, what are the next steps, how it is being used, what the market is accepting from open-source Web services and service-oriented architecture (SOA) infrastructure, and then, lastly, a road map of where CXF might be headed next.
Joining us to help us understand more about CXF, is Dan Kulp, a principal engineer who has been deeply involved with CXF for a number of years. He works at IONA Technologies. Welcome back to the show, Dan.
Dan Kulp: Thank you, it's good to be here.
Gardner: We are also joined by Raven Zachary, the open-source research director at The 451 Group. Welcome to the show, Raven.
Raven Zachary: Thank you.
Gardner: And we are joined by Benson Margulies, the CTO of Basis Technology. Welcome, Benson.
Benson Margulies: Thank you, good day.
Gardner: Let's start with you, Benson. Tell us a little bit about Basis Technology. I want to hear more about your company, because I understand you are a CXF user.
Margulies: Basis is about a 50-person company in what we call linguistic technologies. We build software components that do things like make high-quality, full-text search possible in languages such as Arabic and Chinese -- or do things like tag names and text, which is part of information retrieval.
We have customers in the commercial and government spaces and we wound up getting interested in CXF for two different reasons. One is that some of our customers have been asking us over time to provide some of our components for integration into a SOA, rather than through a direct application programming interface (API), or some sort of chewing gum and baling wire approach. So, we were looking for a friendly framework for this purpose, and CXF proved to be such.
The other reason is that, for our own internal purposes, we had developed a code generator that could read a Web-service description file WSDL and produce a client for that in JavaScript that could be loaded into a browser and tied back to a Web service. Having built it, we suddenly felt that we would like some help maintaining it. We went looking for an open-source framework to which we could contribute it, and CXF proved to be a friendly place for that too.
Over a period of time, to make a long story short, I wound up as a CXF committer. So, Basis is now both a corporate user of CXF as a delivery vehicle for our product, and also I am a committer focused on this JavaScript stuff.
Gardner: Great. You used the word "friendly" a couple of times. Let's go to Raven Zachary. Raven, why do people who go to open-source code and projects view it as friendly? What's this "friendly" business?
Zachary: Well, there are different motivations for participating in an open-source community. Generally, when you look at why businesses participate, they have a common problem among a peer set. It could be an underlying technology that they don't consider strategic. There are benefits and strength in numbers here, where companies pool together resources to work together on a common problem.
I think that for individual developers, they see it as a chance to do creative problem-solving in off hours, being involved in the team project. Maybe they want to build up their current opportunities of expertise in another area.
In the case of a CXF, it certainly has been driven heavily by IONA and its acquisition of LogicBlaze, but you had other individuals and companies involved -- Red Hat, BEA, folks from Amazon and IBM, and Benson from Basis, who is here talking about his participation. The value of this opportunity for many different commercial entities is coming together to solve a common set of problems.
Gardner: Let's go to Dan Kulp. Dan, tell us a little bit about CXF and its current iteration. You emerged from incubation not that long ago. Why don't you give our listeners, for those who are not familiar with it, a little bit of the lineage, the history of how CXF came together, and a little bit about the current state of affairs in terms of its Apache condition or position?
Kulp: CXF was basically a merger of the Celtix project that we had at ObjectWeb, which was IONA sponsored. We had lot of IONA engineers producing a framework there. There was also the XFire Project that was at Codehaus. Both of these projects were thinking about doing a 2.0 version, and there was a lot of overlap between the two. So, there was a decision between the two communities to pool the resources and produce a better 2.0 version of both XFire and Celtix
As part of that whole process of merging the communities, we decided to take it to Apache and work with the Apache communities as a well-respected open-source community.
So that's the long-term history of CXF. We spent about 20 months in the incubator at Apache. The incubator is where all the new projects come in. There are a couple of main points there, and one is the legal vetting of the code. Apache has very strong requirements about making sure all of the code is properly licensed, but is compatible with the Apache license, that the people that are contributing it to have done all of the legal requirements to make sure that the code meets those things. That's to protect the users of the Apache projects, which, from a company and user standpoint, is very important.
A lot of other projects don't do that type of legal requirement. So, there are always iffy statements around that. That was one important thing. Another very important part of the Apache incubator is building the community. One of the things they like to make sure is that any project that goes out of the incubator is in a very diverse community.
There are people representing a wide range of companies with a wide range of requirements, and the idea is to make sure that that community is long-term stable. If one company should suddenly be acquired by another company, just goes bankrupt and out of business, or whatever, the community is going to still be there in a healthy state. This is so that you can know that that the Apache project is a long-term thing not a short term.
Gardner: Could I pause there, and could you tell us who are the major contributors involved with CXF at this point?
Kulp: IONA is still heavily involved, as is Basis Technology, a couple of IBMers, as was mentioned earlier, and a couple of Red Hat people. There is one person who is now working for eBay who is contributing things, and there are a few people who I don't even know what company they work for. And that's a good thing. I don't really need to know. They have a lot of very good ideas, they are doing a lot of great work, and that's what's important about the community. It's not really that important, as long as the people are there participating.
Gardner: Okay. Things move quickly in this business. I wonder if any of our panelists recognize any shifts in the marketplace that have changed what may have been the optimum requirement set for a fully open-source Web-services framework from, say, two or three years ago, when these projects came together. What has shifted in the market? Does anyone have some thoughts on that?
Margulies: Well, Dan and Glen, who was another one of our contributors, and I, were having a lunch today and we were discussing the shift in the direction from old JAX-RPC framework to JAX-WS/JAXB, the current generation of SOA standards. That has very much become the driving factor behind the kits.
CXF gets a lot of attention, because it is a full open-source framework, which is completely committed to those standards and gives easy-to-use, relatively speaking, support for them and, as in many other areas, focuses on what the people in the outside world seem to want to use the kit for, as opposed to some particular theoretical idea than any of ours about what they ought to want to use it for.
Gardner: Thank you, Benson. Anyone else?
Kulp: Yes, one of the big things that comes to mind when this question comes up is, is the whole "code first" mentality. Several years ago, in order to do Web services, you had to know a lot of stuff about WSDL, extensible markup language (XML) schema. You had to know a lot of XMLisms. When you started talking about interop with other Web Services stacks, it was really a big deal, because these toolkits exposed all of this raw stuff to you.
Apache CXF has is a fairly different approach of making the code-first aspect a primary thing that you can think about. So, a lot of these more junior level developers can pick up and start working with Web services very quickly and very easily, without having to learn a lot of these more technical details.
Gardner: Now, SOA is a concept, a methodology, and an approach to computing, but there are a number of different infrastructure components that come together in various flexible ways, depending on the end user's concepts and direction. Tell us a little bit about how CXF fits into this, Dan, within other SOA infrastructure projects, like ServiceMix, Camel, ActiveMQ. Give us the larger SOA view, the role CXF plays in that. Then, I am going to ask you how that relates to IONA and FUSE?
Kulp: Obviously, nowadays, if you are doing any type of SOA stuff, you really need some sort of Web-service stack. There are applications written for ServiceMix and JBI that don't do any type of SOAP calls or anything like that, but those are becoming fewer and farther between. Part of what our Web services bring is the ability to go outside of your little container and talk to other services that are available, or even within your company or maybe with a business partner or something like that.
A lot of these projects, like Camel and ServiceMix, require some sort of Web-services stack, and they've basically come to CXF as a very easy-to-use and very embeddable service stack that they are using to meet their Web-services needs.
Gardner: Alright, so it fits into other Apache projects and code infrastructure bases, but as you say "plug-in-able," this probably makes it quite relevant and interesting for a lot of other users where Web-services stack is required. Can you name a couple of likely scenarios for that?
Kulp: It's actually kind of fascinating, and one of the neatest things about working in an open-source project is seeing where it pops up. Obviously, with open-source people, anybody can just kind of grab it and start using it without really telling you, "Hey, I'm using this," until suddenly they come to you one day saying, "Hey, isn't this neat?"
One of the examples of that is Groovy Web service. Groovy is another dynamic language built in Java that allows you to do dynamic things. I'm not a big Groovy user, but they actually had some requirements to be able to use Groovy to talk to some Web services, and they immediately started working with CXF.
They liked what they saw, and they hit a few bugs, which was expected, but they contributed back to CXF community. I kept getting bug reports from people, but was wondering what they were doing. It turns out that Groovy's Web-services stack is now based on CXF. That's type of thing is very fascinating from my standpoint, just to see that that type of stuff developed.
Margulies: I should point out that there has been a tendency in some of the older Web-service platforms to make the platform into a rather heavy monolithic item. There's a presumption that what you do for a living with a Web service is stand up a service on the Web in one place. One of CXF's advantages is what you want to do is deliver to some third party a stack that they put up containing your stuff that interacts with all of their existing stuff in a nice light-weight fashion. CXF is un-intrusive in that regard.
Gardner: And, just as a level-set reality check, over to Raven. Tell me a little bit about how this mix-and-match thing is working among and between the third parties, but also among and between commercial and open source, the infrastructure components.
Zachary: The whole Apache model is mix and match, when you are talking about not only a licensing scheme. The Apache license, is a little easier for commercial vendors to digest, modify, and add in, compared to the GPL, but also I think it's the inherent nature of the underlying infrastructure technologies.
When you deploy an application, especially using open source, it tends to be several dozen distinct components that are being deployed. This is especially true in Java apps, where you have a lot of components or frameworks that are bundled into an application. So, you would certainly see CXF being deployed alongside of other technologies to make that work. Things like ServiceMix or Camel, as you mentioned, ActiveMQ, Tomcat, certainly Apache Web Server, these sorts of technologies, are the instrument to which these services are exposed.
Gardner: Now, let's juxtapose this to the FUSE set. This is a commercially supported, certified, and tested SOA and Web-services component set. The FUSE services framework is derived from CXF. Dan, tell us a little bit about what is going on with FUSE and how has that now benefited from CXF moving from incubation into full Apache?
Kulp: As you mentioned, the FUSE services framework is basically a re-branded version of Apache CXF. If you go into a lot of these big customers, like banks or any of the major type of customers, and they deploy an application, they want to have some level of support agreement with somebody that says if a bug is found or a problem crops up, can they get somebody on the phone and get a bug fixed relatively quickly.
That's what the FUSE product line is basically all about. It's all open-source, and anybody can download and use the stuff, but you may not get the same level of support from the Apache community, as you do with the FUSE product.
The Apache communities are pretty much all volunteer-type people. Pretty much everybody is working on whatever their own agenda is, but they have their own expertise. So, they may not even have time, and they may be out on leave or on vacation or something like that. Getting the commercial-level of support from the Apache community can sometimes be a hard sell for a lot of these corporations, and that's why what FUSE really brings is a support agreement. You know that there is somebody there to call when there is a problem.
It's a two-way relationship. Obviously, if any of those customers come back with bugs and stuff, the IONA people will fix them and get them pushed into both Apache and FUSE. So, the bugs and stuff get fixed, but the other thing that IONA gets from this is that there's a lot of ideas in the Apache communities that we may not have thought of ourselves.
One good example of this is that JavaScript thing that Benson mentioned earlier. That's not something IONA really would have thought of at the beginning, but this is something that we can give back to our customers saying, "Hey, isn't this a neat idea?" So, there are a lot of benefits coming from the other people that aren't IONA in these communities actually providing new features and new ideas for the IONA customers.
Gardner: Okay, you came off incubation in April, is that correct?
Kulp: Yes.
Gardner: Tell us about what's going on now. What's the next step, now that it's out of that. Is this sort of a maintenance period, and when will we start to think about seeing additional requirements and functionality coming in?
Kulp: There are two parts to that question. Raven and I graduated, and we were ready to push out 2.1. Apache CXF 2.1 was released about a week after we graduated, and it brought forth a whole bunch of new functionality. The JavaScript was one of them. A whole new tooling was another thing, also CORBA binding, and there is a whole bunch of new stuff, some REST-based APIs. So, 2.1 was a major step forward, compared to the 2.0 version that was ready last August, I believe.
Right now, there are basically two tracks of stuff going on. There are obviously a lot of bug fixes. One of the things about graduating is that there are a lot of people who don't really understand what the incubator is about, and so they weren't looking in the incubator.
The incubator has nothing to do with the quality of the code. It has more to do with the state of the community, but people see the word "incubator" and just say, "No, I'm not going to touch that." But, now that they we're graduated, there are a lot more people looking at it, which is good. We're getting a lot more input from users. There are a lot of people submitting other ideas. So, there is a certain track of people just trying to get some bug fixes and getting some support in place for those other people.
Gardner: I am impressed that you say "bug fixes" and not "refinement." That's very upfront of you.
Kulp: Well, a lot of it is refinement too, and, to be honest, there is a bit of documentation refinement that is going on as well, because with new people using it, there are new expectations. Their old toolkits may have done things one way, and the documentation may not reflect well enough, "Okay, if you did it this way in the old toolkit, this is how you do the same thing in CXF."
Margulies: If I could pipe up with a sociological issue here with open source which says, it's a lot easier to motivate someone to run in and diagnose a defect or a missing feature in the code and make the fix than to get the additional motivation to go over to the "doc" side and think through, "How the heck are we going to explain this, and who needs to have it explained to them." We're really lucky, in fact. We have at least one person in the community who almost entirely focuses on improving the doc as opposed to the code.
Gardner: Okay. So, we're into this maturity move. We've got a lot more people poking at it and using it. We're going to benefit from that community involvement. We've mentioned a couple of things that struck me a little earlier -- the Groovy experience and JavaScript. I guess there's this perception by many whom I've talked to that Web services is interesting, but there's a certain interest level too in moving into more dynamic languages, the use of RESTful for getting out to clients, and thinking about Web services in a broader context.
So, first let's go to Benson. Tell us why this JavaScript element was important to you and where you think the kind of mindset is in the field around Web services and traditional Web services-star specifications and standards?
Margulies: We went here originally, because while we built these components to go into the middle of things, we have to show them off to people, who just want to see the naked functionality. So, we built a certain amount of demo functionality as Web applications, with things from Web pages. And, the whole staff was saying, "Oh gosh, first we have to write a JSP page, and then we have to write some Beans, and then we have to package it all up, and then we have to deploy it."
It got really tiresome. So we went looking for a much thinner technology for taking our core functionality and making it visible. It dawned on us that perhaps you could just call a Web service from a browser.
Historically, there's been such a mentality in the broad community because you "couldn't possibly do that." "Those Web service, XML messages, they are so complicated." "Oh, we could never do that." And, several of the dynamic languages, SOAP, or Web-service kits that have shown up from time to time in the community were really weak. They barely worked, because they're very old versions of the Web-service universe. As Web-service standards have moved into stronger XML, they got left behind.
So, not knowing any better, we went ahead and built a code generator for JavaScript that could actually talk to a JAX-WS Web service, and I think that's an important direction for things to go. REST is a great thing. It allows very simple clients to get some data in and out of Web services, but, people are building really big complicated applications and dynamic languages these days, things like Ruby. For Web services to succeed in that environment, we need more of what we just did with the JavaScript. We need first class citizenship for dynamic languages as clients and even servers of Web services.
Gardner: Let's take it over to Raven. Tell us, from the analyst perspective, what you see going on mentality wise and mindshare wise with Web-services specs, and do you think that there's a sort of "match made in heaven" here between something like CXF and some of these dynamic languages?
Zachary: Well, looking back on the history of CXF being the merging of two initiatives -- Celtix from IONA and XFire from Codehaus -- and spending last few years in the incubator, and now coming out of the incubator in April, bringing together those two initiatives is very telling in terms of the stronger initiative, based on the basis of two existing open-source initiatives.
I like the fact that in CXF they are looking at a variety of protocols. It's not just one implementation of Web services. There's SOAP, REST, CORBA, other technologies, and then a number of transports, not just HTTP. The fact is that when you talk to enterprises, there's not a one-size-fits-all implementation for Web services. You need to really look at services, exposing them through a variety of technologies.
I like that approach. It really matches the needs of a larger variety of enterprise organizations and just it's a specific technology implementation of Web services. I mean, that's the approach that you're going to see from open-source projects in the space. The ones that provide the greatest diversity of protocols and transports are going to do quite well.
Gardner: Dan, you've probably heard this. Some of the folks who are doing more development with dynamic languages and who are trying to move toward light-weight webby applications have kind of an attitude going on with Web-services specs. Have you noticed that and what do you think is up with that? Has that perhaps prevented some of them from looking at CXF in evaluating it?
Kulp: Yeah, in a way, it has prevented them, but Web Services are pretty much everywhere now. So, even though they may not really agree with some of Web-service ideas, for their own user base to be able to grow, they have to start thinking about how do we solve that problem, because the fact is that they are there.
Now, going forward, REST is obviously a big word. So, whatever toolkit you're looking at you need to be able to talk REST as well, and CXF is doing a little bit there. If you go back, there's CORBA stuff that needs to be talked to. With CXF, you don't just get the SOAP part of SOA, you get some of these additional technologies that can help you solve a wider range of problems. That's very important to certain people, especially if you're trying to grow a user base.
Gardner: Alright, so you've obviously benefited, the community has benefited from Benson and Basis Technology offering in what they did with JavaScript. I assume you'll be interested in committers to further that across more languages and more technologies?
Kulp: Oh, definitely. One of the nicest things about working in Apache projects is that it's an ongoing effort to try to keep the community growing and getting new ideas. As you get more people in, they have different viewpoints, different experiences, and all that can contribute to producing new ideas and new technologies, and making it easier to solve a different set of problems.
I always encourage people that, if they're looking in the CXF code, and they hit a bug, it's great if we see them submit a patch for that, because that shows that they're actually digging in there. Eventually, they may say, "Okay, I kind of like how you did that, but wouldn't it be neat if you could just do this?" And then maybe they submit some ideas around that and become a committer. It's always a great thing to see that go forward.
Gardner: Let's go around the table one last time and try to predict the future when it comes to open-source Apache projects, this webby application environment, and the larger undertaking of SOA. Dan, any prophecies about what we might expect in the CXF community over, say, the next 12 months?
Kulp: Obviously, there's going to be this ongoing track of refinements and fixes. One of nice things of the CXF community is that we're very committed to supporting our existing users and making sure that any bug fixes or bugs that they encounter get fixed in a relatively timely manner. CFX has a very good history of doing very frequent patch releases to get fixes out there. So, that's an ongoing thing that should remain in place and it's a benefit to the communities and to the users.
Beyond that, there's a whole bunch of other ideas that we're working on and fleshing out. The code first stuff that I mentioned earlier, we have a bunch of other ideas about how to make code-first even better.
There are certain tool kits that you kind of have to delve down into either configuration or WSDL documents to accomplish what you want. It would be nice if you could just embed some annotations on your code, or something like that, to accomplish some of that stuff. We're going to be moving some of those ideas forward.
There's also a whole bunch of Web-services standards such as WS-I and WS-SecureConversation that we don't support today, but we are going to be working on to make sure that they are supported. As customers or users start demanding other WS technologies, we'll start considering them, as well. Obviously, if new people come along, they'll have other great ideas, and we would welcome those as well.
Gardner: Alright. Raven Zachary, what do you see as some of the trends that we should expect in Open Source infrastructure particularly around SOA and Web services interoperability over, say, the next 12 months?
Zachary: We've had for the last decade or so a number of very successful open-source infrastructure initiatives. Certainly, Apache Web Server Linux as an operating system and the application middleware stack -- Tomcat, Geronimo, JBoss -- have done very well. Open source has been a great opportunity for these technologies to advance, and we're still going to see commercial innovation in the space. But, I think the majority of the software infrastructure will be based on open standards and open source over time and then you'll see commercialization occur around the services side for that.
We're just starting to see the emergence of open-source Web services to a large extent and I think you're going to see projects coming out of the Apache Software Foundation leading that charge as other areas of the software infrastructure have been filled out.
When you look at growth opportunities, back in 2001, JBoss app server was a single-digit market share, compared to the leading technologies at the time, WebSphere from IBM and WebLogic from BEA. In the course of four years, that technology went from single-digit market share to actually being the number one deployed Java app server in the market. I think it doesn't take much time for a technology like CXF to capture the market opportunity.
So, watch this space. I think this technology and other technologies like it, have a very bright future.
Gardner: I was impressed and I wrote a blog recently about this emerging from incubation. I got some really high numbers, which indicated some significant interest.
Last, I am going to Benson at Basis Technology as a user and a committer. How do you expect that you'll be using something like CXF in your implementations over the next 12 months?
Margulies: Well, we're looking at a particular problem, which is coming up with a high-performance Web-service interface to some of our functions, where you put a document and you get some results out. That's quite challenging, because documents are sort of heavyweight, large objects, and the toolkits have not been wildly helpful on this.
So, I've scratched some of the necessary services on CXF and I expect to be digging deeper. The other thing I put in as a comment as a committer is that one of the most important things we're going to see is a user support community.
Long before you get to the point where someone is a possible committer on the program, there is the fact that the users help each other in using the product and using the package, and that's a critical success factor. That community of people who read the mailing list just pitch in and help those newbies find their way from one end to the other.
Gardner: Well, great. Thank you so much. I think we've caught up with CXF, and have quite a bit to look forward to over the coming quarters and months. I want to thank our panel. We've been joined by Dan Kulp, principal engineer at IONA Technologies; Raven Zachary, open source research director for The 451 Group; and Benson Margulies, the CTO at Basis Technology. Thank, everyone.
Kulp: You're very welcome.
Zachary: Thank you.
Margulies: Thank you.
Gardner: This is Dana Gardner, principal analyst at Interarbor Solutions. You have been listening to a sponsored BriefingsDirect Podcast on Apache CXF. Thanks and come back next time.
Listen to the podcast. Sponsor: IONA Technologies.
Transcript of BriefingsDirect podcast on IONA Apache CXF and open-source frameworks. Copyright Interarbor Solutions, LLC, 2005-2008. All rights reserved.
Thursday, May 15, 2008
BriefingsDirect Insights analysts probe future of online advertising and find transactional lucre lurking
Edited transcript of periodic BriefingsDirect Analyst Insights Edition podcast, recorded May 9, 2008.
Listen to the podcast. 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 Analyst Insights Edition, Volume 29, a periodic discussion and dissection of software, services, cloud computing, and 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 distinguished panel this week, and this is the week of
Joe McKendrick: Thanks, Dana, good to be here.
Tony Baer: Hey, Dana, top of the morning.
Gardner: And, last on our panel this week, Phil Wainewright, an independent analyst, director of Procullux Ventures, and also a prolific software-as-a-service (SaaS) blogger. Welcome back, Phil. [Update: See Phil's blog on this topic.]
Phil Wainewright: Great to be back, Dana.
But, before we get into a discussion on cloud computing's economic future, let's go around the table. I was at JavaOne in San Fransisco this week, and I understand that, Phil, you were attending a Salesforce.com event in
Wainewright: Yes, indeed, their first full Dreamforce event in
Wainewright: It was a great to actually have the Salesforce crew in my own timezone, so that I could take all of that on board. We had the usual two-and-a-half-hour Marc Benioff Dreamforce keynotes, and he was the one that got ragged this time, instead of me, so that was nice.
Wainewright: Well, that's right, although to be honest, it was my first Dreamforce, because I had never made it to San Fransisco for the Dreamforce events in the fall, and that's something that Marc has often complained to me about. So, it was good of him to bring the show over to me. I appreciate that, Marc, thanks.
Wainewright: Oh, yes, it is. There were 2,500 people there. So, it was a big show. Some of the independent software vendors (ISVs) who have been putting software on the force.com platform are actually from
Unit 4 Agresso recently bought CODA, which was an independent company listed on the
Wainewright: Well, I think it's an incoming tide. Whether it's got the speed and force of a tidal wave is another matter.
McKendrick: Can't you call it one of the "Four Horsemen of the SaaS Apocalypse" or something like that?
Wainewright: People started talking to me earlier this week about these four vendors, all listed vendors on the stock market, that have got a certain size. Taleo just did an acquisition this week that brings them out to the 200 million-a-year run rate, close to the run rate that Concur has. Taleo is talent management, and Concur is travel and expense management. Then, you have Omniture, which is Web analytics. They expect to do around about 300 million this year. Then, the big Daddy of them all, force.com, is looking to do $1 billion this year.
You are starting to see the leaders emerge now. Thank goodness it's not just Salesforce, but kind of gang of four, to use another foursome analogy, and they are riding the wave. I'm not quite sure what apocalypse it is yet. We might argue that it's an apocalypse for the conventional software vendors. Certainly,
Gardner: And, this event came right on the heels of the news last weekend that Microsoft, at least for the time being, is walking away from its bid for Yahoo! And, from comments from Bill Gates and others, it seems that Microsoft might be fully done with that merger or proposition. Was there any talk of that or did any Benioff mention it?
Wainewright: No, he was strangely silent, actually. The president of Google EMEA, was one of the people who came on stage during the Benioff keynotes. So, there was a talk about Salesforce and Google teaming up and working together, but very little about Microsoft.
The thing that interested me about Benioff's presentation, and this is something that I blogged about, was that he is really positioning force.com not as the platform of the future, but as one of the platforms of the Web, and the one that he believes will be the leading platform for enterprise applications. But, he is now starting to talk about a whole forest of different platform-as-a-service (PaaS) vendors and acknowledging other platforms -- like Google App Engine, Amazon Web Services, and even Facebook -- as platforms people use to build functionality in the sky.
That's an interesting change of emphasis. In the past, it was always about. "Salesforce is a platform of the future. Microsoft Windows is the platform of the past. And, we are going to replace Microsoft as everyone's favorite platform."
It's good that he's now talking about the context of the Web being everyone's favorite platform and Salesforce's force.com being just one of the platforms that you can choose to put functionality on the Web.
Wainewright: That's right, and perhaps that change of emphasis is something that Microsoft has not quite taken on board yet, and that's one of the reasons they thought buying Yahoo might be the way to go. Perhaps that's a topic we will get into later in the podcast.
Gardner: Okay. Let's go over to Tony in
Baer: I have been observing from afar. I have been remote, as they say, but have been devoting most of my attention to JavaOne. I do want to add a thought there about Microsoft or Microhoo and also about Marc Benioff's thoughts on an emerging SaaS ecosystem.
One thing I want to make clear is that when you just have one company in the market, essentially it's one-trick pony. When you have competitors, that validates the market. What Benioff was indirectly saying there is that if SaaS is no longer synonymous with Salesforce, that now validates the SaaS platform. It vindicates his contention that SaaS is a platform, and that the future is "no software."
That's one thought. The other thought, before going on JavaOne, regards Microsoft walking away from Yahoo. My sense is that Yahoo is not going to get any better price for their shares than what Microsoft was going to offer. But, I think it is a blessing in disguise, at least for Microsoft, if not for Yahoo shareholders.
This would have been a horrendous deal for Microsoft. This is not the type of deal that they do best. They do very well in making small, very strategic technology acquisitions. What's gotten lost in the noise here is that Microsoft does have this stake in Facebook, which only happens to be "The most Popular," software development platform in the social computing space.
And, I've got to believe that maybe they are facing a war in ads, but why not work around this, instead of co-opting this, to become or federate with the social application development platform of choice.
Gardner: I think that there are some indications that the bloom is off the rose of social networking, both as a significant revenue generator, as well as an application development platform, at least for one of the social networks to become a development platform. That's from some recent revenue indicators from Google that its relationship with MySpace has not proven to be as monitizable as they expected.
Also, some recent statistic show that the types of applications that have been generated on Facebook are very tenuous, very one-off or fun things that would appeal to teenagers, but not with any significant depth or business value. The amount of activity from developers on Facebook has been slacking off, or at least plateauing, which is not a good indicator.
So I take your point that Microsoft is in the game of social networking, but I am not sure if that's enough to do much for them in terms of overall online activity.
Baer: I'll put this way. For social networks, we are getting into kind of a Gartner-style "trough of disillusionment" there. But, I see this thing fitting more into the mold of the strategic technology buys or technology acquisitions that Microsoft does, because, if you think about it, this has not been tapped.
I totally agree with you. I'm very turned off by the types of applications and sort of frat-partying environment that you have on Facebook. But, I think there's a lot of untapped potential in terms of turning some of these techniques and using them to extend enterprise applications, whether they be on premises, in the cloud, or what have you. So, I could see this as being potentially an extension of the Visual Studio Platform in the .
Wainewright: I'm just thinking about advertising and Facebook. People are surprised that for these social networking sites the ads don't work. I remember back in the Web 1.0 boom and the dot-com boom, one of the things that was interesting was the discussion sites were very bad at generating ad revenue, because people didn't click on the ads.
The cost per thousand (CPM) for discussion sites, or for the discussion area of a site, was always a lot lower than other types of sites that were more information heavy. So it's old news about kind of sites where people follow what other people are saying. It's a bad site for advertising, because you are interested in the conversation. You don't go there to click away on something else.
Baer: That's right, and it's not necessarily the metadata of the discussion content that creates some affinity-based relationship between buyer and seller as a result, and, therefore, you get a higher value CPM advertising revenue benefit. It does seem to push it down to a lower common denominator of just page views for the sake of page views.
Wainewright: Yeah, that's right. People start chasing page views without remembering the reason that they are chasing is to generate value for advertises. They think, "We've got lots of page views," but they don't think back to whether those page views are going to deliver value.
Our topic is what are going to be the revenue models now that we have a fairly good expectations of SaaS, Web services, publicly available APIs, mashups, and increasingly robust cloud community of not only host and providers and infrastructure providers, but ecologies.
I emphasize the plural of development activities that create business value in some form over the wire. This is all well and good for the end user, but in order to support such an ecology, there needs to be revenue commensurate with the cost, perhaps even leaving some margin on the table.
Let's go to you, Joe McKendrick. You've been studying SOA for some time. You've been familiar with data for some time, technologically and functionally, but let's look at the economics of this as we move more toward an online world. Microsoft has indicated this through its Yahoo purchase attempt, desperate as it may have been and now perhaps squashed as it may be.
If you see the future as an online world, do you have any sense of how the money is going to be made, now that we are segueing into this new era?
McKendrick: Good question, Dana. And, in fact, Microsoft has given us another clue. Another memo from Ray Ozzie surfaced a couple of weeks back. You may recall the memo back in 2005, the famous "turn the world upside down" memo that talked about the advertising support of the online model for software. He kind of reinforced that with his latest memo.
It wasn't saying, "We must offer software advertising to support software," but it was more of a discussion about the social mesh, the community, the social networking, a paradigm that's emerging. It's way too early in the game, but I think it's inevitable. We are really seeing it on the consumer side. It's going to be interesting, but I think it's going to leach into the enterprise over the next couple of decades as well. I'm talking years from now, but it's definitely a model that will be sustaining consumer computing. We are seeing that emerging on the social computing side.
Look at what Google has done with just a small slice of the advertising market -- text ads associated with search and search criteria that they are going to start automating through a similar auction bid process, advertising that goes on banners ads across the Web, beyond just the text ads.
Then, they've got their designs on radio, magazine, and newspaper advertisements, particularity done at the local level. They've got designs on television advertising across both cable and broadcast, but certainly with the television that goes out over the Web. So, Google is looking at a potential of hundreds of billions of dollars of market, where Microsoft's annual revenues are what -- between $40 and $50 billion I believe? We're talking about several significant multiples of potential revenue here when advertising is factored as a full business.
So, just using as the factoid, Phil Wainewright, what do you think about the opportunity for software companies to take more and more of this advertising pie?
Wainewright: Well, we touched on this in our discussion last week, and I really think people have got this completely the wrong way around. To focus on advertising is just so "0.0," to coin a phrase. Advertising exists only because we don't have the Web. Advertising is something the B2B market has to use through magazines, TV shows, or whatever, because they couldn't reach the consumer directly.
Now, the Web enables people to reach potential consumers and business prospects directly, rather than having to go through this advertising. So, the idea that the software industry is going to get funded by advertising has got it completely the wrong way around. Actually, what is going to happen is that business is increasingly going to use software in order to get closer to its consumers and its prospects. It can actually skip having to spend the money on advertising in order to make that connection.
Let me explain how that might work, instead of running adverts on sites that host discussions about bookkeeping services for small companies, for example, or instead of paying for search ads that pop up when people are searching on the Internet for bookkeeping services for small companies. As a small company, if you are using a financial application to run your company and you want some bookkeeping services, a bookkeeping service might pop up as a menu option in the software. You can sign up for and use an outsourced service over the Internet.
Instead of the bookkeeping service actually having to advertise on the search engines, in the publications, the discussion forums, and the social networking sites, they just pay to have their service made available within a software package that relates directly to the service that they are offering.
Therefore, it's not really advertising any more. It's just product placement at a point where the consumer or the business, in this case, actually needs that service.
McKendrick: Phil's got it exactly right. Another good example is mortgage calculator, something that popped up about 10 years ago on the Web. Mortgage calculator is software, and probably before 1998, if you wanted such software you had to go out and buy a package at Staples or Office Depot. Now, you can go to a mortgage company site, for those who are still looking for mortgages, and check out a calculator on site. The software is made available as a value-add. Phil has got it right in terms of their reverse. We have to look at this in a reverse sense.
Baer Joe you are so 2006, I have to say.
So we are moving from an advertising to a placement or even visibility value, and it becomes rent to those who can draw the people in. Does that sound reasonable?
Baer: I'd say so. Look at the Amazon model which isn't necessarily overt advertising, but its affinity. You just bought a book, say, on accounting and they'll say, "By the way, based on your pattern of orders, would you also like to get a book about taxes or something like that?" So, it's basically keeping it in context.
Just a couple of days ago I was reading an interview in one of the business journals with someone who was critiquing TV ads and saying, "You know something? These are so obsolete. I really hate watching this because, basically, when you're watching a program, statistically very small minority of the audience is interested in that particular product at that particular time."
You start looking at migration to digital broadcasting. At some point -- I don't know the exact technology mix involved -- combining that with the Internet, there will be some way of micro casting. There may be a large population segment watching a specific program, but you maybe identified in terms of which demographic you specifically are. It's almost sounding 1984-ish.
McKendrick: Tony, you are so 1984.
Wainewright: Tony, that's right. I think Google actually realizes that and understands that. Therefore what they are aiming to do is get into TV advertising and all these other sectors. These are vendors that enable this kind of personalization of the message, being a conduit between the prospects and the business that's trying to sell to that prospect, and using software automation to enable that.
They are thinking beyond the old model of advertising, and I think that's Microsoft's problem. Microsoft hasn't really understood this, is still thinking about online advertising as a segment, and is not looking beyond the wider opportunity to use the automation on the Web as a way of just bringing buyers and sellers close together.
This requires a tremendous amount of cloud compute, to the same levels we have seen in matching search criteria to results and then matching that to advertising. That advertising is then bought through an auction-bid process among those seeking the highest placement.
So if we take that same model and apply it to all sorts of different needs and wants of business, personal, entertainment, and luxury across the board, what do we call it? It's not really advertising.
Here is our chance at the BriefingsDirect Analyst Insights podcast to come up with a name for this thing. Any takers?
Wainewright: I've struggled with it actually, Dana. I have been planning a blogpost about this for probably a year. I saw someone really calling it "featuretisment," which I am not advocating, but it's a possibility. Maybe it's "online merchandising," maybe it is "placement," maybe it is just "promotion," rather than advertising. But, I think we do need a different word, because, if we use the word "advertising," we approach it too much from the old mindsets.
Baer: Here is one that I hopefully don't use, which is "lifestyle enhancement" or "lifestyle augmentation." I hope we don't use that.
Baer: I want to just shoot that one down immediately.
McKendrick: I want to throw another note in here. When we talk about social computing, the whole Web 2.0 paradigm world, we are talking about the incoming generation. You have the 20-something is coming in, and even younger than that.
These folks are well accustomed to SaaS, online/on-demand software and are accustomed to seeing advertising online. I have a nine year old daughter and her favorite sites are Webkinz in which you buy stuffed animal, get a special password code log in and you can virtually manage your Webkinz online. She loves that and --.
McKendrick: Yeah, Club Penguin is another one, Disney took that.
McKendrick: What's interesting is, 10 years ago, our kids would have had to go out and buy a CD and install a CD locally in the computer. These things are all delivered online to kids. Kids don't want this. My nine-year-old probably doesn't know how to install something from a CD.
McKendrick: Exactly. Everything is through the browser now. That's what they are expecting. That's what expected now. College students as well.
This statement came out loud and clear. Sam Palmisano says he is never going to put advertisements in anything
They need to consider some of these other more interesting business models, particularly in the context of business. We're not talking about a $15 music download or an $8 movie download. We're talking about anywhere from $50,000 to hundreds of thousands of dollars of purchasing that happens very rapidly across the entire B2B economy.
Any thoughts about how
Baer: Actually, take a look at the emerging model for downloading films or TV shows, that's probably is a better example. For a certain price you can get it without ads. For free, you get it with ads. I don't know if that directly applies, there maybe some sort of variation of that, which can keep Sam Palmisano's feeling that he can go to sleep at night.
Wainewright: I think they do. The subscription model does take, but I think you will still have indirectly funded applications, particularly for volume markets like the business markets, the small business market, and obviously the consumer market, which is indirectly funded.
The consumer doesn't pay, but it is supported by some kind of either advertising, commissions on product placement, or just the expectation that a certain percentage of free users will upgrade to a paid version, and, therefore, the free-user population is a marketing expense.
We see all of those models already in the SaaS segment. The thing that is going to make this a slow transition is having a set of subscription services, where there are lots of different providers being aggregated, and they're getting some cut off the subscription. These are big billing and settlement challenges.
Actually, the software, the infrastructure software, that can support doing all of that measurement and doing it accurately and dealing with all of the questions: "I want my money back -- how do I get my money back?" These are questions that come up when money changes hands. This is something that still hasn't been worked out properly.
I was interested to see that Salesforce is still at the first stages of working at providing billing and settlement for force.com. In a sense, they are probably behind other players in that space, in terms of having an infrastructure for doing that. I think that could be a brake on this kind of thing taking hold very quickly, simply because the technology doesn't exist yet.
Baer: Just to underscore your point, it's not only that they perfected it for their core business, they now are handling increasing portions. A lot of their business is business process outsourcing. So, they're saying, "We don't only deliver the product to your customer, but we will take on large chunks of the fulfillment process or the warranties service repair process." And, they've have got the billing mechanisms down for that.
Gardner: So, the intellectual value of understanding how to manage that process is what ultimately buoys them and makes them now part of a potentially larger virtual ecology, rather than physical.
Wainewright: Hold on! They are doing that as a single company, they are not doing it with all kinds of tiers and partners, who are all contributing their own services and wanting to bill and charge back for those services. So, it's an order of magnitude larger.
Gardner: Perhaps the message to them is that they should be thinking along these lines, taking what assets they have, and extending them into partnerships, APIs, and Web services that can be plugged in through a SOA, and perhaps they get some transactional revenues as a result.
McKendrick: Which should make force.com and
Those vendors who want to be positioned well in front of an activity, the fulfillment of the actual transaction financially, would be in extremely advantageous position. Even if they take a fraction of a percent per transaction, ultimately we are talking about a massive business, one that everyone essentially would have to do some level of business with.
Any thoughts about the transactional hub, and the cloud compute power that would be required to do that?
Baer: StrikeIron kind of hits upon that model. They offer a marketplace of Web services, and part of what they do with that paradigm is that for the software developers -- someone who creates a service and offers it through the StrikeIron service -- they handle the transactions, the micro transactions. You may get a few pennies each time some uses your service. I think their model is going to take off. I think there is lot of potential for the model. We are going to see a lot of micro transactions taking place across the Web in the entire network.
Any other thought about the role of Google and what other organizations might be able to step up to the plate in this regard?
Speaker: Amazon Web Services.
Wainewright: I was just going to say that Rearden Commerce is perhaps an example of a vendor that's getting into that opportunity. Rearden this week announced a funding, a $100 million in venture funding, which mainly came from American Express and Chase.
So we see travel booking and the credit card company are teaming up with the transaction providers or the transaction handlers and getting at this nexus of bringing buyers and sellers together in the travel and employee services space. The amount of money that's being invested in Rearden says that people feel that there is quite a lot of potential in that particular vision.
Wainewright: Rearden Commerce provides software that allows you, as a business, to have your employees book their flights, their dining, and their corporate expense activity in a controlled, managed, and largely automated way. At the moment, most of their customers are relatively large customers or are customers of AMEX's travel management services. They charge a license fee at the moment, but I think in their road map, they see a potential to make money just by taking a cut out of the value of the transaction, rather than sending a traditional subscription license.
Baer: Just to go full circle here, I remember just talking to an enterprise vendor back in the 1990s. They were trying to export different mechanisms for pricing, and were talking about what they called at the time "risk sharing." Instead of charging the traditional license fee upfront, they were getting some sort of share of the benefits. Obviously, that never panned out, but today through SaaS, through micro-pricing and transactional pricing, and the acceptance of subscriptions and variable pricing, the time may have come for merging of some variance of that.
We have the "son of software" in services, also a place where Google is well-positioned. We also have the "son of financial services." That is the next era that will require the compute ability to manage on a real-time, micro level across multiple variations of transactions and very complex process and event landscapes.
And, once again, Google could rise up and be prominent in that place as well. It seems that the algorithm is what rules the future, and he with the best algorithm that can execute on that algorithm and draw in the most partners is the winner. Any thoughts?
Wainewright: And, therefore, Microsoft, as long as it talks about software, rather than focusing properly on services, is always going to be the loser.
Gardner: You need to focus on being able to develop, control and adjust the algorithms and then execute on all the variables within those algorithms at massive scale, and that becomes ultimately who's got the best compute cloud infrastructure. I'm not sure it's going to be built on Windows.
Baer: The interesting thing about Microsoft is their whole scale has been more penetration, it's never been scale in terms of that we can now conduct scalable processing.
McKendrick: It's getting to the point where the operating system is something that gets in the way. I think people will be happy with just some kind of device, such as a mobile device with a very thin layer and browser accessing everything out on the network.
Baer: And, from that standpoint, the one interesting thing that I saw from JavaOne this week, is the battle over where that rich Internet layer is going to be. Should it be within the Java virtual? Should it be in the flash runtime? You are talking about a couple battles of runtimes. You are not talking about battles of operating systems.
Wainewright: Dana, I would disagree with you about runtime on the client. I think it's going to be important, but I think it's the topic over another podcast.
Baer: Phil mentioned Rearden Commerce, and I want to add that all it's components are built on SOA-enabled services. So, there is a good lesson there. If you want to get out in the cloud, SOA paves the path.
Baer: It's the only way to go, Dana.
McKendrick: Thanks, Dana. It's great to be here.
Baer: Hey, good talking again.
Wainewright: Good to be here, Dana.
Transcript of BriefingsDirect podcast on the future of advertsing. Copyright Interarbor Solutions, LLC, 2005-2008. All rights reserved.
Subscribe to:
Posts (Atom)
