|
Sponsored Links
Resources
Enterprise Java
Research Library
Get Java white papers, product information, case studies and webcasts
|
News
News
News
|
Messages: 14
Messages: 14
Messages: 14
Printer friendly
Printer friendly
Printer friendly
Post reply
Post reply
Post reply
XML
XML
XML
|
 |
Java Business Integration JSR passes final ballot
JSR-208, Java Business Integration (or JBI), has passed the final ballot, with two abstentions from BEA and IBM. JBI is a specification that addresses standardization integration of services, with a preview available hosted on http://java.sun.com/.
All members of the executive committee voted "Yes," with the exceptions of BEA and IBM. BEA's comment on the abstention was:
BEA believes that the JBI specification is an incomplete attempt to standardize the interfaces between multi-vendor infrastructure and contributes little to the usefulness of the Java platform for business application integration, one of the real pain point for our customers. It's unfortunate that it's name alone will result in significant confusion in the marketplace.
IBM also believed the spec was "not a sufficient step forward."
However, companies such as TIBCO are banking on JSR-208 for the integration of service-oriented architectures for their "Hermes" project (due in 2006), for example. This product was described as follows: "Hermes reduces the cost and complexity of implementing and administering an enterprise-class SOA by giving developers a consistent but extensible way of deploying and managing home-grown and third-party services both independently and as part of composite applications."
This capability seemed directly tied to the use of JSR-208, which implies that JBI is a workable definition of a standardized SOA for Java.
What do you think? With IBM and BEA abstaining on many JSRs lately, often for the similar reasons as expressed in this JSR, is their abstention meaningful? Do you think you might be leveraging something like JSR-208?
|
|
|
Message #175415
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Java Business Integration JSR passes final ballot
Carlos has a good analysis of IBM and BEA's comments here...
http://www.manageability.org/blog/stuff/jbi-containers
I think JBI (JSR 208) is going to be a very important standard in the integration, ESB and EAI space and we are busy implementing an open source, Spring based JBI container and component suite called ServiceMix.
So far we've support for JMS, HTTP, SAAJ, WSIF, XSLT, Groovy/JSR 223 and Mule with much more to come...
James
LogicBlaze
|
|
|
Message #175424
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
ObjectWeb ESBi, Celtix and JBI
Iona joined ObjectWeb and announced the Celtix project on June 21, 2005 (the news is stuck somewhere in TSS, for some reason...)
"Part of that core functionality in Celtix will be support for the recently introduced Java Business Integration (JBI) specification developed within the Java Community Process (JCP)."
"IONA anticipates that the community will deliver an initial release of Celtix by the end of 2005, providing the industry with an open source Java ESB that can help drive adoption of Service Oriented Architecture (SOA)-based projects and promote the incremental adoption of this computing methodology in the enterprise.
See: http://os3g.blogspot.com/2005/06/esb-initiative-welcomes-new-member.html
http://www.objectweb.org/phorum/read.php?f=25&i=199&t=199
|
|
|
Message #175426
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Curate's egg
An important and necessary spec, but..
1. It requires components to implement standard interfaces
2. It requires xml deployment descriptors
3. It uses a special format jar archive as the unit of deployment.
Sounds familiar?
While the EJB world appears to have learnt from its mistakes and is moving away from imposing excessive constraints on EJB code, JBI appears not to have noticed.
Business logic/entities should be POJOs. Funny how the best open source projects realise this (eg ServiceMix), while as soon as you have a JSR, they straightaway want to tie developers hands.
Still, as I say it is important. May it flourish.
Kit
|
|
|
Message #175431
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Curate's egg
An important and necessary spec, but..1. It requires components to implement standard interfaces2. It requires xml deployment descriptors3. It uses a special format jar archive as the unit of deployment.Sounds familiar?While the EJB world appears to have learnt from its mistakes and is moving away from imposing excessive constraints on EJB code, JBI appears not to have noticed.Business logic/entities should be POJOs. Funny how the best open source projects realise this (eg ServiceMix), while as soon as you have a JSR, they straightaway want to tie developers hands.Still, as I say it is important. May it flourish.Kit
I totally agree - though I do think those 3 things are necessary for now. There does definitely need to be a deployment unit so folks can drop components inside a container - e.g. so a BPEL component can just drop right into any JBI container, just like a JMS provider's RARs can drop into any J2EE app server.
However I can also imagine JBI being used in regular Tomcat/Spring style deployments where the JBI components are wired together as part of a regular Spring configuration to avoid the need for a JBI specific deployment unit. e.g. see ServiceMix's Spring support
I'm sure in future versions of JBI we can further simplify the developers life using annotations and a more POJO approach like Spring/EJB3. In ServiceMix we support POJOs - though we currently expect developers to implement the ComponentLifecycle interface from JBI (which is a pretty simple interface - even simpler than servlets - it just provides the necessary hook to the POJO to be able to interact with the container and its lifecycle).
Considering how bad EJB 1 was (it took 3 versions to get anywhere near a good spec :) I think JBI is a great piece of work for a 1.0 - but for sure we can make it better in future versions.
James
LogicBlaze
|
|
|
Message #175439
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Curate's egg
I totally agree - though I do think those 3 things are necessary for now.
Possibly, though it might be seen as inviting developers to go down a route that could end up as a dead-end.
There does definitely need to be a deployment unit so folks can drop components inside a container - e.g. so a BPEL component can just drop right into any JBI container, just like a JMS provider's RARs can drop into any J2EE app server.
I would argue that RARs from a JMS provider have a very different role from business logic developed for internal consumption. The latter is more likely to be regularly revised. But in truth the deployment unit isn't my major gripe. It's the standard interfaces v POJOs thing.
However I can also imagine JBI being used in regular Tomcat/Spring style deployments where the JBI components are wired together as part of a regular Spring configuration to avoid the need for a JBI specific deployment unit. e.g. see ServiceMix's Spring supportI'm sure in future versions of JBI we can further simplify the developers life using annotations and a more POJO approach like Spring/EJB3. In ServiceMix we support POJOs - though we currently expect developers to implement the ComponentLifecycle interface from JBI (which is a pretty simple interface - even simpler than servlets - it just provides the necessary hook to the POJO to be able to interact with the container and its lifecycle).
Sounds great! even nicer (IMVHO) the ComponentLifecycle interface could be layered on top of my latest killer POJO using Springs aspects :)
Considering how bad EJB 1 was (it took 3 versions to get anywhere near a good spec :) I think JBI is a great piece of work for a 1.0 - but for sure we can make it better in future versions.JamesLogicBlaze
With my "Hypocrites-R-Us" hat on, I certainly doubt I could have done any better :) Good luck.
Kit
|
|
|
Message #175479
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Curate's egg
An important and necessary spec, but..1. It requires components to implement standard interfaces2. It requires xml deployment descriptors3. It uses a special format jar archive as the unit of deployment.Sounds familiar?While the EJB world appears to have learnt from its mistakes and is moving away from imposing excessive constraints on EJB code, JBI appears not to have noticed.
Ditto, I got extreme EJB flashbacks reading the spec (which I have done over a couple of times over the last few weeks).
Personally I think going down the route of mandatory implementation of specific interfaces etc is a step back from a lot of frameworks that allow components to be simple POJO's.
I don't quite see how anything can be "less standard" than just using POJO's..
However, that being said, I think JBI does have a lot of good concepts going for it to standardize how a service-container should be built.
If only the rough edges around creating and deploying Services can be shaved down it might be really great in the future (take away the interface-dependencies!!).
|
|
|
Message #175495
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Comment on IBM and Bea Absence in Voting
Just as thinking aloud - I am wondering if the logical progression will be to have splintered applications connected via JBI that perform today's app server tasks.
JBI allows vendors to host their software as a service (one of the benifits). Would there be an opportunity for future application servers that are hosted on remote ASP locations to integrate millions of client web applications using JBI. Borrowing the Walmart store concept, can we envision a business model with few portals hosting zillions of web sites (think of products in Walmart Store), all connected via JBI to their parent applications. Does this model help BEA and IBM or the IT folks who want move their applications off to a third party ASP and have just the business processing modules hosted on their local systems? Isn't a third party ASP better suited to solve high availability/upgrade issues for all IT folks?
Disclaimer: I am not planning to start ASP business
|
|
|
Message #175521
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
2 layers of interfaces (was standard interfaces)
One clarification: the JBI spec/API/SPI is not targeted at application developers but instead container developers.
If you take the BPEL example, software vendors implementing a BPEL engine would implement the SPI under the cover. The application developer does NOT need to know about the JBI API. He only implements his BPEL process. As the BPEL engine interprets the BPEL process and calls out to the services defined in the BPEL process definition, the BPEL engine calls to JBI and delegates binding to the service to the JBI layer.
The same thing is would be true for transformation engines, rule engines or any other engine that you would plug into your environment.
Summary: if you are an application developer you should never see the JBI API. The only API you are exposed to is the WSDL of the service you are invoking or waiting a notification from and there again you should only care about the abstract definition (port and message type), NOT the binding.
Hope this helps,
Edwin Khodabakchian
Oracle
http://otn.oracle.com/bpel
|
|
|
Message #175524
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
2 layers of interfaces (was standard interfaces)
Summary: if you are an application developer you should never see the JBI API. The only API you are exposed to is the WSDL of the service you are invoking or waiting a notification from and there again you should only care about the abstract definition (port and message type), NOT the binding.
And we all know how likely that is going to be.. :)
So what really is the benefit of JBI besides "vendor-independence" in an enterprise SOA scenario?
If application developers are not supposed to see the JBI API, it's not very likely JBI is supposed to be the Service Container of an organizations specific Services is it?
What is the purpose of JBI beyond "vendor-independence" from the viewpoint of an end-user organization? And what is the benefit of a JBI Service over a Service that drops in nicely into a J2EE container, has a clean WSDL interface and is exposed in a location transparent way?
The more I read up on this spec and the more I hear people talk about it, the more it sounds to me like useless bloat. Unless of course you call ticking the "JSR 208 compliant product/framework" box a "benefit" (a box which many, probably including myself will try to tick just to appease the "standards" hungry out there).
Ok, maybe overly tough words, JBI does have some really good and useful concepts that are worth looking into and keeping an eye on with that being said.
I am just trying to get a feel for the justification and benefit of it beyond "vendor independence" for BPEL engines etc..
|
|
|
Message #175642
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
I don't buy it
I read the spec in May. I was pretty excited about it until I saw things like:
“WSDL-based Messaging Model”.
Honestly, can someone please just shoot WSDL and SOAP and get it over with? I mean it's hell. Shoot all of the WS-* specs. Just stop it – stop the madness. Its evil! Its wrong!
Also, the “Service Invocation and Message Exchange Patterns” are:
One-Way
Reliable One-Way
Request-Response
Request Optional-Response
What about pub/sub? Just how flipn' hard can we make RPC?
I also saw this in the “Future Directions” section:
•Distributed JBI. JBI, as currently defined, is not distributed. Distributed implementations may require support in the JBI specification to address issues that arise only in distributed systems.
Seems to me this should be the whole point? I mean how to tie these things together. Like JBI .. Java Business INTEGRATION ... Like distributed computing and stuff?
Perhaps I'm just a moron and don't get it. But, it just didn't smell right. Just seemed all coupled and weird to me.
I know its easy to say IBM and BEA just don't want to play, but neither of them has an ESB that is much of anything so I fail to see why they wouldn't jump on board. I think that they might just be right!
I have to agree with them.
|
|
|
Message #175710
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
I don't buy it
I read the spec in May. I was pretty excited about it until I saw things like:“WSDL-based Messaging Model”.Honestly, can someone please just shoot WSDL and SOAP and get it over with? I mean it's hell. Shoot all of the WS-* specs. Just stop it – stop the madness. Its evil! Its wrong!
Relax :). The logical WSDL model is fine - that of services, interfaces, operations and bindings/endpoints. Seriously, there's nothing wrong with that. JBI just uses the logical model, its not bound to the pointy bracket stuff. e.g. JBI can work well with pure HTTP / JMS without all the SOAP/WSDL XML stuff. In ServiceMix we use JBI to route JMS messages across providers/destinations with message transformations etc. There's no reason that the JBI API and model can't work well for pure REST stuff too.
Also, the “Service Invocation and Message Exchange Patterns” are:One-WayReliable One-WayRequest-ResponseRequest Optional-ResponseWhat about pub/sub?
The JBI MEPs work just fine for JMS support and WS-Notification (the WS equivalent of pub-sub) which we use just fine in ServiceMix. So pub/sub works well in JBI.
Just how flipn' hard can we make RPC?
With bindings for reflection, WSIF, Axis and ActiveSOAP - RPC works just fine with JBI. I don't really grok your problem?
I also saw this in the “Future Directions” section:•Distributed JBI. JBI, as currently defined, is not distributed. Distributed implementations may require support in the JBI specification to address issues that arise only in distributed systems. Seems to me this should be the whole point? I mean how to tie these things together. Like JBI .. Java Business INTEGRATION ... Like distributed computing and stuff?Perhaps I'm just a moron and don't get it. But, it just didn't smell right. Just seemed all coupled and weird to me. I know its easy to say IBM and BEA just don't want to play, but neither of them has an ESB that is much of anything so I fail to see why they wouldn't jump on board. I think that they might just be right!I have to agree with them.
I wonder if taking a look at ServiceMix might help you grok JBI?
James
LogicBlaze
|
|
|
Message #175795
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Plug for ServiceMix
This entire discussion is focused on the need for the spec and how it seems not ready for prime time/is a rehash of other painful implementations. The whole point of having a spec like this should be to make life easier, not harder.
Bob brought up several points regarding what he saw as deficiencies in the spec and it seems the best answer given is, "Hey, look at my product." It's nice that you have a product, but that doesn't change the fact that the spec still has issues.
|
|
|
Message #175797
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Plug for ServiceMix
This entire discussion is focused on the need for the spec and how it seems not ready for prime time/is a rehash of other painful implementations. The whole point of having a spec like this should be to make life easier, not harder.Bob brought up several points regarding what he saw as deficiencies in the spec and it seems the best answer given is, "Hey, look at my product." It's nice that you have a product, but that doesn't change the fact that the spec still has issues.
Bob thinks the spec has issues (e.g. for pub/sub and RPC) which I don't think really are issues - its just a misunderstanding of the spec & how it maps to those technologies.
Sometimes seeing some code is the easiest way to explain how an API is meant to be used - so my point, which I obviously didn't explain too well - was that by looking at the source code of ServiceMix you can see how pub/sub, JMS and RPC can be used with the JBI specification.
i.e. I don't think the JBI specification has any problems working with JMS, pub/sub or RPC - if you don't believe me there's plenty of source code to read to see how it all fits together.
James
LogicBlaze
|
|
|
Message #175942
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
My O My
Just been to a JavaOne talk about that stuff. If it is anything near the presentation, I'll stay away from it. After all, after about an hour, it was not clear what it is, what it has to do with Java, what it is good for, and why it is good.... Instead I now know that it requires WSDL (wonder why) and that it supports four trivial interaction formats. Whew. As Maggie Thatcher said: I want my money back!
|
|
|
| New content on TheServerSide.comNew content on TheServerSide.comNew content on TheServerSide.com |
|
|
Reza Rahman explores the features of the proposed JSR 299, Contexts and Dependency Injection for Java EE (CDI). When approved, it promises to be a key feature of Java EE 6.
(November 2, Article)
SAML is an XML-based standard for exchanging authentication and authorization data between security domains. The single most important problem that SAML was created to solve is the Web browser Single Sign-On problem. Many organizations are debating whether to stay with version 1.1 or move to 2.0. This article makes observations about both options.
(September 28, Article)
Joe Ottinger takes a look at how people learn, and applies it to the practice of programming. He notes that understanding how people learn is an essential part of working in a programming team.
(September 22, Article)
Stephen Maryka gave us an article about the Asynchronous Web and posed a number of questions that get examined like an approach to delivering Asynchronous Web capabilities through extensions to existing Java EE technologies.
(July 14, Article)
JavaServer Faces Flex goal is to provide users capability in creating standard Flex components, part of flexSDK which is open sourced through MPL license, as normal JSF components. This article by Ji Hoon Kim will provide an overview of creating a simple multilingual JSF page consisting of JSF Flex tags.
(June 29, Article)
In this session Jeff explores the key characteristics of successful SOA projects. He covers some of the patterns, and anti-patterns, tool sets, and strategies that he himself learned the hard way. Last, he provides a strategy and blueprint for achieving a high likelihood of success in your SOA project.
(June 23, Tech Talk)
Ari Zilka, CTO of Terracotta, Inc., talks about the new features in Terracotta 3.1, announced during JavaOne and available now.
(June 15, Tech Talk)
In this Tech Talk, Josh Long explores an integration challenge using Spring Integration and walks through the implementation, employing and expanding on the basic patterns of Enterprise Application Integration to tie together components into a function integration solution, and then demonstrates how Spring Integration helps address the integration requirements.
(June 15, Tech Talk)
In this Tech Talk, David Geary teaches you: The basics of Google Web Toolkit; How to implement Ajax-enabled applications in Java; Internationalization; Hooking into the browser history mechanism; Remote procedure calls.
(June 4, Tech Talk)
Jon Kern discusses the best architecture/technical solutions and ensure that they are repeated by all developers. By tackling the architecture up-front in a serial manner, subsequent parallel development will be much more manageable and predictable.
(May 28, Tech Talk)
This keynote describes the frustrations of modern knowledge workers in their quest to actually get some work done, and solutions for how to guard yourself against all those distractions. Neal Ford talks about environments, coding, acceleration, automation, and avoiding repetition as ways to defeat the misguided attempts to sap your ability to produce good work.
(May 26, Tech Talk)
Gil demonstrates how new, aggressive uses of already abundant compute capacity by common applications offer competitive value for application designers.
(May 21, Tech Talk)
Chris Keene introduces WaveMaker as a new way to automate the ability to generate Hibernate classes in order to more quickly bring OR mapping into an application.
(May 19, Article)
In this session Nati Shalom demonstrates how to take a standard Java EE web application and scale it out or down dynamically without changes to the application code. Seeing as most web applications are over-provisioned to meet infrequent peak loads, this is a dramatic change because it enables growing your application as needed, when needed, without paying for unutilized resources.
(May 19, Tech Talk)
Mastering EJB was one of the original and most influential EJB books in the industry. Mastering EJB III now returns with two new expert co-authors, updated for EJB 2.1 and 30% new chapters including security, integration, best practices, open source, and more.
(Book PDF Download)
The Application Server Matrix is a detailed listing of J2EE vendors and their application server products, with information on latest version numbers, J2EE spec support and licensing, pricing, platform support, and links to product downloads and reviews.
(Application Server Comparison Matrix)
|
|
