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.
Showing posts with label IONA. Show all posts
Showing posts with label IONA. Show all posts
Thursday, June 05, 2008
Wednesday, October 17, 2007
BriefingsDirect SOA Insights Analysts on Citrix, XenSource, HP and Opsware
Edited transcript of weekly BriefingsDirect[TM] SOA Insights Edition podcast, recorded
Listen to the podcast here. If you'd like to learn more about BriefingsDirect B2B informational podcasts, or to become a sponsor of this or other B2B podcasts, contact Interarbor Solutions at 603-528-2435.
Dana Gardner: Hello, and welcome to the latest BriefingsDirect, SOA Insights Edition, Volume 24, a weekly discussion and dissection of Services Oriented Architecture (SOA) related news and events with a panel of industry analysts and guests.
I’m your host and moderator, Dana Gardner, principal analyst at Interarbor Solutions, and ZDNet blogger. We are joined by a large stable of experts and analysts this week, and this is the week of
Jim Kobielus: Good morning, everyone.
Neil Macehiter: Hello, everyone.
Dan Kusnetzky: Good day, everyone.
Brad Shimmin: Greetings, everybody.
Todd Biske: Hi, everybody!
JP Morgenthal: Hello, everyone.
Tony Baer: Good morning, Dana and everybody.
We're also going to step back a few weeks into July and discuss the $1.6-billion acquisition of Opsware by HP. This is a case where we are looking at management, and an acquisition that might help redefine or expand the role of management, automation, and operations, and perhaps have an impact on SOA as well.
First, let's get the low down on the XenSource and Citrix deal. Why don’t you give us a quick recap on that Tony Baer?
Baer: Well, Citrix has made roughly a $500-million offer to buy XenSource, which is itself a company that was formed around commercializing the Xen hypervisor open-source technology. In fact, it only morphed into a real commercial company within the past 12 months or so, maybe even less.
The interesting thing about XenSource is that it’s been considered to be the leading, emerging alternative to VMware. It essentially virtualizes the machine to a slightly more native approach than VMware. It's a very interesting acquisition because Xen has had a relationship with Microsoft, where it gets access to Microsoft's virtualization technology, and it also fills a key gap for Citrix.
Dana, you and several of the other folks here who were on the call raised a lot of questions in terms of how this impacts the relationship between both companies and Microsoft.
My quick take on it is that in the grand scheme of things, it's not going to make huge changes. Of course, there's a lot of wiggle room here, but my sense is that, when all the debris settles, Microsoft will still need some way of interoperating its hypervisor with the Linux environment. So, even though the relationships may change somewhat in the long run, there will still be some sort of technology sharing here.
Macehiter: I'm not sure one can necessarily equate the high multiple with its being a game-changing event. Clearly, XenSource has about $8 million revenues. We think its paid revenue is $20 million next year. So, it's a monstrous multiple, which indicates that virtualization is very hard, as we have seen with the VMware's IPO. They are now the top publicly traded software company in the world, based on market cap. What this acquisition emphasizes, more than anything else, is where the temperature is rising, and it's not in the core hypervisor.
The hypervisor that Citrix has acquired in Xen is actually open source, and the commitment is to retain that as an open-source initiative. The real value in this acquisition is XenEnterprise v4, which addresses some of the lifecycle management issues around virtual machine infrastructure provisioning, image management, etc. That’s where the temperature is already rising, and it was an acknowledged gap in the Citrix portfolio around desktop virtualization. So, I think it is indicative that virtualization management is hard. I must admit I was quite surprised that Citrix was the acquirer. I was thinking that XenSource was an acquisition target, but I was thinking more of the OS providers, the Red Hats or Novells, acquiring the capability, particularly around the management.
The Microsoft relationship isn't game changing, primarily because Microsoft’s hypervisor technology and the management around it, in Viridian and Virtual Machine Manager, is still a year or so away. It's going to be very interesting to see how the relationship morphs, as Microsoft becomes less dependent by virtue of having it's own hypervisor within Windows Server. Microsoft Research in
Kusnetzky: First, I want to expand the notion of virtualization, and to point out it's not anything that’s really new. The model of virtualization that I have been using to examine the market includes seven different layers of technology, each moving some part of an application environment from living in a physical world, to move in a logical or virtual world. If we look at Citrix's strengths, they've always played very well in access virtualization, that is, making it possible for an application to display on a remote device without the application having to know a great deal about what the remote device looks like, the network that it's on, or anything.
They've also got some form of application virtualization, allowing applications to be accessed regardless of where they are, what operating systems they're running on, and the like. They’ve never had a very strong processing virtualization, storage virtualization, network virtualization, security story for the virtualized environment, or management of physical and virtual resources.
If we look at just the idea of what XenSource was doing with their processing virtualization management security, particularly their recent announcement of partnership with Symantec for the Veritas Storage Foundation software to be included in XenEnterprise, you could see that Citrix starts to have a more top-to-bottom virtualization story than they every had before. So, from a product portfolio view, this acquisition appears to make some sense.
From another point of view, though, I have some pretty serious doubts. If we look at the history of technology company acquisitions in the past, corporate culture and management style makes a very big difference in retention of key developers, key architects, and key strategists.
We don’t have to look too far to see some pretty major disasters where a big company acquired a smaller company that had a different approach to business and the key designers left. You could look at IBM acquiring Rohm to get into the telecommunications market, and very short order, all of the people who had made Rohm what it was, went to Northern Telecom. Another example would be Computer Associates acquiring Ingress, and the significant designers and architects moving to Sybase and Oracle, leaving CA with a shell of a company.
Kusnetzky: There are even strong differences. Citrix has been married to Microsoft for years, even though it had technology that allowed it to work with Unix, Solaris in particular, and Linux. They really didn’t focus on that because it would anger the folks in
Kusnetzky: If we look at Citrix's portfolio, every single piece, service, or product offering is matched by something Microsoft is pushing now. That, in essence, means that Microsoft is trying to acquire the business that Citrix has and slowly remove Citrix from the limelight and off to the sidelines.
They have their own presentation services in the form of terminal services. They have their own clustering. They have their own Go-to-Meeting-like software with the acquisition of another company’s business. Go-to-Meeting was Citrix and Live Meeting is Microsoft. If you go down the list, Citrix is being increasingly pushed off into the corner, and they needed to do something that allowed them to come back and be focused. They needed a broader strategy, one that wasn’t focused solely on access mechanisms. The acquisition of XenSource gives them a broader story.
Kusnetzky: That is, at least, a possibility. The majority of Citrix's business is centered on Windows, so they can’t go too far along the path of angering Microsoft, because it would become very difficult for them to get access to key technologies that allow their product to work.
Biske: Virtualization is definitely something that organizations are looking at right now. For the clients I've worked with, it's been a mix. Some are really trying to embrace it on the server side and make use of it right now. Others are looking at possibly using it on the desktop for developers, when they need to get a specific development environment, but it’s definitely in people’s minds today. So, I would definitely classify it as in the list of strategic initiatives that companies are looking at and determining how to use appropriately.
This is a really interesting acquisition that will help XenSource at least get more mind share in the enterprise. Companies obviously have lots of Microsoft investments on all their desktops. There's a good chance that major enterprises have significant investments in Citrix as well, if they've got any need for remote access for their systems, terminal services, etc. It will open it up to a few more environments to add in this virtualization capability for organizations that were still unsure about what to do with open source. It’s a good thing from that perspective.
Biske: Absolutely. I compare it to IONA’s acquisition of LogicBlaze. For companies that were looking at open source, having IONA behind that was a good thing, because they've now got a strong name, somebody they can go to for the support around that. Now, you've got the same situation with XenSource. When you have these smaller companies trying to commercialize open source, they still haven’t built the reputation of these larger vendors. So, overall for XenSource it’s a good thing. We’ll have to see whether it really enables them to compete even more with VMware and Microsoft’s coming solution in the space.
Morgenthal: Thanks. Avorcor is delivering what we call the supply chain as a service. We're really involved heavily in a vertical market SOA around supply-chain management. We've been doing a lot with taking SOA and driving it out in a vertical nature, not just horizontal, where I see a lot of the early work being done. Because of what we're doing, we are working with clients who are facing these issues.
I’ll give you an example where the state of art is, where the state of the decision making is. We have a client that is looking to make a very large enterprise application decision. The company from which they're buying their enterprise application software refuses to commit to virtualization or running on a virtualization architecture. Even though there has been significant evidence of enhanced performance that are running natively on a flat Windows platform in a virtual machine, this company would not commit to running in production in a virtualized architecture. On the other hand, we find that we’d perform better in a virtualized architecture.
We've been dealing with issues of the Microsoft platform for a long time around resource management, where we're fighting with SQL server and other applications or resources, and each one has different memory requirements. This virtualized environment allows us to focus on giving our application 100 percent of the resources, and thereby never running out of things like TCP/IP sockets or having memory thrashing errors slowing down wireless communications, which is critical to Web services doing their job. So, it’s having a profound effect on the production environment.
Morgenthal: From a development perspective, that's a given. I, myself, have done what no one expected. I'm actually running on a Macintosh, and that's because I run all my development from my Windows platform stuff in a parallel virtual machine. The reason I do that is because the the MacBook Pro is one of the best Intel machines on the market today. It’s solid. It’s stable. The applications and everything else I do using the Web in my job, run perfectly in that environment, and when I need to do development. So, from a development perspective, it’s a given that people are moving in this direction in busloads.
Morgenthal: On the datacenter side, the promise there is better utilization of resources. As I said, if you really want to get into it, you could find a way to tune Microsoft, but I have a sys admin working in one of my clients who is fighting with this 3GB initialization parameter. When he puts it in one way, one app gets hit when he puts in there. When he doesn’t put it in, other apps get hit, but mine works fine.
This is a clear case of where you go out and get an additional operating system license and put this into each application and in its own VM running on a four-way or eight-way Intel Duo Core 2 machine -- they are running an SAN -- and you have one of the cleanest, most high performing environments I've ever seen.
Shimmin: Absolutely, it's a matter of economics, but not just for the reasons we were talking about. We were mentioning that this is something that helps you better utilize your hardware. This lets you better utilize your software. It basically frees you from having to worry about the stack and the interoperability issues that arise over time in managing a stack.
Shimmin: You're right there, Dana. There are two levels where this really takes effect. One is, as you were just describing, on a broader level, you need to have interoperability. That interoperability is something that is multilayered and something that you need to be able to standardize over time in a SOA infrastructure and virtualization, once you abstract away all those things that mitigate your ability to do so.
On a more finite level, the part that interests me is the fact that, when you set up a SOA installation, you have a lot of issues you have to resolve initially in terms of, "I'm going to have this version of the operating system, and this version of application server, and this version of USB up the stack."
As we've seen a lot of the vendors, Red Hat and now Novell with their agreement with IBM this week, are trying to say, "Okay, look, we are going to, standardize the stack for you. We're going to tell you that it's definitely something you can count on over time. It's not going to break every time we version a piece of it." What virtualization does is let you set up that verified stack on your server and not have to worry about breaking it down the road, because it's sitting in it's own virtual environment.
Gardner: And doesn’t virtualization also allow you, if you're have a Microsoft shop or you have a lot of Microsoft applications running, to continue to exploit and leverage those investments, but extend them, and without an additional high cost on the infrastructure side of it?
Shimmin: Absolutely. Your lifespan for software is dramatically increased by virtualizing it.
Kobielus: I don’t know if we're missing it, but may just overlooking the fact that virtualization is hot this week. Clearly, there have been very important announcements, both XenSource with v4 of its product, the IPO by VMware, and, of course, the acquisition of XenSource by Citrix. That’s hot this week, but really SOA is a virtualization approach.
Virtualization is a long-stroke perspective, as is any approach that further decouples the application logic from the underlying metal. That’s what SOA is all about. Another way of putting that is, abstracting the external calling interface from the underlying implementation of a service or set of services. Virtualization has been around since the dawn of computing. When we stopped programming in machine code and started using FORTRAN, COBOL, as well as compilers and so forth, to put greater distance between the logic and the metal, that’s when virtualization, as an approach, began. It was the big bang of the 1950s and 1960s in computing.
So, in a sense, virtualization is like a cosmic background radiation that still radiates and still manifests itself in complex ways, including, of course, this new focus, this recent focus on hypervisors and so forth.
Cycling back to the importance of this week’s events from Microsoft, what happened this week is good for all three major players. It's good for XenSource, Citrix, and Microsoft. Clearly, it's good for XenSource, because, they've got a tough challenge. They're in a market where their primary competitor, VMware, currently has 85 percent of the market for server virtualization. So, XenSource needed its own mini big bang to give it further momentum to overtake VMware/EMC fairly soon.
Citrix is much larger, more deeply capitalized, richer in R&D and has extensive global sales and marketing, and is a logical suitor for XenSource. It's good for Citrix, because Citrix has several people who have been in the access and presentation of virtualization space for quite some while, and it's well entrenched as a Microsoft partner. So, this allows Citrix, by acquiring XenSource, to put together a complete end-to-end virtualization platform, from storage to processor, to server and access virtualization -- the whole soup to nuts.
Kobielus: Oh, sure. They've been moving in that direction, of course -- thin-client application virtualization and a multi-client environment focused on mobility. It definitely positions them better. Citrix acquired NetScaler, a year or two ago, and they've got their own MetaFrame Technology. I'm hoping that they will then unify or de-siloize their various virtualization product Citrix upon Xen as their dominant hypervisor, without losing any connectivity or interoperability with Microsoft, on both the access side and on Viridian, as Viridian gets built up.
One of the most powerful things is that Citrix is now the bridge, virtualization-wise, with the open-source community. Clearly, Xen has great traction with Red Hat, Linux SuSE, and, of course, Microsoft, because they have been Microsoft’s primary access virtualization partner for quite sometime.
I want to close the loop on your question, Dana. The XenSource acquisition by Citrix is good for Microsoft, because it allows Microsoft to buy some time until Viridian is ready. A year from now, Microsoft can say, “Oh yeah, we don’t have Viridian ready just yet, but look at this. Two of our primary virtualization partners have gotten together to field an ever more comprehensive virtualization product portfolio, which is integrated or will be integrated fairly tightly with Viridian when that comes out."
So, we'll hear Microsoft saying, “We don’t have it all together today, but we have partners who can give you a fuller virtualization portfolio to compete with EMC/VMware."
Kobielus: Right. I was surprised that we haven’t seen Microsoft acquire Citrix outright.
Macehiter: Can I just chip in one quick thing here?
Macehiter: One interesting element of the acquisition is that historically XenSource has been primarily focused on virtualization in the server infrastructural environment. Citrix has historically focused on virtual desktop, and VMware had it's VDI initiative around that. One question about this is the extent to which the Xen capabilities are harnessed by Citrix to address some limitations of the virtual desktop infrastructure environment, in terms of an integration with things like the Citrix Desktop Server. That becomes the primary focus in terms of offering a virtual desktop infrastructure, the expense of the core backend server infrastructure virtualization.
There's an interesting dynamic there. Although, in principle, they have the soup-to-nuts solution, the question is whether they bundle this as a core capability, which means that they are primarily focusing on virtual desktop, versus virtualization across the page. A key issue is the scalability limitations around things like presentation server, where you just see organizations throwing in more and more servers just to deliver the scalability of presentation server.
Baer: I've also been monitoring a bunch of the blogs, one of the more interesting cases that I have seen is that -- and which actually makes some sense -- is that Citrix is not, at its base, an open-source company. As Dan was talking about before, there are some cultural challenges there. XenSource was an academic project at
That would clear the way for Microsoft to pursue an acquisition here, and make for a nice clean break. I don’t know if that answers your questions, Dana. but my sense here is that this might actually smooth some rough edges around the challenges Microsoft has had in developing Viridian.
Baer: If you have that clean break, where the open-source stuff is taken care by an outside foundation, that could set some sort of precedent from Microsoft, because Microsoft had been making some initiatives towards the open-source community in the area of interoperability.
Baer: Not in the long run, but my sense is that, what Microsoft is trying to do in sort of a life-extension mode is organize these interoperability agreements with folks like JBoss. That type of precedent could happen here with the Xen Technology, and if XenSource under Citrix divests the technology and it's absorbed into an open-source foundation, that would clear the way for Microsoft to open up a much closer relationship with Citrix. Ultimately, Microsoft could acquire them, if Viridian is further down the pike that they think.
Microsoft has had challenges developing this technology over the past few years, and Microsoft hasn't been reluctant in the past to acquire technology. The only thing that might be a game changer is that Microsoft tends to acquire small start-up companies, and Citrix wouldn't fit that mold. But, this does open up some possibilities.
Biske: If you start getting into the automation space, the HP-Opsware deal is obviously the more interesting one. There's a natural connection between the virtualization space and some of the movements in the management space. Your panel here discussed SOA and virtualization almost a year ago, and I have some comments on my blog about it.
When you really embrace SOA, you're going to wind up with more moving parts for a given solution. And in doing so, you could create this management challenge of how to allocate resources for each of these individual services that have their own life cycle. There's a natural potential to move towards server virtualization to do that, so you can get your arms around that whole management concept. Where I've been disappointed in the management space, however, was that we really haven’t seen anything from the large systems management vendors to start tackling this problem.
So, to this Opsware deal. Opsware was founded and created by Marc Andreessen of Netscape fame. It had an interesting see-saw ride in terms of its market capitalization and then the dot-com boom and bust, hung on through the tough times, and now has been acquired by Hewlett-Packard. Tell us again with a little bit more depth, if you would, Todd, how you see management on the operations side and SOA relating?
Biske: What's most interesting for me is applying SOA to the management space. So, if we are creating lots and lots of services -- you may now have 500 or 1,000 services -- you have to look at that and say, "I have a bigger management problem." There's no reason we can’t take the concepts of SOA and apply them to the management environment.
So, whether it's automated provisioning of solutions, automated policy management, a need to change SOA’s or enable more resources for a particular consumer, there is no reason that I shouldn’t be able to have my management systems call a service to do that. I may want to set up custom orchestrations for how to manage my infrastructure. I may want it all automated out of the box and just push a switch and have it happen.
In order to get there, we've got to have management services on all of our infrastructure, and that’s where there's a huge gap. Everything is still intended to be used by a person. Maybe with some creative scripting, people are able to do it, but you can compare it to the days of Web-enabling mainframes, where the technique was to screen scrape off the green screens. You almost have to do the same thing from the management side now. Look at these user-facing consoles, figure out what glue you can put in front of it to script it, and automate it.
Shimmin: They're absolutely in a position to help us with this, both from what Todd was just saying there, and the inverse of what Todd was saying, which I want to talk about, but they have the products and the technologies. The Systinet acquisition that I think is the linchpin here for making this all work together. As you were saying, we’ve seen precious little come out of them and others in the space. The real go-getter here for me is the opposite of what Todd was saying. I would want to see my SOA installations able to speak to and hear from my datacenter systems management solutions. And right now, for that closed loop you were talking about, everything we see is the basic SNMP traps that may get read by
That lets you say, "Okay, there is an alert that one of my servers is overrun on memory. I’ve got these applications running on it, I am going to need to do something, and I see an alert that I can drill down on, and do some basic root-cause analysis." That’s not enough for a true business technology optimization and being able to utilize the resources you are trying to marshal for a SOA environment. I want my Tivoli Application Manager to fully automate that process, look at the variables and the event stream coming from my systems, correlate that, and put it into some sort of context with my applications that are running on it.
Morgenthal: I had a conversation with Paul Preiss, who heads up IASA, the International Association of Software Architects, about this very thing. He has raised a point and is trying to drive attention towards the exponential growth of SOA, as people start to add services and services become dependent upon services and organizations. I don’t see that problem. One of the differences is that when you come at it from an enterprise IT perspective, and when you come at it from a product perspective, you end up with two different SOAs.
From a product perspective, when you deliver a product as a SOA, you're delivering the architecture, and then you are delivering the implementation of that architecture. Therefore, you have a very controlled instance in which you can manage very easily without needing large governance controls, because you're providing all the infrastructure for management of that SOA as part of your application.
Yes, when you have a lot of legacy infrastructure and legacy investment, and people without the sophisticated SOA architecture experience on staff start developing services, you open yourself up for potential disaster. In those instances, the organization has to ask itself, "Are we ready to invest here?" Every organization obviously wants to take advantage of the latest technologies. This is one of them that can really end up biting them if they are not careful.
So, they need to step back and think about what it takes to invest in SOA and start to wrap their legacy systems and make them available. For one client I worked with -- I love to tell the story, it’s hysterical to me -- we went in, did a big installation, and they knew nothing about Web services. We introduced a lot of the organization to what the Web services can do. Before we knew it, there was a line out the door: "Can I have a Web service. Can I have a Web service?" We had opened up doors to data that had been previously locked tight and made it very difficult for them to do their jobs.
I told the CIO, "You have to think about a security architecture around this," and he agreed. I came back three months later to do a follow-up meeting with him, and I said, "What did you end up choosing?" And they hadn’t. And this is an environment where they don’t even allow you out to your Yahoo Mail. Every Website is locked down tight, but anybody with a notepad, and knows how to write an XML document, can now get whatever data they want out of the mainframe.
So, you see what’s happening. Governance is at the point already where you have a consolidated approach. Prior to that, you need a plan, you need a well thought out approach to what it means to invest in this type of technology and architecture.
Macehiter: I take a slightly different perspective on the distinction between governance and systems management. I actually think it’s a continuum. Governance is about the way you manage the entire service lifecycle. Historically, there has been this distinction between the governance of design-time processes and the design and development of application solutions, and the governance of the operational environment. Primarily, that’s been because applications have been developed and thrown over the wall.
As we move toward more of a service-oriented approach, the service actually becomes a common element that spans development and operations. That’s one of the key benefits of a service-oriented approach. The implication of that is that you can’t make these broad distinctions. There needs to be continuum. And that’s where things like the registry and the repository become key, because they contain and manage the artifacts that can provide that linkage in terms of things like contracts, and then policies.
There has to be more of a joined perspective. HP, in principle, through its acquisitions, has the assets. For example, when they acquired Talking Blocks that was one the early Web services management players that had assets around management of Web services. Now, they're using it to manage their infrastructure, using Web services. But the Systinet acquisition was part Mercury, which is primarily focused on the design-time. HP really needs to join this up. The other issue is around granularity. When a lot of the management vendors talk about managing a SOA, they're really talking about managing the service-oriented infrastructure, rather than managing the services themselves. So, there is a granularity issue.
Opsware is very good at automating provisioning in the lifecycle, but it’s around the infrastructure that’s running the services, not the services themselves. That’s where the linkage needs to come. I tend to share Todd's views. The vendors in the space -- the BMCs, IBMs, HPs, all of them -- have really missed this, and they’ve been lacking in explaining how they're really going to manage the services, because they're so fine-grained. Historically, managing an instance of an SAP application server is very coarse-grained, and that’s comparatively straightforward. But, when you're talking about disaggregating that and having application components everywhere, you have to disaggregate the way you manage as well.
It seems like we’re missing not only, as Neil pointed out, a vendor to step up to the plate and solve this on their own, but we are also certainly missing a management-standards approach that would allow a solution-based, ecology-based, or even an open-source based approach. What do you make of that?
Baer: There’s no question about that. Part of the problem is that at that level, when you start dealing with questions of what defines a service level and a service-level compliance and that starts to get into some higher level areas. When you look at the history of standards, the OSI stack is probably a great example of this with the seven layers. I may get my numbers wrong here, but it was relatively easy to standardize Layers 1 through 4, but when you got to layers 5, 6, or 7, where you get close to the application layer, it gets a lot closer to a lot of the assets that vendors consider to be their value adds.
So, I wouldn’t hold my breath waiting for standards. I have always been concerned about what I wrote about a couple of years back as sort of a blood-brain barrier, which is that you had this conception of runtime governance of SOA, then you had this idea of runtime management, which is essentially more of an infrastructure area. They're handled by two different constituencies, one area being handled by datacenter operators and sys admins, and the other area being handled more by the application folks.
So, when I speak with the AmberPoints of the world they say, "Well, what we deal at service level, we're just dealing with it more in terms of tracking -- is the service level maintained -- but we are not going back to the root cause, which is that a particular data server goes down or something like that." There’s just a huge gap there. I was very disappointed with HP, after they acquired Talking Blocks. I never saw much action there in terms of trying to bring that more into what was then OpenView.
HP has a golden opportunity right now, especially with the way they’ve been running HP software. They reversed the acquisition, where they buy Mercury and then put most of the Mercury execs in charge of strategy, which is a brilliant move. They never had much strategy there before that, but they also were taking management to a much higher level. They need to do provide that sort of unity there. That way that you can get a pass-through, so that, for example, when
Another area is what I would call IT process automation, which traditionally has been called "run book automation." You might recall Opsware had acquired this company called iConclude, which had that type of product that allows you to automate the workflow of running the data center. This is another way of looking at it. You could call that workflow as a service, and that’s something that is an incredibly open opportunity.
Baer: Exactly, The other thing that Brad and Neil referred to is the whole idea of governance and governance as a lifecycle. It’s not synonymous with systems management, because that’s just an instance of runtime. There’s the whole design time, change time, and retirement time.
Again, there's a huge possibility for the HPs of the world to knit together a nice federated solution here. There are a lot of opportunities that vendors have not exploited so far, where we could finally start to make runtime governance a real actionable component, as opposed to something in which I just look at a dashboard and then get on the phone to my systems operator.
I’d like to thank our panel for joining. These are topics I’m sure we will be revisiting. We’ve had great insight today from Jim Kobielus, principal analyst of Current Analysis; Neil Macehiter, research director at Macehiter Ward-Dutton; Dan Kusnetzky, principal analyst and president of Kusnetzky Group; Brad Shimmin, principal analyst at Current Analysis; Todd Biske, enterprise architect at MomentumSI; Morgenthal, CEO of Avorcor and Tony Baer, principal at OnStrategies.
I'm Dana Gardner, principal analyst at Interarbor Solutions. Thanks for joining. Come back next time.
Produced as a courtesy of Interarbor Solutions: analysis, consulting and rich new-media content production.
If any of our listeners are interested in learning more about BriefingsDirect B2B informational podcasts or to become a sponsor of this or other B2B podcasts, please fill free to contact Interarbor Solutions at 603-528-2435.
Transcript of BriefingsDirect SOA Insights Edition podcast, Vol. 24, on industry mergers and acquisitions. Copyright Interarbor Solutions, LLC, 2005-2007. All rights reserved.
Subscribe to:
Posts (Atom)
