In synchrony with recent announcements about the significant progress of the SOA story here at JBoss, the jBPM team is happy to present the release of jBPM BPEL 1.1.Beta2, our web services orchestration offering. This release affirms our commitment to open standards and, more importantly, to the requirements of our community. It is the last beta version before the GA release in October.

The software entered beta stage in June, but development started way back in November 2004. At that time, BPEL4WS 1.1 was a generally available specification for defining business process behavior based on web services, whereas WS-BPEL 2.0 was in progress at OASIS. Gaps and ambiguities in the former specification made it hard to interpret for users and implementers alike. The OASIS draft addressed many of the issues, but was under constant revision.

To cope with this situation, we opted for adhering to WS-BPEL 2.0 semantics while preserving the ability to read 1.1 documents. JBoss was already an OASIS member, so I had the opportunity to join the Technical Committee, track the changes and participate in the discussions. WS-BPEL 2.0 just entered public review status on September 10, 2006.

Thanks to the involvement of our customers and the community during this time, we are building a solid product that meets real expectations and polishing the rough edges before they make it to the final product.

Look out for the following features in the second beta release:

• Support for temporal activities: sleeping, alarm-based routing and time event handling.
• Ability to deploy and run processes defined with jPDL (our language to implement workflow and BPM in Java) along BPEL processes in a single installation
• Verified compatibility with JBoss AS 4.0.3 and 4.0.4. In version 4.0.4, a brand new web services stack replaced the earlier implementation, derived from Apache Axis.
• Simplified development procedure. The product uses JMS queues to control request/response traffic. By introducing a default queue, developers need not concern themselves with JMS at all. Deployers may still use multiple queues for scalability in production.

Enjoy!