JBI 2.0 : Composite Materials

Friday Apr 14, 2006

JBI 2.0

It has been almost a year since we completed JBI 1.0. What do we do for an encore? Do JBI 2.0, of course!

If you are attending JavaOne 2006 in San Francisco, please bring your JBI "wish list" to the following BoF (Birds of a Feather) session:

Session Id: BOF-0089
Session Title: What's Next for Java™ Business Integration (JBI)?
Track: Core Enterprise
Room: Franciscan I
Date: 17-MAY-06
Start Time: 21:30

If you've been living with JBI 1.0 for the last year, as an implementor, component developer, or application developer, we want to hear from you. We want to make sure that we take JBI 2.0 in directions that are important to the current users of the technology. So bring that wish list, and the beverage of your choice (it will be 9:30 PM, after all!).

Posted at 06:40PM Apr 14, 2006 by rtenhove in Java Business Integration | Comments[3]

Comments:

Thanks Ron, here are some thoughts:

Optional security contracts, especially for lifecycle management.
Service and/or ServiceInstance java interfaces. Currently, in my point of view, a service in JBI is purely logical, and exists physically only in the WSDL. If a component is declaring multiple interfaces and defining multiple implementations as services, to bring down a specific service, you can, for example, bring down the service unit that initiated it, bring down the whole component or invoke the component specific exposed JMX beans’ operations. Practically, not all services will be initiated using service units, and bringing down a component would bring down all associated services.
Message persistence support.
Can we have a way for the container to expose its currently active services to external clients? May be the required SOAP component can help.

Posted by Hossam Karim on April 20, 2006 at 01:15 AM EDT #

Hossam,

Thanks for the suggestions; I'll add them to our list. A quick question for clarification: When you mention security contracts (esp. for life cycle management), are you suggesting something other than the standard JMX security features, and equivalent security for other management interfaces (like Ant)?

Best regards,

Ron

Posted by Ron Ten-Hove on April 25, 2006 at 08:42 AM EDT #

Yes. I think we need a component management level security as well as the current protocol management level, like overloading the start method to accept a Subject as a parameter. What I think is needed practically is to allow the container’s user to access only specific operations on specific components with an arbitrary authentication and authorization method specified by the component. You always say “JBI is a container of containers”, so we need to specify the security model of the parent and its children as well.

Posted by Hossam Karim on April 28, 2006 at 11:00 AM EDT #