News Stay informed about the latest enterprise technology news and product updates.

BEA's Carges addresses BPEL, JBI and SOA

In part two of this Q&A, Mark Carges, BEA Systems Inc.'s CTO, delves into why BEA's taking a cautious approach on BPEL and JBI and where it wants to go beyond the AquaLogic ESB.

Before becoming chief technology officer at BEA Systems Inc., Mark Carges headed up BEA's Enterprise Framework Division -- including integration and portal products -- and was one of the original architects for the Tuxedo transaction system.

part 1 | part 3

BEA has expressed reservations about both the JBI and BPEL specifications. What do you want to see from both that isn't there at the moment?

Currently, we do support BPEL import and export. We've got that. What's not there yet is a finished 2.0 spec. That's the problem. What has to happen first is we've got to finish the spec and we're working on that. There's a fellow on my team who is one of the co-authors of that and it's moving forward. The difference between prior versions of BPEL and BPEL 2.0 is there are upward incompatibilities. So the work people have done today around BPEL by definition is sort of like the early versions of EJB. When we got into a certain version of EJB, it broke a lot of things, specifically when we went into deployment descriptors. People asked what about all of the prior stuff?

So that's sort of where BPEL is at. It's very nascent still. The first thing that needs to happen is, the spec has to get settled down and it needs to get settled down in a way that you can get true portability and that's not quite there yet, even in the spec. If you build something that exports a BPEL and then something wants to import that, you've got to make sure you have that full roundtrip.

So how would you characterize the BPEL market at the moment?

I would say there has been mixed support for it if you look across Microsoft and IBM, ourselves and Oracle. It's one of those things where you also want to see broader adoption so the customers know that's something they can begin to count on and see implementations from. Some vendors are only saying they'll support import/export, but then their tools use proprietary implementations. Others are saying they'll support it natively through and through. That shows that the market is fairly immature as to what is the right way to take something like that. What it also shows then is you're getting a lot of innovation in the standards body. Innovations in standards bodies typically aren't good things.

Which is the criticism you've leveled at JBI, too, correct?

Yes, and it's also focused on system-level components. We and others are looking at it from the standpoint of whether it gains traction, as products get out on the market that comply with it. What kinds of problems are being solved? Are the right problems being solved? There's a lot of system provider interfaces, or SPIs, that are in JBI and those tend to serve smaller niche vendors because it says, 'Oh, I've got something that's JBI compliant and you can plug me in here.'

The service infrastructure vision we've laid out is much broader because we look at it and say the customer is going to need a number of different technologies. They're going to need their buses and their registries and their meta data repositories and all these different things. We look at that more holistically, and we want to provide a solution around that. For example, people don't come to us today and say with WebLogic, 'We like the WebLogic server, but we want to take out your two-phase commit engine and plug someone else's in.' It's just a level of granularity no one's interested in. They just want a two-phase commit engine to do JTA and have it all there. So we supply that and we hook it in with our JMS and our EJBs and everything works well.

Do you expect interest in that mix-and-match model to increase in the coming years?

With the level of granularity that JBI is at, we need to let the market speak back and say here's what we like. As the market speaks back and says this is what we like and demand, you'll see BEA go there. I expect that over time you will see parts of JBI -- some, most, if not all -- you'll see BEA comply with. We don't believe that if we put out a fully compliant set of products today that it would be worth our investment.

AquaLogic started out with an enterprise service where does it go from there?

AquaLogic itself is a product family with six different product lines within it, one of which is a messaging line and the service bus is in that line, along with the registry and other capabilities. Our data services platform is part of AquaLogic. There's a whole AquaLogic enterprise security piece that has some role-based entitlements. Then, as those are in place -- the messaging, the security and the data -- we've put out a vision around the types of composite apps you can build with process and portal. Once I can see my services, I can put policy on them, I can secure them, I can know who can get them, I can version them, I can lifecycle, put all the meta data around them, then I can start configuring portals or configuring business processes across the enterprise.

We've focused right now on the messaging, the security and the data, and we've put a roadmap for the other parts of the family that are the portal, user interaction for process and the composer, composer being how do I look at all of those holistically and bring all those together from a composition standpoint?

Will this eventually require you to have a native registry/repository rather than rely on a third-party vendor like Systinet?

We have the repository already, and I think you'll see those capabilities increase over time. You can put in things like transformation and routing rules and other capabilities you don't want developers to be writing in their code or in their business processes. Currently, we tie that in with Systinet's registry.

Do you anticipate that somewhere on that roadmap acquisitions will be part of the process?

Absolutely. We put out a very broad roadmap and vision with the AquaLogic family. What that allows us to do is look at what we can organically build, and it also gives us a roadmap to things we go out and buy. Something like composer is probably something we'll have to build. If we're talking about taking all these different parts and bringing them together, you can't go buy that. That's sort of the glue that brings it all together. But some of the pieces, whether it might be some of the portal pieces or some of the process pieces or some of the dashboard, some of those exist out in the market, maybe they make sense to bring in.

Dig Deeper on Topics Archive

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.