Discussions

News: BEA and IBM submit joint white paper on BPELJ

  1. BEA and IBM submit joint white paper on BPELJ (16 messages)

    BEA and IBM have released a white paper on their proposal for BPELJ. BPELJ is a fusion of BPEL and Java that allows these two programming languages to be used together to build complete business process applications. By enabling BPEL and Java to work together, BPELJ allows each language to do what it does best.

    Introduction
    The Web Services Business Process Execution Language (BPEL) is a programming language for specifying business processes that involve Web services. BPEL is especially good at supporting long-running conversations with business partners. Even before the standard is formally released it is becoming clear that BPEL will be the most widely adopted standard for business processes involving Web services. BPEL is geared towards 'programming in the large', which supports the logic of business processes. These business processes are self-contained applications that use Web services as activities that implement business functions. BPEL does not try to be a general-purpose programming language. Instead, it is assumed that BPEL will be combined with other languages, which are used to implement business functions ('programming in the small').

    "This white paper proposes a combination of BPEL with Java, named BPELJ, that allows these two programming languages to be used together to build complete business process applications. By enabling BPEL and Java to work together, BPELJ allows each language to do what it does best."
    The white paper is here:
    BPELJ: BPEL for Java technology

    There’s also an interesting opinion piece on this over at the register:
    IBM moots BPEL-Java fusion

    Threaded Messages (16)

  2. Deja Vu[ Go to top ]

    Reading the white paper, I get a feeling that I have seen the concepts before.
    A company called Intalio already provide similar features and has a nice GUI tool ('Designer') to specify your BEPL, transactions, mappings, functions etc. They have their own app server that then runs your BEPL for you too.

    I don't work for Intalio, but had to use their tools on a project for a client last year and the Designer product was a little flakey at the start of the project, but was vastly improved by the end. I guess by now it will be bug free and working well. The server component worked really well throughout.

    Definitely worth a look if you need the aforementioned features today. (And I really dont work for them!)
  3. Deja Vu[ Go to top ]

    If you want to design processes today that are deployed as J2EE components, you can use WebLogic Workshop. In the current version (8.1), Workshop uses the JPD file format, which is different from BPELJ, but the next major version will support BPELJ and will be backwards compatible and allow you to migrate your work.

    Jesper
  4. Once you have it in Java, you can get it in C++ or .NET by using third party tools. Personally, I prefer our own (JunC++ion and JuggerNET), but there are plenty of competing products on the market that make Java a great starting point for connectivity.
  5. Hi.

    We are here . http://www.genisofttechnologies.com

    Use the Request a Quote Form in our HomePage.

    We have already done xflow customization for many customers.

    contact us , and we could give you reference of our customer list.

    Thanks and Regards.

    We are also expert in Visual Basic , Crystal Reports 3 tier Application Development .
    Cheap ERP Development
    etc.,
  6. BPML[ Go to top ]

    Vince,
    Perhaps you are thinking of Business Process Modeling Language (BPML), a standard proposed by the Business Process Management Initiative, of which Intalio is a member.
    Regards,
    Jim Greer
  7. BPML is DOA, long live BPEL[ Go to top ]

    Unfortunately for Intalio, BPML became DOA as soon as IBM and Microsoft published the BPEL specification and consequently submitted it to OASIS for standardization.

    Doron.

    Organic BPEL
  8. BPML/BEPL - whats in a name?[ Go to top ]

    Vince,Perhaps you are thinking of Business Process Modeling Language (BPML), a standard proposed by the Business Process Management Initiative, of which Intalio is a member.Regards,Jim Greer
    Hi Jim,

    well BEPL and BPML are very, very similar. In fact, I belive that BEPL heavily 'borrowed' from BPML as Microsoft and 'add your own other big company' like to do ;-).
    I also know that Intalio were converting their products to run with BEPL, and that most of the changes were simply in name only.

    Vince.
  9. This proposal is a step in the right direction but it suffers from a few flaws.

    A step in the right direction because there is a high need to be able fragments of procedural code within a BPEL process (((for those who are not familiar with BPEL, BPEL is a specification submit by Microsoft, IBM and bunch of others to OASIS for addressing the need for Web service composition/Workflow coordination in a Web services world. BPEL is a language that allows a developer to define a flow for sending and receiving messages across a network of services))): As you implement a flow, you might need to perform small computation, call a session bean, validate some piece of data. As suggested by the proposal, those requirements are better addresses by inline fragment of Java codes as a step in the process rather than having to wrap the fragment as a full blown external service.

    But this proposal has also a lot of flaws and seem immature. As context, Collaxa worked about 3 1/2 years on a concept called ScenarioBean that tried to bridge the gap between BPEL and Java. ScenarioBeans suffered from a lot of the same shortcomings so nobody should get defensive about this.

    Shortcoming #1: What ever solution the community develops for procedural embedding within BPEL should be language neutral. As a developer, I should be allowed to embed within a BPEL process a code fragment in Java, JavaScript, C#, etc using the same concepts and syntax.

    Shortcoming #2: The essence of BPEL (and its power) is that data is modeled as document and messages and XML Schema provides metadata about the structure of those documents. This unification is very powerful because it allows for better tooling. Introduction of serializable Java object into the BPEL type system is a big step backward as it allows people to mix and match documents with object and does not constraint developers to clearly separate orchestration logic and other type of business logic. This will open the door to a lot of spaghetti code.

    Shortcoming #3: JAXB mapping. XML/Java mapping is a though problem. It works well for simple XML documents (mostly the ones that vendors ship as demo with their products) but quickly hit the wall when you try to develop any real world application that usually entails more sophisticated data structure (STAR BODs, etc.). This is not a shortcomings of Java. It is simply related to the fact that an object tree is not a good representation of a document structure. This is why XML was created, this is why languages like XPATH, XQuery exist. Given that this is a tough problem, we should assume that things are going to evolve in the coming years. BPEL procedural embedding should not be dependent on this moving target.

    Shortcoming #4: JAXB mapping. Another very common use case that is not well addressed with this proposal is that BPEL process often deal with large XML documents. In that context, streaming is an important aspect of the solution. Representing XML document as Java Objects again falls short at addressing this requirement and will entail significant performance problems.

    Shortcoming #5: Java Annotation. BPEL is complex enough. Embedding BPEL into a Java comment just so that a BPEL process can call a functions seems an awfully complex solution to a very simple problem. It would so much simpler to encapsulate the Java code in a stateless session bean and call out that session bean when needed...or even a simple Java static class.

    Shortcoming #6: Procedural invocation. This again mixes the boundary between orchestration logic and simple business logic fragment! This is just so inconsistent!

    If I had to summarize, the biggest shortcoming of this proposal is that it blur the boundaries between orchestration logic and traditional procedural language/business logic. This is BAD because it will result in a lot of spaghetti code and makes BPEL more complex than it needs to be while damaging some of the key concepts, patterns and value proposition of BPEL (every thing is a document (data decoupling), everything is a service (interaction decoupling), orchestration logic is declarative (visualization and adaptability, bridging the bap between business analyst and developer).

    A better solution would be to ....address this requirement by adding a single activity (<exec>code fragment</exec> and NOT mess around with the other parts of the BPEL language and ...make sure that the same activity can be used to embed a fragment of C# code or Java code ((<execute language="C#|Java">code fragment</execute>) so that BPEL keeps its portability.
  10. Embedding BPEL into a Java comment just so that a BPEL process can call a functions seems an awfully complex solution to a very simple problem.
    Agreed. I wonder if a Groovy binding would be easier to use. Groovy could help in two ways: its DOM syntax for easy document loading, and its command interpreter for defining logic on demand.
    It would so much simpler to encapsulate the Java code in a stateless session bean and call out that session bean when needed...or even a simple Java static class
    I wonder which is easier to use, BPELJ or IBM's BPWS4J? The BPWS4J container sounds very appealing:

    "The BPWS4J engine supports the invocation, from within the process, of Web services that have a SOAP interface, that are EJBs, or that are normal Java classes." http://www.alphaworks.ibm.com/tech/bpws4j
  11. A better solution would be to ....address this requirement by adding a single activity (<exec>code fragment</exec> and NOT mess around with the other parts of the BPEL language and ...make sure that the same activity can be used to embed a fragment of C# code or Java code ((<execute language="C#|Java">code fragment</execute>) so that BPEL keeps its portability.
    That's precisely what the BPEL activity in Fiorano latest ESB 3.5 version
    can do!

    Thanks,
    Amit Gupta
    Fiorano Software Inc.
  12. Problem with embedded Java in XML[ Go to top ]

    Good day,

    I am not an XML expert but I thought that if data could be recognized as markup, it needed to be put into a CDATA section? For Java, this is definately true when you look at the JDK 1.5 support for generics, which denotes the type of a container with <...> such as

    ArrayList<Integer> list = new ArrayList<Integer>();
       list.add(0, new Integer(42));
       int total = list.get(0).intValue();

    Now, in Java, the following is also valid syntax:

    int[] a = {1,2};
    int[] b = {3,4};

    if (b[a[0]]>4)
       ///do stuff

    The "]]>" denotes the end of a CDATA section (assuming one was started). This means that the BPELJ document will either fail validation because the examples do not show it wrapping the code in CDATA and the code could contain markup syntax or it could fail validation if CDATA is used and the above example appears in the character data. Remember that the spec states that a '>' "need not (and cannot) be escaped using "<""

    Any thoughts on this?
    Sean
  13. Problem with embedded Java in XML[ Go to top ]

    Oops...answered my own question. The '>' must be escaped if it appears in the string "]]>" and that is not the end of the CDATA.

    I will assume that in the final spec the character data fields will be XML compliant.
  14. Has anyone got any experience with JBPM (www.jbpm.org), or XFlow, etc?
  15. There seem to be two camps involved – those who see this as something necessary to ease the burden on the poor Java programmer. For them, something like BPELJ sounds much easier to deal with than having to jump through hoops to work with BPEL. Here, ‘loose coupling’ is a pain in the butt. BPELJ lets them insert a ‘work around’ to get by a whole raft of difficult situations.

    At the other end of the scale are those folks who (like me) are looking at BPEL as an execution language for ‘Business Processes’ (and there are still many issues there). Here, the engine can read the definition and execute. The semantics of the process need to be separated out from detailed programming of functional calls. If we can do that then there is a chance to close the gap between business users (who dream up new ways of working) and the systems that are used to support their operations. With the right tools, they can envision a process and then ‘make it so’, without resorting to an army of programmers – modern BPM environments are already enabling just such an approach. Here, ‘loose coupling’ is what enables re-use, flexibility and adaptability.

    The idea should be that these sorts of languages (BPML and BPEL) should pursue the old truism - that if it can be abstracted into the semantics of the approach, then it should. By introducing a change like BPELJ, IBM and BEA are taking things firmly back in the other direction - into the realms of programming that requires deep technical skill.

    I used to have an adage that I used when looking at workflow engines. If you asked about something a little more difficult, they would say something like "that's easy, you have to write a program to do that". You'd get that answer for all sorts of questions - like asking how you would ensure the same actor received the work item if it navigated back to that role, or integrating even the simplest application.

    All that this (BPELJ) shows is that the Application Server vendors and integration centric players have difficulty meeting the semantic needs of true BUSINESS PROCESSES. "How things get done around here" is full of all sorts of subtleties, and if you cannot represent it at the semantic level, then you have to resort to programming.

    For those of us, who see a future where an executable business process language can enable a whole new approach to computing, the introduction of Java programming extensions within BPEL is a very retrograde step. Quite simply, it will ensure that the ‘standards’ end up having very little to do with the business and a lot to do with programming – thus sustaining the Business-IT divide. To me, the key point is not one of portability on platforms (one could argue that Java is portable). Instead, it is whether the engine can externalize the logic embedded in the Java.

    The BPEL TC should resist this sort of attempt to divert its activities and focus their attention on solving the problems of the business process at the semantic level – giving the BPEL specification the sorts of process-oriented capabilities needed by business. At least then there is a chance for a whole new raft of software platforms that can present these semantics in an end-user accessible environment.

    The TC should very explicitly reject the antics of vendors who want to divert its activities back towards developing yet another irrelevant guideline for IT programmers. BPELJ seems (at least to me) to serve only the needs of the existing application server and programming tool vendors – those who are most threatened by the emergence of business accessible computing environments.
  16. Derek

    I could not agree more with your recommendations. For a change, we were starting to see standards emerge that were vendor independent, technology independent, platform independent, and protocol independent. What IBM and BEA are doing is just to protect their investments in their application server and integration platforms and lock the customers to the same. This should be strongly rejected by BPEL TC as an attempt to vendorize the standard. Is there a way we can create a campaign against this move?

    N. Shekar
  17. One of the things that amazed me about deploying without UDDI a container of interdependent web services was how many URLs needed to be calculated and copied before execution began. But now I see there's JmDNS on SourceForge implementing standards defined by the Internet Engineering Task Force. I could easily forsee SOA embracing p2p and leveraging JmDNS or JXTA or Jini or WS-Discovery or WS-Resource, etc. In which case URLs are discovered. Can BPEL describe workflow that relies on discovery other than "the little-used UDDI"?