It appears that there may be some problems in the land of Web Services. Sun and BEA got together to work on JSR-208, Java Business Integration. However, BEA pulled its support, as well as IBM in favour of BPEL. This leaves a fragmented market for developers.

Sun is still positive:

JBI is the key to Java-based SOA strategies, said Mark Hapner, a Sun distinguished engineer and J2EE architect, in Santa Clara, Calif.

"JBI will drive the shape of ESBs [enterprise service buses] much like the EJB [Enterprise JavaBeans] spec helped drive the shape of app servers four to five years ago. In short, JBI will provide to ESB and integration what EJB has provided for app servers and business logic," said David Chappell, vice president and chief technology evangelist at Sonic Software, in Bedford, Mass.

Sources said they believe IBM got involved with the JBI effort because it was the only way the company could get a look at the spec.

In addition, because JBI works to level the integration playing field, supporting JBI may not be "in [IBM's] best interest," said a source.

Sources also said BEA has a different set of issues, such as pushing more technology through the open-source community, rather than the JCP, to garner developer support for its platform.

BEA has open-sourced the development framework for its BEA WebLogic Workshop Java development environment, which is now an Apache Software Foundation project called Beehive

Read more in Defections Rattle Java Alliance

Java Business Integration is an oxymoron.

Integration may well mean integration with non-Java artifacts. A business integration framework should be platform independent.

So we need something (X) above M$ BizTalk and JBI. And when we have that, BizTalk and JBI makes no sense since X will route stuff via RPC/messaging mechanism readily in place. Whether that mechanism is WS, SOA(P), CORBA is irrelevant.

Java Business Integration is an oxymoron.

+1

Integration may well mean integration with non-Java artifacts. A business integration framework should be platform independent.So we need something (X) above M$ BizTalk and JBI. And when we have that, BizTalk and JBI makes no sense since X will route stuff via RPC/messaging mechanism readily in place. Whether that mechanism is WS, SOA(P), CORBA is irrelevant.

Yes.
I am all for integration, but it looks like even more problems lie in the business level and business mentality. There are enough technical solutions exist today to integrate businesses if they really _want_ to integrate.
Mostly they simply don’t and all that SOA looks like vendors push without real demand.

<blockquoteYes. I am all for integration, but it looks like even more problems lie in the business level and business mentality. There are enough technical solutions exist today to integrate businesses if they really _want_ to integrate. Mostly they simply don’t and all that SOA looks like vendors push without real demand.
The primary barrier to SOA adoption not a lack of business need (and, as you point out, not a lack of vendor-based solutions), it's a failure to recognize the existence of an integration problem. As long as teams responsible for maintaining disparate systems are willing to build case-specific interfaces to share data or functionality, it's not reasonable to expect an upper management layer to recognize the damage until the architecture becomes unsustainable within an acceptable cost. Once the need for an enterprise level integration solution is identified and accepted, building an SOA is a fairly common approach these days - it's a safer alternative to investing in a costly integration platform.

Similarly, building a product around an SOA model requires either the luxury of starting from scratch or a recognition of significant maintenance costs that can be alleviated by a shift towards an SOA-based product.

In either case, although an SOA can be built incrementally, it must be planned up front. As with any large-scale redesign effort, moving either a product or an enterprise to an SOA model requires buy-in at the top levels of management.

In either case, although an SOA can be built incrementally, it must be planned up front. As with any large-scale redesign effort, moving either a product or an enterprise to an SOA model requires buy-in at the top levels of management.

Horsefeathers! I recently grafted a WSDL face onto a pre-millenial ForTran batch system. The subject matter was Fermi Lab collider data. My chore was assigned to me as an orinizational afterthought, years after the legacy system was frozen.

Apache Axis makes it so easy. I don't need to author WSDL, and I can test my service without developing a client by manually typing URLs into my web browser. Axis is very amenable to Rapid Application Development practices. Eg, "Axis automatically locates the file, compiles the class, and converts SOAP calls correctly into Java invocations of your service class." That's POJO automation. Can your EJB server do that yet?

A great benefit of SOA for me is that its introduction does not need to be planned. The technology is too easy to use. Undoubtedly consulting firms would deny it.

Horsefeathers! ... Apache Axis makes it so easy. I don't need to author WSDL, and I can test my service without developing a client by manually typing URLs into my web browser. Axis is very amenable to Rapid Application Development practices. ... A great benefit of SOA for me is that its introduction does not need to be planned. The technology is too easy to use. Undoubtedly consulting firms would deny it.

Development and use of web services for any purpose (and yes, web svc development is quite simple these days) is not the same as building and governing an SOA. The latter typically involves supporting a registry for dynamic discovery of services (binding at runtime), asset management, definition and automated enforcement of policies, automated testing, versioning, and so on. Generating your interface definitions as web services using a tool like Axis does not guarantee that your service will interoperate with endpoints of other technologies, let alone fit into the bigger picture of an SOA.

So although your SOA need not be implemented in advance of services being built (in fact, I would expect the opposite to be true), it's important to have some notion of the long-term picture so that your services will fall in line with where you hope to go. Whether or not to employ an ESB is one of the decisions to be made when planning your SOA. Sun's insistence that JBI is the key to an effective ESB is one of many (mostly vendor-based) opinions.

Development and use of web services for any purpose (and yes, web svc development is quite simple these days) is not the same as building and governing an SOA. The latter typically involves supporting a registry for dynamic discovery of services (binding at runtime), asset management, definition and automated enforcement of policies, automated testing, versioning, and so on. Generating your interface definitions as web services using a tool like Axis does not guarantee that your service will interoperate with endpoints of other technologies, let alone fit into the bigger picture of an SOA. So although your SOA need not be implemented in advance of services being built (in fact, I would expect the opposite to be true), it's important to have some notion of the long-term picture so that your services will fall in line with where you hope to go. Whether or not to employ an ESB is one of the decisions to be made when planning your SOA. Sun's insistence that JBI is the key to an effective ESB is one of many (mostly vendor-based) opinions.

I agree that there must be a SOA framework above Axis. I've found Globus freeware so easy for this. It covers all of the features you mention above and is easy to roll out in an ad hoc patchwork fashion. Seriously, what's the point of a grid if services can't be spontaneously rolled out? It isn't always explained as such, but SOA shines at amorphous p2p topology, and it doesn't get more ad hoc than that.

An enterprise bus is one style of brokering services, and maybe its utility succumbs to the managerial authoritarians that dominate corporate Amerika. But there are more anarchic federations such as academic grids, where access control isn't always subject to central buraucracy. For example, I could spontaneously issue you a user certificate to my personal grid, and I could grant you the right to debut new service categories. You wouldn't have to meet me here in Boulder to take advantage of my offer of machinery. Universities collaborate like this.

I populated with custom services a newly born grid at Stanford's Linear Accelerator Center without ever leaving Boulder. My user certificate wasn't even issued at Stanford, and still it was honored. And then my office donated a computer to add to SLAC's grid. We didn't physically send the computer to Stanford. Instead we added a few entries to a property file and joined the virtual federation. No central authority ever commanded the addition of our machine to that grid. This is how Globus does SOA.

In cyberspace the services can appear and disappear at the whim of the grid's audience. The WS-* standards allow such spontaneity. WS-Resource certainly does. So rapidly protoyping and agily evolving a production enterprise system is very much spiritually accomodated by SOA. The technical alignment is good.

http://sourceforge.net/projects/mule

Above is just as good if anyone thinks they already have many ws.
.V

That's POJO automation. Can your EJB server do that yet?A great benefit of SOA for me is that its introduction does not need to be planned.

I think your view on the matter is a recipe for disaster in any but the most trivial of integration scenarios.

While adding unplanned features may cause technical problems, they can usually be fixed in some way or the other. Domain changes, however, are almost impossible to handle unless there is a clear architecture and process definition in the system.

THAT, my friend, requires considerable planning.

The fact that SOA makes it easy to wrap a function doesn't mean integration is easy. It just means it is easy to call that function (procedure/method/service/whatnot)

I doubt, however, that you have equal success if the system beeing integrated use transactions. Or use security products and protocols. Or has organizational ownership. Or......

SOA is just a limited and slow version of CORBA with tags (none of which support process integration, which appears to be JBI's mission.)

I thought that JBI is about standardizing how to plug for example a BPEL engine on top of a J2EE application server ?
Something like "we should be enabled to combine a JBI-spec compliant BPM engine with any spec-compliant J2EE app server" ?

If so, parts of the article don't make sense to me, like IBM not supporting JBI in favor of BPEL -- does not make sense to compare JBI directly to BPEL here, IMO. These two seem not to be mutual exclusive. :)

Still interesting though.

Matthias

BPEL Engines would comply with BPEL Spec in executing the Workflows. And JBI Spec would define how the BPEL Engines would be integreted with J2EE Servers.

The Reason IBM, BEA do not want to support this might be to support BPEL in their own proprietary way in their APP Servers and not to be tied with another J2EE Spec and thus being compliant to Sun Standards.

However, reading through the draft I can understand why App Server vendors would be hesitant to support it. (disclosure: I work for BEA, but not in a capacity to make these types of decisions).

First, the draft states very clearly that this JSR is not designed for end-user application developers, but instead for Software Vendors. From the draft:

<quote>The primary audience for this specification is system level software engineers with experience in developing containers, execution engines, process engines, [etc.]. ... JBI does not define an application programming model but rather defines a set of SPIs that enable the development of ... “containers�</quote>

Does anyone think that end-users would be more interested in plugging different Web Services containers or BPM containers into WebLogic than they are in plugging in different Web containers or EJB containers? While there may be circumstances where plug-and-play at this level is useful, my experience has been just the opposite.

I suspect that, given the choice, most users would say that API-level (artifact) portability is much more important than container pluggability. That's where BPEL comes in. BPEL and BPELJ should give users the ability to port their processes from one platform to another without having to move the entire BPM container.

Web service container funcionality has already been more or less standardized at the API and deployment level. Data transformations should be just as portable via XQuery standards.

The other area JBI touches is connectivity. The idea as I understand it is to define a standard connector interface (binding components or BCs) and build an abstraction mechanism between the various containers and the BCs via a "Normalized Msg Service" (or NMS). On the connector side, JCA seems to be evolving sufficiently to support most needs. As for an NMS, I would be worried about the ability of the AppServer vendor to do suffient tuning to garantee throughput.

BOTTOMLINE: I don't see any end-user advantages to creating the plug-and-play container environment envisioned by this JSR. The current focus of BEA and most vendors is to provide artifact portability (via BPEL, XQuery, etc.) and standards-based connectivity while maintaining a secure, configurable, and performant execution environment.

BOTTOMLINE: I don't see any end-user advantages to creating the plug-and-play container environment envisioned by this JSR. The current focus of BEA and most vendors is to provide artifact portability (via BPEL, XQuery, etc.) and standards-based connectivity while maintaining a secure, configurable, and performant execution environment.

There are a lot of advantages for the end-user (the client) to have plug and play container environment for BPEL in the existing J2EE APP Server Scenario. This would encourage multiple vendors to provide Service Oriented Products on top of exisiting J2EE Servers and free them from Vendor Lockin for the entire stack of solutions.

The way to see this is, In General, All Workflow Oriented Or Process Oriented Or Service Oriented Systems including BPEL is an extension to the current Object Oriented Systems and if needed can act as a Facade to the underlying APP Servers. There I really need a choice to Plug and Play different BPEL Containers on Existing J2EE Servers.

Does anyone think that end-users would be more interested in plugging different Web Services containers or BPM containers into WebLogic than they are in plugging in different Web containers or EJB containers? While there may be circumstances where plug-and-play at this level is useful, my experience has been just the opposite.I suspect that, given the choice, most users would say that API-level (artifact) portability is much more important than container pluggability. That's where BPEL comes in.

I actually believe that end-users would be interested in the plug-in capabilities JBI offers, although I don't believe that plugging in 'different Web Services containers' would be the most common case.

I understand that JBI defines three major components or building blocks: Binding Components (BCs) for connectivity, Services Engines (SEs) allowing for the deployment and execution of services provided by end-users (or third-parties), and the NMS connecting all of these.

Users will be interested in plugging specialized BCs supporting industry-specific or proprietary protocols and data formats. App server vendors are unlikely to have an interest in supporting all existing formats, i.e. there exist plenty of niche markets for third-parties providing such BCs; a standardized SPI will be extremely beneficial here.

The same is true for SEs: again, switching from the app server vendor's BPEL engine to someone else' BPEL engine will probably not be the most interesting use of this plug-in capability. On the other hand, being able to plug-in specialized service engines, e.g. for transformations of industry-specific or proprietary data formats, will prove beneficial.

So I agree very much with your assessment that JBI and BPEL are not mutually exclusive, but I disagree with the conclusions you draw about the usefulness of JBI plug-in capabilities for end-users.

BTW, the spec says that a JBI environment is confined to a single JVM; therefore, the NMS connects components within a single JVM, too. Why would there be major performance/throughput concerns for the app server vendor?

Kind regards,
Oliver Kamps (an end-user)

Let's take these one at a time.

First, what do you think the BC model offers that cannot be solved by JCA? Industry-specific connectors (like SWIFT, HIPAA, etc.) are being developed as JCA adaptors today. Web Services offer a fairly universal access model, albeit devoid of connection pools and other optimization knobs today. For more Java-oriented abstraction Apache Beehive Controls show how Java 1.5 annotations can be used to mark-up POJOs that can encapsulate any data access/business logic need.

As for SEs, while I can see some advantages to offering a pluggable container mechanism, I don't think they are unique to Business Integration. Any IoC use case could be considered a potential candidate for an SE. I think the IoC community today is way too scattered both technically and philosophically among the various OS projects under development to try to create and maintain standards for IoC plug-ins inside the app server. Many of the IoC projects underway today can work perfectly inside an App Server without the need for a standard.

Finally, my resistence to NMS is not based on whether or not it's technically possible to do, but more to the fact that it's a universal mechanism within the architecture. As I participate in more and more integration projects, the idea of a universal message service that handles every integration use case seems futuristic. Any 1.0 spec would likely be designed to handle a certain set of integration use cases, with other cases being difficult or impossible to implement in a scalable fashion without breaking the standard.

I think that it makes sense for the App Server vendors to focus on JCA, BPEL and other end-user integration standards for the moment. Once some of the basic artifact portability standard have been defined, then the vendors can see what interoperability and extensibility issues are left to solve.

Just my 2c.

You questioned whether end-users were interested in container-level/SPI-level plug-in capabilities, and a few people came out in favor.

I believe that JBI takes an interesting step in what looks like the right direction; the EG is soliciting feedback on their work.

With regards to JCA, this is the J2EE Connector Architecture, and JBI does not want to rule out J2SE implementations (although the EDR states that J2EE is expected to be the most frequently used platform). I don't think that's a bad thing.

If you or the application server vendors think that there is a significant overlap between the BCs and JCA, then this is something that should be discussed and dealt with in the expert group and, upon agreement, in the spec. (But I don't see how leaving the EG is a constructive contribution to the discussion.)

The essence of your post is very similar to other threads on this site: someone has an issue with the approach taken by JSR-n. Therefore, JSR-n is bad/irrelevant/not-what-end-users-are-interested-in and should be abandoned.

Err, no. Having an issue with the approach taken by a JSR is fine. Commenting on this is fine. Not supporting or not implementing the spec is fine. Saying it is not relevant to you or your customers is fine.

But why can't the people who apparently care about it (and believe their customers care about it) run with it? What damage does this do to anyone else?

Kind regards,
Oliver

Oliver

Don't get me wrong. Again, my posts are personal interpretations of how I'm reading the spec and how I think it fits with what my customers are doing.

Obviously, there are people who believe that JBI has its place in the J2SE and/or J2EE landscape.

My original point (maybe not stated as clear as could be) is that, while BPEL and JBI do not exclude each other, to me it makes more sense to focus on BPEL and other APIs at the moment and define what's needed in terms of pluggable container functionality once you actually have users deploying integration solutions on the platform. If not, you run the risk of overarchitecting something that never gets used.

I never recommended abandoning JBI or the concepts behind it. However, I probably would be in favor of splitting it into separate JSRs, possibly like:

1. JCA++ - evolution of existing connector architecture.
2. IoC plug-ins - creating a standard way of plugging new containers into the App Server. This may turn into a non-issue depending on how annotations evolve in the platform.
3. Msg Broker - creating standard MB functionality on top of JMS.

That way, JCA and JMS could continue to evolve as they have been while the pluggable container concept would be treated on an independent basis.

I'm not stopping anyone from "running" with JBI. I just think that the EG has a huge undertaking to actually get concensus and an RI with the currect scope of the spec. I could be wrong... ;-)

Cheers

Monte

With regards to JCA, this is the J2EE Connector Architecture, and JBI does not want to rule out J2SE implementations (although the EDR states that J2EE is expected to be the most frequently used platform).

JCP.org claims that JBI exclusively targets J2EE. This resonates with the complaint that features of JBI needlessly duplicate existing features of J2EE, such as JCA.

I appreciate Monte mentioning IoC. Why not a JSR for general purpose IoC? EJB, Servlets, and JBI could specialize it. Does generalized IoC belong in J2SE or J2EE?

However, BEA pulled its support, as well as IBM in favour of BPEL.

I think you hit the nail on the head Dion. BPEL seems to be the way people are going. I've spent some time getting up to speed on our BPEL Process Manager (Oracle acquired Collaxa in June), and it's impressive. Moreover, I'm surprised at how many people are in production mode with our and other BPEL implementations. Lots of BPEL info here.

 - Don

We do not even have a WS "standard" adopted by a majority yet.
JMS? Jabber? Google? Rest? Soap?? Hessian? Beep? etc?

No need for ESB or BPEL describing it yet.

.V

Does anyone else see the irony that Sun, IBM, and BEA can't come together in Business Integration?

On the note of needing something (X), has anyone considered Webden Interactive's BIE?