Linux.com

Further, a BEA executive close to their BPEL work told Open Enterprise Trends that BEA intends to provide a reference implementation of BPEL J to the Java/J2EE community and may provide this royalty-free and as open source.

"BEA will write and provide a reference implementation of BPEL J. Depending on demand and the evolution of the specification, we will also consider making this implementation open source and royalty-free. We're very serious about it. We want this to be very portable across the Java platform," said Stephen Hood, BEA product manager for WebLogic Integration.

To get more perspective in BPEL J, we spoke in depth with Hood. He addresses the genesis of BPEL J, how it will help developers implement BPEL, and what assurances are in place to make sure that BPEL J doesn't undo any interoperability between Java and .NET orchestration.

Inside the workings of BPEL J

Today, BPEL4WS continues to grind through the standards-setting process at OASIS. Hood insists that BPEL J is not too early, and that BPELJ and BPEL can be worked on in parallel. BPELJ "is a reflection that BPEL will happen, and we hope it will happen this year. Too many vendors want it to happen."

In specific, BPEL J is a joint submission from IBM and BEA that will amend JSR 207 within the Java Community Process (JCP) will not derail the BPEL work. The proposed extensions in BPEL J will enable Java and BPEL to cooperate by allowing sections of Java code, called Java snippets, to be included in BPEL process definitions. Snippets are expressions or small blocks of Java code that can be used for things such as, but not limited to, the following:

• Loop conditions
• Branching conditions
• Variable initialization
• Web service message preparation, and
• Logic of business functions

In addition, BPEL J makes it possible to for J2EE developers to create business processes that include both Web services and currently-existing traditional J2EE business components.

Further, Hood said, BPEL J will not splinter the existing alliance between Java and Microsoft .NET over BPEL. "BPEL as a broad execution language standard was not envisioned to work 'as is' for specific language implementations. BPEL J is our take on how it should work in Java," Hood said, noting that Microsoft would also likely have to draft some .NET-specific implementations for BPEL within .NET.

What follows is a quick-reference FAQ for the status, workings and intent of BPEL J. A look at how BPEL J will be implemented in Java/J2EE, and how it affects developers and interoperability with non-Java systems is also addressed.

OET: How would you describe the differences between BPEL and BPEL J?

Hood: BPEL is a language for orchestrating existing Web services into business processes. Look at the problem: What BPEL is supposed to do is deal with core logic, so it makes several assumptions: (a) Everything you talk to is a Web service; and (b) Everything you interact with is an XML or a formatted document. BPEL sticks with core high-level logic, rather than drilling into deeper, finer-grained, technical issues, such as data manipulation, procedural logic, and integrating with non-Web services interfaces.

OET: And these "deeper" parts of the spec are where BPEL J comes in?

Hood: These deeper topics are out-of-spec for BPEL, and if they weren't, we'd never be done. As it stands, the BPEL work at OASIS is far enough along that we can now begin working on those deeper issues, which will be dealt with in terms of implementing BPEL for each language. BPEL J is for implementing BPEL for Java.

OET: Aside from the BEA/IBM whitepaper, does the Java community need a reference implementation of BPEL J?

Hood: The JSR 207, entitled "Process Definition for Java," was submitted to the JCP by BEA about a year ago or so, and it’s designed to answer the question: How does Java relate to process languages?

In JSR 207, what we did a year ago was submit a starting point by referencing technologies included in our WebLogic Integration product similar to BPEL J. Since the submission of JSR 207, we’ve worked with IBM to define an implementation for BPEL, which we've called BPEL J. The BPEL J implementation is pretty much the same approach as we proposed in JSR 207, except it uses BPEL and looks to solve the problem of how to interact between Java and other process languages.

It is our hope and goal that BPEL J be standardized as a part of JSR 207 and that that will be the venue for any changes to the specification as it approaches standardization. It's early, but we've worked pretty hard with IBM on this and are pretty confident the 207 group will consider it very, very closely. IBM has co-authored this work, and as written, we believe this spec is ready to go. But, we anticipate there will be some changes, and that's fine.

OET: What was missing between the original JSR207 and your BPEL J proposal?

Hood: Technically, BPEL J defines an idea called Java snippets. It defines exactly the way you can use those in a BPEL process to accomplish fine-grained procedural logic.

OET: What do these "Java snippets" look like to a Java developer? Do they resemble any current objects/artifacts in Java?

Hood: Java snippets look like simple Java code, and they can take a number of forms. You can put a few lines in of Java in line in your process (e.g., preparing a call to a business partner) constructing a call in BPEL to a Web service to use a couple of lines of Java to help me construct the document I'm sending. You can also have an external [Java] Bean essentially, by writing Java of arbitrary complexity and reference it.

OET: How does BEA envision the use of "Java snippets"? Would developers use wizards or other code generation techniques? Or would they build these "snippets" on their own?

Hood: We expect they’ll work in much the same way our process language in WebLogic Integration works today. You drag and drop nodes to build a process diagram, which in turn generates an XML syntax of our own creation that describes the diagram. In BPELJ, [that syntax] will be a BPEL syntax.

OET: That's a bit deeper support for business process than exists in today's BEA WebLogic Integration products, isn't it

Hood: In our current WLI, we don’t have a rules engine, but we target [support for that] with third parties, such as ILOG.

OET: What do you expect will be the impact of business rules and/or process training for Java developers? Can BPEL or other technologies on business process offer Java devs an opportunity to train on business process?

Hood: The answer is definitely "Yes." The E in BPEL stands for execution. BPEL is a programming language. It happens to take the form of a process diagram in most tools the ways vendors think of it and have designed it. But BPEL is a programming language and builds executable programs -- that's where BPEL is unique and very interesting. A lot of other process products and standards in the past targeted exclusively nondevelopers, such as business analysts. And they encouraged patterns where business defines requirements and then IT are expected to blindly implement the steps.

That's a great idea, but historically it hasn't really worked yet because there isn't enough communication between the Line of Business and the developers. Often, what you end up with is the LOB writes up a Word doc or a Visio diagram, and then says [to the developer teams] this is the way it should work. Then, [the developer teams] look at it and shrug and maybe ignore it and build their own thing, and it's not until [the project] is almost done before the business can validate that the developers did the right thing or the wrong thing. So, you have all this needless cycling.

Read more on Page 2 ...

Share    Print    Comments