Controversy may be giving way to simple heads-down hard work when it comes to BPEL4WS, the proposed orchestration standard for web services supported by both Java and .NET vendors. The leading J2EE app sever vendors BEA and IBM have jointly proposed extensions to BPEL (Business Processing Execution Language) to make it more easily implementable within Java/J2EE environments.
Further, a BEA executive close to their BPEL work told Open Enterprise Trends that BEA intends to provide a reference implementation of BPELJ to the Java/J2EE community, and may even provide this royalty-free and as open source.
“BEA will write and provide a reference implementation of BPELJ. 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 BPELJ, OET spoke in depth with BEA’s 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 BPELJ doesn’t undo any interoperability between Java and .NET orchestration.
Inside the Workings of BPELJ
Today, BPEL4WS continues to grind through the standards-setting process at OASIS. Hood insists that BPELJ 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, BPELJ 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 BPELJ 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, BPELJ 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, BPELJ 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. BPELJ 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.
A BPELJ FAQ with BEA’s Hood
What follows is a quick-reference FAQ for the status, workings and intent of BPELJ. A look at how BPELJ 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 BPELJ? .
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 BPELJ 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. BPELJ is for implementing BPEL for Java.
OET: Aside from the BEA/IBM whitepaper, does the Java community need a reference implementation of BPELJ?
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 BPELJ. Since the submission of JSR 207, we’ve worked with IBM to define an implementation for BPEL, which we’ve called BPELJ. The BPELJ 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 coauthored 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 BPELJ 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.
OET: Is it off-base to think that better native support for business process means that Java developers will need to pay more attention to business rules and the integration between “silos” that end-to-end rules support infers? In other words, does BPEL support in Java products help to break down the idea of “Java as a silo”?
Hood: There is a myth out there that BPM tools make developers irrelevant or unneeded. We think, very strongly, that BPM is a family of tools that involve both business and IT.
I think potentially it can [break down]. Also, increasingly the lower levels [of Java development] are being commoditized. Look at the success of the app server. Nobody today would go out and build that layer themselves. The problem is understood, and people have solved it well. There’s no value in trying to solve that [problem] yourself today, and that’s going to continue moving up the Java stack. We think developers are looking for ways to keep their skills relevant to their orgs.
OET: How will Java developers react to having these new skills and/or demands put upon them (depending how you look at it)?
Hood: We’ve been doing webinars on dev2dev on the idea of process-driven development. Let’s put aside the business stuff, and what it comes down to is that process makes trivially easy things that are hard to do in code — things like asynchronous communication or logic, persistence, or transaction management, conversation threading. All these sorts of things are functionality provided by process tools — like WLI today and BPELJ tomorrow.
OET: Without connectivity between silos, it’s pretty difficult to help developers support that kind of development project, isn’t it? So, will BPEL J have those foundation connectivity elements in it? Is that a big piece of BPEL, to have all those welding components pre-built?
Hood: I would put it a different way. BPEL makes assumptions about the state of your IT infrastructure. It assumes that everything is a web service. It also assumes that all the fine-grained tough technical problems are being solved inside your services.
So, for example, BPEL can expect you to have an “update customer record” service. But BPEL doesn’t want to know that that service is going to talk to both SAP and Siebel, one via web services and the other via a JCA adapter, and that you have data transformations in place and if the system’s down, you’ll try a back-up system, etc. BPEL doesn’t think in terms of that fine-grained logic; it thinks in terms of coarse-grained business services. And that’s why BPEL works as an idea because it’s a simplified problem space.
OET: So, whose job is it to make sure the plumbing infrastructure is intact?
Hood: That’s been the big question before BPELJ. There are all sorts of different approaches to doing this. There are companies that wrap mainframes with web service interfaces. There are plenty of “web services platform” products that let you build web services interfaces for your existing infrastructures. There are Open Source toolkits that let you build them. And the list goes on and on.
Our approach, along with IBM, is to ask the question: BPEL is great for orchestrating web services; how can we use BPEL to build web services? And the answer to that is BPELJ.
OET: Does BPELJ look to replace those multi-flavor options?
Hood: Yes. To get an idea, look at service-oriented architectures, for example. The whole idea there is you build business functionality into reusable services, and then you orchestrate those into applications or business processes. So, in the orchestration piece, BPEL is poised to be the leader. It deals with coarse-grained logic, not native language issues. You need to deal with the native language issues, and that’s what BPELJ is about.
OET: BPEL without J is for orchestration. And, as we come to a vote for BPEL, vendors are now concerned with implementation.
Hood: We’re proposing this as the way to do it on the Java platform. Gap, you’re right, but that gap is intentional. There’s a last-mile problem with BPEL. The whole world is not web services-based, so we have to ask ourselves, does it make sense to wrap everything as a web services — such as access to files?
OET: { How do you envision ensuring interoperability between your BPELJ and the non-Java world, particularly .NET
Hood: That’s a great question. The idea of BPEL by itself is portability of process logic across platforms and tools. But, I think the BPEL community understands that that’s only possible to a point. To do these finer-grained problems, BPEL will have to be extended. As an example, look at SQL.
We all got together as an industry and agreed on ANSI SQL. It didn’t solve all the problems, or include all the features that vendors needed to meet customer needs and to be competitive. That’s OK. That was just accepted as the way it was going to go. So, vendors eventually went out and extended that [ANSI SQL] standard in their own ways. Oracle did it their own way; Microsoft another and IBM another.
So, today, we’re left with not a great situation, but it’s an understandable one. If I’m running SQLServer and you’re running DB2, and I give you my queries, you know they won’t just magically work properly. But, it’s a pretty-well-understood problem to get those queries from my format to yours. So, with BPEL, we’re shooting for a higher bar than that, but it’s a similar metaphor. We’re hoping that the equivalent for BPEL of ANSI SQL will be a broader problem solved and the bar will be higher so you can take a process from my tool and run it on yours.
OET: Will there also be a parallel effort from Microsoft for .NET, a BPEL.N, to coin a phrase?
Hood: It’s likely, yes.
OET: Is it important for you to keep the communications open among Java vendors, as well as Microsoft? Are you making sure there won’t be further fragmentation, even as a Java-specified BPEL moves forward? This is all about moving BPEL ahead quicker and not about starting another food fight somewhere among Java vendors, or among you, IBM and Microsoft’s .NET, right?
Hood: We continue to be very involved and have active conversations with both IBM and Microsoft. These are standards that will coexist [between Java and .NET]. The idea is if you use BEA’s tool and you write a BPELJ process, it’s a BPEL process plus some Java stuff. The BPEL stuff is still portable, and [you can] take it to Microsoft’s .NET [platform], and bring it up in their tool. What will not port over will be the fine-grained, Java logic, and that’s OK. It would be implemented completely different on .NET, anyway.
On the surface, I can see how people might say this will fracture [BPEL] efforts. But, in fact, we think this will actually avoid fracturing BPEL. Microsoft supports export of BPEL from BizTalk, and it may go into the OS. They’re very much involved, but they haven’t done anything about what goes into the product.
OET: Does there need to be some interoperability testing or certification for BPEL across Java and .NET platforms? For you as a vendor, would such support help?
Hood: OASIS is not terribly strict about that. If you want to have real portability that actually works, then you need interoperability testing, certification and reference implementations. We’re not sure if we’ll be getting that from OASIS. But we will get these from the Java Community Process. Part of our agreement for JSR 207 is that BEA will write and provide a reference implementation of BPELJ. 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.
Customers have been asking us for this for years, and we’re going to put a line in the sand and say we’re going to ship this thing. They’re not going to wait much longer. [. Can’t speak to the exact date, but I’d say we’d love it to happen sometime this year. But [we] don’t have to wait. BPEL will be given a thumbs up; there’s no doubt now. A lot of vendors have already implemented a pre-release version of the spec. BPELJ and JSR 207 are dependent upon BPEL. Both of these things can go on in parallel. When we reach the end of the line, BPEL has to be formally standardized first before 207 can be formally ratified.
OET: As part of core J2EE spec?
Hood: That’s the goal. Absolutely. Regardless, BEA and IBM will implement it, and we believe this will drive other vendors to do so, as well.