In Part one, he covered GlassFish, Open ESB, Java SE, JavaFX Script and other things Java-related to SOA and Web services.
We have not open sourced the legacy SeeBeyond products. What we are doing is all of our new development is in open source. In Open ESB, we are bringing together some of the R&D that SeeBeyond was doing and some of the R&D that Sun has been doing around JBI and JSR-208. So we're opening up that. And that is where we are doing the innovation in the integration technologies. We're doing all of that in open source. And we'll continue to develop everything in open source. We don't have plans at this point to take all of the legacy SeeBeyond code and make it open source. There are two pieces to that. Sometimes people get confused between open source and freely available. We are moving toward making it freely available, but we probably won't be open sourcing all the legacy code. How far are you from having it completely available?
It's something that we're in discussions around. Probably something like later this year. It will certainly be available with Open ESB. Is there any concern that if you do a really good job with Open ESB, you'll be cannibalizing JavaCAPS?
It's something we've given considerable thought to in our strategy. Our strategy is that our commercial product that we support and sell will continue to be JavaCAPS. What we are developing in Open ESB will be open source, but we will be taking those technologies and components that provide value to our customers and are ready to be released as a GA product and incorporating them into JavaCAPS. Looking critically at JBI, what is it that you haven't gotten right yet?
What we haven't gotten right is probably a couple things. One is we haven't gotten a commercial product to market. We can point to the [SeeBeyond] acquisition, but that isn't an excuse. We needed to get something out the door. Something related to that, partially influenced by not getting something to market as soon as we should have, we haven't done as good a job as we needed to evangelizing it. Certainly there are other commercial vendors building to it. They see the value in it, but there are major ones that are not supporting it. We continue to have discussions with them and hopefully at some point they will come out for it. Those are probably the two things we should have done better. Why is JBI still important?
It's still important because it does standardize the plumbing for an integration platform. There's significant value to that. It isn't always easy to explain to a customer. But having that standardization will give customers more flexibility and choice. With JBI, with that standardized plumbing, it allows the development of an ecosystem of vendors that offer customer choice.
Ten years ago if you wanted to do integration you had to go buy individual point products and figure out how to make them work together. Integration vendors saw that part of the problem was they needed to provide an integrated suite. So, SeeBeyond included, many of the vendors created integrated suites, but with those integrated suites every vendor was coming from a unique position. They were stronger in certain areas. So oftentimes the integration suite wouldn't do everything you needed and you'd still have to go get a best-of-breed point product to compliment your suite. So you needed integration for your integration products. What JBI provides is the ability to have a standardized platform that different vendors can support and plug into so that you can have that same integrated experience but have the best-of-breed capabilities. That's ultimately how it benefits the customer. It keeps them from having to have vendor lock-in. What's the impetus behind JBI 2.0?
JBI 2.0 moves the standard forward and implements some of the things we've learned in the past couple years around reliability and clustering. Also we believe that JBI and SCA (Service Component Architecture now in the OASIS standards process) are complimentary. So one of the things is we want to assure that we do stay complimentary. There may be things from SCA in terms of metadata that JBI can take advantage of. Looking forward, some work is beginning on Java EE 6, can you tell us anything about that and give us any timeframe for it?
The work around GlassFish v3 includes some of the things that are candidates for Java EE 6. There's a Web profile where you don't have to have the EJB container, but you can be compliant as a Java EE 6 Web profile. This is taking advantage of some of the more modular architecture. As far as timeframes, I think they're talking about late '08 or sometime in '09. Does it look as if the people working on Java EE 6 are responding to the criticism about bloat in Java EE 5 by making it more componentized?
That is absolutely part of it. Whether it's fair or not, there's a perception out there that Java EE application server is very heavyweight. There's probably some truth to that. So this is in large part a response to that. It's really looking at the market and seeing what people are asking for. There's certainly still a place for Java EE and EJB development, but clearly Tomcat -- not a full Java EE container, but a servlet container --- has widespread use. That clearly profiles that there's significant adoption of. Having a way to support that without having to have the fully Java EE stack is something that is being looked at. IBM still isn't supporting Java EE 5, is that an area of concern?
Somewhat. I don't know the exact discussions there or their plans. My guess is that they will ultimately support it. Certainly Oracle and BEA are supporting it. I think at some point IBM will be the one sticking out not supporting it and I think the market demand will move them there. In terms of the Web services stack, you have one, there's AXIS, JBoss. Wouldn't life be simpler, maybe Microsoft aside, if there was only one Web services stack?
I think so. We would love to collaborate or contribute with others in doing that. The work that we've done as part of Project Tango was done in open source. It's part of GlassFish. It's out there. Others are taking it and incorporating it in their products. So we have the beginnings of that kind of collaboration. It's been incorporated by BEA and Oracle. They're not going off and doing their own things. They see the value of collaborating. I'd like to see that. It would be a significant enabler of interoperability across the Web services platforms. That's certainly the reason we worked with Microsoft. As you say, we're not going to really have the same stack there because we're on different technologies, but assuring interoperability was the key driver in that work.
I'm peripherally involved with Project Mammoth. It's focus is on our software infrastructure products, our identity products, our business integration products. They are working to put together a collection of services and offerings that they'll be able to offer to their customers that are using our products and our technology. In the keynote (at JavaOne) you heard that governance is increasingly important as customers and businesses are building out their service-oriented architecture. They're discovering that as you have more and more services you have to have ways of managing them, and govern them, and secure them. It's something that is a key focus of Mammoth in it's early formations, but we expect there is going to be other things that are going to be identified, such as creation of a set of best practices around the use of our products. It's something we're very excited about. We're working on similar types of initiatives. It's not something we're just working on with Accenture. If I draw a picture of JavaCAPS, especially what you have for people in terms of SOA, there seems to be a hole where a registry/repository might be, are you addressing that?
Sun has the Sun Services Registry, but clearly there are other products out there that have significant market presence that we have to work with and operate with. We will be making sure that we continue to interoperate with those and support those. Are you looking to get a more robust registry/repository with support for UDDI 3.0?
Yes, we absolutely are. We haven't identified how we'll go about doing that yet. We're looking at what is the best way to do it whether that's building out what we have and working with some of the Web services organizations. In the field, we're doing implementations of our service governance framework that's providing valuable input on that.