Discussions

News: BPEL4WS submitted to OASIS Standards Body

Bookmark and Share Get thread feed

  1. BPEL4WS submitted to OASIS Standards Body (54 messages)

    BEA, IBM, and Microsoft have submitted the Business Process Execution Language for Web Services (BPEL4WS) to the OASIS standards organization this week, and a new technical committe is being formed at OASIS to continue work on the spec. A rival spec, the Web Services Choreography Interface, is being worked on at W3C.

    Read OASIS Forms Web Services Business Process Execution Language TC (WSBPEL), and OASIS to get BPEL4WS jurisdiction.
    Reply to this

    Threaded Messages (54)

  2. BPEL4WS bookmark[ Go to top ]

    Here is a quick bookmark of resources for developers that might be interested in learning more about BPEL4WS. IBM and Collaxa offer downloadable evaluation versions of their products. So for the early adopters, you could actually go further and kick the tires.

    I am very interested in hearing from the developer community about what is missing to make BPEL (1) an interesting topic and (2) a useful solution and what kind of content would help them get a better grasp of what BPEL4WS is.

    Fire!

    Edwin
    http://www.collaxa.com
    HP review of technologies, tools and standards for Web service orchestration(HP)
    BPEL 101 Tutorial(Collaxa)
    DeveloperWorks BPEL Columns(IBM)
    BPEL Programmer's Guide (Collaxa)
    Visual BPEL Wizard (Collaxa)
    BPEL Forum (IBM)
    Repository of BPEL samples (Collaxa)
    BPEL Learning Guide (searchWebServices.com)
    Reply to this Reply to original

  3. BPEL4WS????[ Go to top ]

    I do not get it! Why do we need all these XML-based crapy difficult to read languages for invoking a sequence of services. Why not simply use Java and JAX-RPC?!? Vendors are trying to push all these "no-code needed" visual drag and drop tools...Guess what, this is a magic pill.. it does not exist...after the first demo, you end up having to live with a mickey mouse tools to build enterprise applications that in reality are much more complex than the simple stupid quote demo that vendors advertize. So no thanks! Get real. The real world and particularly integration is complex!!!
    Reply to this Reply to original

  4. BPEL4WS????[ Go to top ]

    Robert,

    I only agree partially. Also in my opinion, BPEL4WS is an xml-programming-language for web services. So I don't see much of an advantage there over JAX-RPC.

    Other specifications (e.g. WfMC's XPDL, BPML, ...) and tools (e.g. jBpm) are not restricted to web-services alone. They are able to execute processes that interact with other systems in any protocol. Then, the advantage over programming (even java) is significant.

    Tom.
    Reply to this Reply to original

  5. Asynchrony and formalism[ Go to top ]

    Edwin,

    You talk about BPEL4WS being useful in the context of asynchronous message exchanges. Is there a *standard* formalism for describing an asynchronous web services? If not how do you guaranty the interoperability across vendors and SOAP toolkits.

    Valery
    Reply to this Reply to original

  6. WS-Addressing and BPEL Service Links[ Go to top ]

    Valery,

    There are multiple specs but no standard yet. The most promissing specs are WS-Addressing and BPEL Service links.

    Here is a small example. Imaging that we are building an Asynchronous Sales Forecasting service. Here is what the message exchange pattern would look like:

         Client Interface Sales Forecast Service
                                                 ( async )
               | |
               | ---------- initiate ---------> |
               | <---------- ask ------------ |
               | |
               | |
               | <------ receive request ------ |
               | ---------- ask --------------> |
               | |
               | |

    There are 2 things that need to be described:
    P1: The client has a callback interface defined by a web service port type.
        The server has an interface defined by a web service port type.
        How do we couple those 2 interfaces into an async "conversation"?

    P2: How does the forecast service know where to callback. How is the
        callback correlated to the initial request.

    P1 is addressed by the notion of BPEL Service Link which is a very simple extension to WSDL to allow mapping to multiple interfaces/roles into a conversation pair.

    P2 is addressed by WS-Addressing, a spec submitted by IBM, Microsoft and BEA.

    Once those 2 things are leverage, interoperability is significantly simpler. We have a couple examples of interoperability with BEA workshop on our developer website.

    I hope that this addresses your question.

    Best,

    Edwin
    Reply to this Reply to original

  7. standards[ Go to top ]

    [quote]There are multiple specs but no standard yet[/quote]

    just out of curiousity , when would you consider something to be a "standard"

    when oasis says so or w3c, WS-I maybe ? microsft and IBM ?
    Reply to this Reply to original

  8. what makes a standard[ Go to top ]

    [quote]There are multiple specs but no standard yet[/quote]

    > just out of curiousity , when would you consider something to be a "standard"
    > when oasis says so or w3c, WS-I maybe ? microsft and IBM ?

    This is a good and unanswerable question. One could define "standard" in terms of the output of organizations like ANSI, ISO, and the UN. In the current context, I think you're correct to identify WS-I as the body that will sort out the web services stack on a generic level.

    My personal ruler for a standard as opposed to a specification submitted to or endorsed by a standards body is maturity, adoption, and reference. (The reference requirement is a little bit like the algorithm that Google uses to rank search results.) For example, the abyssmal Rich Text ("RTF") file format could be called a "standard" in that it is relatively stable, people know what you mean when you say "RTF", and there are plenty of tools and applications that use RTF in one way or another.

    Right now, WSBPEL (it is no longer called BPEL4WS) is a proposed specification; it is an agglomeration of reasonably good ideas that is going in front of a committee of technology and industry experts for validation, modification, and extension.

    For example, W3C XML Schemas have been around in one form or another since 1999 (May 6 WD), but a mature open source implementation (in the form of Xerces from the Apache XML project) and a good selection of commercial tools for manipulating XML Schemas have only been available for about the past 12 months. Moreover, numerous specifications, including SOAP, WSDL, XQuery, etc., reference XML Schema as a type system or the type system. While it wouldn't have been legitimate to call XML Schemas a "standard" in 1999, it is legitimate now in that it exists in a concrete, referencable form and is supported by a variety of tools and applications.

    The important thing about the submission of WSBPEL to OASIS is the opportunity to forge a specification that is worthy of being a standard for the description and execution of business processes.
    Reply to this Reply to original

  9. BPEL4WS versus other BPM standards[ Go to top ]

    Hi Tom,

    <tom>
    I only agree partially. Also in my opinion, BPEL4WS is an xml-programming-language for web services. So I don't see much of an advantage there over JAX-RPC.
    </tom>

    I hope that my example regarding asynchronous interactions (BPEL4WS <receive> activity) and flow coordination ( BPEL4WS <flow>, <sequense>, <links>) addresses your confusion regarding comparing Java to BPEL4WS.

    <tom>
    Other specifications (e.g. WfMC's XPDL, BPML, ...) and tools (e.g. jBpm) are not restricted to web-services alone. They are able to execute processes that interact with other systems in any protocol.
    </tom>

    This is another area of confusion: a web services/WSDL described end points do not mean only XML and SOAP over HTTP. WSIF is a good example of that: you can reflect, Java, CORBA, JMS, etc. resources as web services with zero over head.

    Some of those workflow definitions have better support for user tasks, assignment, load balancing, etc... (driven by old document management roots). With the exception of BPML, none of them stack up to BPEL4WS for coordination of messages and integrations over a distributed, heterogeneous and non-reliable network like the net.

    Like I said earlier if you are an early adopter you should give it a try and see for yourself.

    Best,

    Edwin
    Reply to this Reply to original

  10. BPEL4WS = Asynchronous interactions and flow[ Go to top ]

    Robert,

    I think that you are making a good point with regard to some of the limitations of visual modeling capabilities with regard to "scaling with complexity". This is something that the industry will have to deal with over time: Collaxa tries to address this problem by offering 2 abstractions on top of our BPEL engine: one is a visual model (targeted at coarse grain static flow) and one is a programatic flow model called JBPEL which is based on the annotation of Java with BPEL orchestration tags and metadata. You can learn about those if you take a look at the first 2 chapters of the BPEL developer's guide.

    But with all respect, I think that you are wrong when you compare BPEL4WS with Java/JAX-RPC. You are comparing apple and oranges. BPEL4WS (and other flow abstractions) are driven by the need to coordinate *asynchronous* message exchanges across services distributed over the net. This means that you have to be able not only to invoke a web service (a la JAX-RPC) but also wait to *receive asynchronous callback* before invoking the next service. More sophisticated use cases require parallel flow of execution, join patterns, exception management, compensating business transactions, etc. As you can see, those constructs and semantics do not existing in traditional languages like Java/JAX-RPC. This means that you have to write a lot of code to implement those type of requirements.

    BPEL4WS solves that problem by offering a base set of activities and ways to glue them into a flow. <receive> for example allow you to define a rule pointing out that you want to suspend the execution of the flow until a message is received. How would you implement this in Java?

    Again asynchronous message driven interactions drive the need for flow coordination. BPEL4WS offers a standard approach to implementing flow logic. Orchestration servers offer "Containers" where BPEL-based flow logic is executed, monitored and managed.

    Here is a link to an example of the kind of applications/long-running processes that can be build by stringing together asynchronous services.

        BPEL Example: Make Excel Flow

    Give it a try and you should be able to get a feel of what I mean by asynchronous web services and flow coordination.

    Please let me know if you have any specific questions regarding BPEL4WS.

    Best,

    Edwin
    edwink at collaxa.com
    Reply to this Reply to original

  11. Java + Asynchronous interactions and flow[ Go to top ]

    It looks like the main cause of existence of such approaches like BPEL4WS and a like is the inability of traditional programming languages to handle an asynchronous interactions (method calls). People are trying to use various dialects of XML as interpretable language to be able to store state of execution at the moment of the asynchronous call and to restore it after response is received.
    We in Velare Technologies (www.velare.com) are trying to develop another approach.
    Our technology is based on execution context reification that allows us to implement asynchronous method calls in pure Java. As result we can use any OOP techniques and design patterns for process flow development. Highly sophisticated flow patterns can be easily implemented in Java using standard IDEs and modeling tools.
    We've released beta version of our messaging solution Discorso that is based on this technology.
    In two weeks Velare is planning to release standalone version the Java asynchronous method invocation framework called ATCT.
    Meanwhile you can play with various examples of use of ATCT included in the beta release of Discorso.

    Serguei Mourachov
    Reply to this Reply to original

  12. Execution context reification[ Go to top ]

    Serguei,

    It would help to see a code example to understand what you mean by "execution context reification". Could you please enlight us on how you would implement the following flow within your framework:

    <receive initiate> // start
    <invoke creditRating.getRating> // synchronous service
    <flow> // parallel flow of execution
        <sequence unitedLoan> // one branch of the parallel flow
             <invoke unitedLoan.initiate> // start async service
             <receive unitedLoan.receiveResult> // wait for async callback
        </sequence>
        <sequence starLoan> // one branch of the parallel flow
             <invoke starLoan.initiate> // start async service
             <receive starLoan.receiveResult> // wait for async callback
        </sequence>
    </flow>

    Thank you,

    Edwin
    Reply to this Reply to original

  13. Execution context reification[ Go to top ]

    Edwin

    Here is simple example I’ve created using Discorso.

    public class SpawnDemo extends OpenClientDialog {

    public void execute() throws AISignal {
    Rating r = ratingSource.getRating();
    spawn(new OpenClientDialog[]{
    new OpenClientDialog() {
    protected void execute() throws AISignal {
    Object unitedLoan = new Object();
    Object unitedLoanResult = sendAndGetReply(new Message(unitedLoan)); // here we can wait for result for days and/or months
    }
    },
    new OpenClientDialog() {
    protected void execute() throws AISignal {
    Object starLoan = new Object();
    Object starLoanResult = sendAndGetReply(new Message(starLoan));
    }
    }
    }
    );
    }
    }


    You can see that method execute() throws AISignal.
    AISignal is a “tag” Throwable for our framework; it means that method should be executed in special mode allowing creation of the ExecutionContext object.
    Actually, all methods tagged with AISignal executed by secondary bytecode interpreter written in Java. It allows us access process stack as a first-class Java object.

    Method sendAndGetReply is an asynchronous method; it tagged with another “special” Throwable - ATCSignal that informs the framework to stop interpretation and process an asynchronous call. At this moment framework can serialize the ExecutionContext, store it somewhere and execute any asynchronous activity. After receiving response the ExecutionContext can be restored and the response can be returned as result of invocation of sendAndGetReply();

    If you are interested in more detailed information about ATCT and Discorso you can send me email.

    smourachov at velare.com

    Serguei Mourachov
    Reply to this Reply to original

  14. Execution context reification[ Go to top ]

    Serguei,

    Thanks for the example. I have fixed the formatting so that it is easier to read:
    http://www.collaxa.com/temp/velare.htm

    I think that it is an interesting idea and could provide a skin that some developers might prefer over writing BPEL4WS code. But my recommendation would be that you pre-process these Java classes into BPEL4WS execution maps so that your customers are not locked into your proprietary solution to handle asynchronous interactions and flow coordination.

    Best,
    Edwin
    Reply to this Reply to original

  15. Execution context reification[ Go to top ]

    Edwin,

    Thanks for interesting discussion

    Actually I have some doubts about standardization of flow languages, in particular their executable forms. IMHO, orchestration scripts are completely confined in their execution environment, i.e. concrete webservices “don’t know” who is invoking them and in what kind of activity they are participating. It means that as webservice developer I don’t care who is calling me: BPEL4WS or some other type of script.

    OTOH, BPEL4WS can be exposed to external world as webservice using WSDL interface, and again as developer I don’t care about nature of the script; it’s just another webservice for me.

    Therefore, IMHO it looks like, BPEL4WS proponents are trying to convince us to use the “standard” flow language which looks more and more like a programming language as alternative for common programming languages. They have products that need a language able to handle asynchronous interactions. The only solution they can imagine is a XML-based script, ignoring such languages as Lisp, Scheme, Ruby, stackless Python, etc, which can be easily used to solve such problems. Nobody likes word “proprietary” and they decided to invent and standardize yet another XML-based monster making money on tools, training, professional services; deprecating existing tools and developers skills set.


    IMHO it makes more sense to standardize some kind of language for Message Exchange Patterns (MEP) between parties and leave the execution process to be vendor specific.
    Essentially, I think, it would better to have extended WSDL that is able to handle multiple message exchange without specifying how it will be executed.
    In this case we could generate any type of executable scripts in any language from the MEP definitions.


    Serguei Mourachov
    Reply to this Reply to original

  16. Execution context reification[ Go to top ]

    Serguei,

    I am not trying to convince you that BPEL4WS will remplace Java!!! To me, it is about congruence. You use JSP instead of pure Java because it offers a better representation of what a page is and therefore is ideal for implementing presentation logic. In the same way, Java is the best language for implementing fine grain business logic and components. In the same way, BPEL4WS includes flow semantics and is best use for orchestration logic. The key is to use the abstraction that is the closest to what the mental model of the developer is: what you think is what you code!

    I think that you could argue that BPML is better than BPEL4WS. But I think that it is diffult for you to argue that over the next 2 years no standard orchestration standard will emerge. When that happens, people that offer an alternative (proprietary) approach/framework with have a very hard time. Who remembers Cullinet?

    The benefits of BPEL4WS are similar to those of SQL or J2EE : reduces developer learning curve, better tools support, much lower prices and reduce the cost of migrating from one vendor to the other.

    Finally, in your cases, BPEL4WS could be completely hidden to the developer: you could pre-process your Java classes and use your "markers" to generate a BPEL4WS byte-code equivalent.

    This way your customer will get the best of both world: the ease of use of your scripting approach and the ability to pick and choose the most reliable and easiest to manage BPEL4WS engine.

    Edwin
    Reply to this Reply to original

  17. Execution context reification[ Go to top ]

    Edwin,

    >I am not trying to convince you that BPEL4WS will replace Java!!!
    Well, may be I was a bit aggressive in my statement, but I will try to explain my position…

    >The key is to use the abstraction that is the closest to what the mental model
    >of the developer is: what you think is what you code!
    Simple, lightweight domain specific language for flow definition potentially may be a good idea. I really like SQL but I hate XML-based scripts. Of course I understand all their advantages but I think that readability and developer friendliness is far more important.
    Can you imagine SQL using XML syntax?! Would it be so widely accepted in that case?
    Look at XQuery effort, although I don’t consider it ideal, it looks much better than BPEL4WS in terms of readability and developer friendliness.
    The main problem is that BPEL4WS proponents are trying to standardize the language using their financial power, killing possible alternatives right away, without giving anybody a chance to evaluate various ideas in real life applications.

    > Finally, in your cases, BPEL4WS could be completely hidden to the developer:
    > you could pre-process your Java classes and use your "markers" to generate a
    >BPEL4WS byte-code equivalent.

    I think that it would be really easy to transform BPEL4WS in Java source code without loosing any functionality, but produce BPEL4WS from Java is almost impossible. Java is so much more powerful; can you imagine flow definition that uses inheritance, delegation, observers and other OOP design patterns and how it can be transformed to BPEL4WS? Of course Java doesn’t have expressiveness of domain specific language for flow definition but this is true for many other domains and languages. I think it might be more appropriate to use thread semantics or even to introduce some new kind of semantics in Java to achieve the idea: what you think is what you code, in case of flow definition. After all, it’s the main goal of using any imperative programming languages – to define a flow in your application.


    Serguei Mourachov
    Reply to this Reply to original

  18. Loan Procurement Flow implemented using JBPEL[ Go to top ]

    <sergei>
    I think that it would be really easy to transform BPEL4WS in Java source code without loosing any functionality, but produce BPEL4WS from Java is almost impossible. Java is so much more powerful; can you imagine flow definition that uses inheritance, delegation, observers and other OOP design patterns and how it can be transformed to BPEL4WS? Of course Java doesn’t have expressiveness of domain specific language for flow definition but this is true for many other domains and languages. I think it might be more appropriate to use thread semantics or even to introduce some new kind of semantics in Java to achieve the idea: what you think is what you code, in case of flow definition. After all, it’s the main goal of using any imperative programming languages – to define a flow in your application
    </sergei>

    I have update this document to describe how the loan procurement flow can be implemented using JBPEL. It should be a proof that it is possible to combine a Java friendly skin with a BPEL4WS execution map.

    Edwin
    Reply to this Reply to original

  19. Java + Asynchronous interactions and flow[ Go to top ]

    Brian,

    <qoute>The JRE is equipped with everything necessary to seamlessly save processing state between events.</quote>

    But the onus is on developer to design and program state machine that's responsible for saving / restoring the state of the process. Not the case with ATCT where this could be taken care of by the framework by virtue of Serializable Execution Context.

    <quote>The only feature you've mentioned that seems novel enough to justify a proprietary solution is of course any visual aids. But having mentioned it, you quickly resumed chatting about your textual API. So I'm confused: you've made a visual tool or not?<quote>

    I think you might be confused by what Collaxa's product is and what Velare's product is.

    As a side note :

    Velare's technology allows one to take better advantage of already existing tools and skills that companies already have. The business process can directly map to code when Velare's technology is used. Consider a UML sequence diagram and how it maps to code implemented using sequencial programming. The mapping is direct. If you were to map it to an event based code than you would need another abstraction, BPEL perhaps.

    With ATCT it's not needed.

    thanks
    alex krut
    Reply to this Reply to original

  20. Loan Procurement Flow implemented using JBPEL[ Go to top ]

    Edwin

    >I have update this document to describe how the loan procurement flow can be
    >implemented using JBPEL. It should be a proof that it is possible to combine a Java
    >friendly skin with a BPEL4WS execution map.
    You are using right term: “skin”, that’s it, and it’s just a skin on BPEL skeleton!
    Can you subclass JBPEL flow or sequence or their fragments?
    Can you delegate sequence execution to dynamically loaded class?
    Can you add and remove observers (that may contain flows as well) for various flow events at run-time?
    AFAIK BPEL cannot do these, but it’s a normal way to implement flows using Java and millions of developers already know how to do that! And they already have various tools that can help them in the development.

    Serguei Mourachov
    Reply to this Reply to original

  21. Loan Procurement Flow implemented using JBPEL[ Go to top ]

    <serguei>
    Can you subclass JBPEL flow or sequence or their fragments?
    </serguei>
    You sure could if it was needed. We had support for inheritence in 1.0. We got rid of it because it creates tight coupling between processes and translates into a version control nightmare. I am happy to talk more about this if it is of interest to people reading this thread.

    <serguei>
    Can you delegate sequence execution to dynamically loaded class?
    </serguei>
    Sure. The location and even the binding to a service is completely data driven thanks to WSDL and WSIF. You can also achieve this use case through JMS which provides a completely unified and non-typed interface.

    <serguei>
    Can you add and remove observers (that may contain flows as well) for various flow events at run-time?
    </serguei>
    The Collaxa observer framework is based on WS-Addressing and offers an API for dynamic publish and subscribe.

    <sergei>
    AFAIK BPEL cannot do these, but it’s a normal way to implement flows using Java and millions of developers already know how to do that! And they already have various tools that can help them in the development.
    </sergei>
    BPEL is only the foundation of the solution. The additional feature have to build on top of it either as extension or service.

    Over time, as a standard emerge, the learning curve in learning that standard will be lower than the learning curve of learning your APIs and even if your technology was slightly better than the standard, you will have a hard time competing.

    But I could be wrong. The market will tell.

    Edwin
    Reply to this Reply to original

  22. It’s not just about webservices…[ Go to top ]

    Edwin, by the way, I’m criticizing BPEL approach because it’s really interesting for me to discuss all these things. Not because I blindly believe that use if execution context reification is the only right solution for webservices orchestration.
    Our technology can be used in various areas and ws-orchestration just happens to the most popular of them. I agree that mapping between BPEL and Java looks very interesting in case of ATCT, and IMHO it looks better in comparison with Collaxa approach for execution context management.
    Actually, we are more interested in use of our technology in various solutions and frameworks, than in competition of implementations.
    ATCT can be used in webapplication frameworks, mobile agent solutions etc.
    Of course webservices look like most promising technology right now, but still it’s just one of the places where asynchronous method invocation framework can be used.
    The final goal is to simplify development of complex distributed systems and who knows what kind of new ideas we will have in 3-5 years.
    At the same time I think ideas like ATCT can give Java as a platform an additional boost opening new opportunities for application development.

    Serguei Mourachov
    Reply to this Reply to original

  23. Java + Asynchronous interactions and flow[ Go to top ]

    <quote>
    It looks like the main cause of existence of such approaches like BPEL4WS and a like is the inability of traditional programming languages to handle an asynchronous interactions (method calls).
    </quote>

    I doubt that. Queing up asynchronous events is easily within the ability of procedural languages. For example Swing's always had an event queue to seemlessly decouple event generation from event consumption. LISP extended quite well for an actor-based language like MIT's Act-3. And Java has several straightforward agent/actor frameworks. Asynchrony isn't the reason for expressing algorithms in XML.
    Reply to this Reply to original

  24. Java + Asynchronous interactions and flow[ Go to top ]

    Asynchrony isn't the reason for expressing algorithms in XML

    That's right.
    You can use any type of Queuing for asynchronous application development.
    Unfortunately it's not so easy to implement the sophisticated flow patterns using event-driven mechanism.

    Using interpretable flow language allows you to transforms the event-driven queue-based approach to simple and well-known sequential programming concept. In this case flow patterns can be easily implemented and textually (and graphically) represented.

    Unfortunately we cannot use mainstream programming languages as flow languages because of lack of real asynchronous calls. That's why we have all these XML dialects used for flow definition instead of "normal" languages.
     
    We in Velare are trying to introduce asynchronous methods in Java that will allow developers to use all their skills, programming techniques and tools for asynchronous process development.
    We think that using Java as flow definition language is a real alternative to cryptic and limited XML-based solutions. Moreover this approach can be used not just for Webservices orchestration but in any other area with similar requirements.


    Serguei Mourachov
    Reply to this Reply to original

  25. Java + Asynchronous interactions and flow[ Go to top ]

    <quote>
    Unfortunately it's not so easy to implement the sophisticated flow patterns using event-driven mechanism. Using interpretable flow language allows you to transforms the event-driven queue-based approach to simple and well-known sequential programming concept.
    <quote>

    What you mention is similar to JSR-166 or Doug Lea's util.concurrent package, where most or all of what I consider flowing asynchrony has been sewn up into the "well-known sequential programming concept", as you say. So like I totally agree with you that Java's well suited to wrap web service choreography. I'm just not sure that a custom mapping between WSBPEL and Java, such as yours, is optimal. With frameworks like JAXB or even just JAXP, there's already a perfect Java wrapping of WSBPEL. I suppose teaching a Java workflow engine to talk WSPBEL might be little more than a direct application of J2SE's XML machinery. It's unclear to me how much or how little upgrading to J2EE from J2SE offers in this case. Is a servlet really that much more useful to a workflow engine than, say, merely the java.net package? So like I'm totally sure J2SE already has what it takes to readily crunch choreography.
    Reply to this Reply to original

  26. An Example[ Go to top ]

    Brian,

    Could you please get specific and show us how you would implement the flow example listed earlier using the frameworks you are suggesting?

    Edwin
    Reply to this Reply to original

  27. Java + Asynchronous interactions and flow[ Go to top ]

    Brian

    What Velare provides is not a java - xml mapping or replacement for concurrency package or anything that java already has. The core Velare's technology - ATCT introduces Execution Context as a first class object and allows one to freese and serialize execution context. The execution context can then be restored and continued.

    ATCT makes implementation of workflow or process engines that allow utilizing java (not xml) to code the business logic in a sequencial manner.What had to be coded as an event handler can be coded in one ! line using ATCT. It also saves you having to preserve state of the process as now, using ATCT, the state of the process is preserved as part of the Excecution Context.

    Imaging having to issue email to the customer and getting reply in one line of code. e.g.
    <pre>
    Reply reply = email.send();
    </pre>

    That's how the code that would normally be scattered across asynchronous event handlers could look if ATCT is utilized.

    In the above code snippet the framework that uses ATCT could send out the message and wait for reply. The method Email.send() would only return when the reply is received. Keep in mind that in ATCT the execution context is a first class serializable object that could be stored for months waiting for the customer to reply to the email.

    ATCT does not tie up JVM runtime resources (threads, etc) during the time the Execution Context is deactivated. Standard java does not offer this functionality and nor does the concurrency package.

    Discroso is framework that's built on top of ATCT and could be used as a demonstration of what could be achieved using ATCT.

    cheers
    alex krut
    Reply to this Reply to original

  28. Java + Asynchronous interactions and flow[ Go to top ]

    <quote>
    ATCT does not tie up JVM runtime resources (threads, etc) during the time the Execution Context is deactivated. Standard java does not offer this functionality and nor does the concurrency package.
    </quote>

    The JRE is equipped with everything necessary to seemlessly save processing state between events. There's JDBC and serialization. And with J2EE there's also stateful beans, persistant session contexts, and durable queues. I see no reason to abandon an appeal for direct application of Java's standard mechanisms. The only feature you've mentioned that seems novel enough to justify a proprietary solution is of course any visual aids. But having mentioned it, you quickly resumed chatting about your textual API. So I'm confused: you've made a visual tool or not?
    Reply to this Reply to original

  29. Walk the walk[ Go to top ]

    <brian>
    The JRE is equipped with everything necessary to seemlessly save processing state between events. There's JDBC and serialization. And with J2EE there's also stateful beans, persistant session contexts, and durable queues. I see no reason to abandon an appeal for direct application of Java's standard mechanisms.
    </brian>

    You can talk the talk. Let's see if you can walk the walk: Implement the loan flow describe earlier using serialization, JDBC, statefull session beans, durable queues etc. and we will post your implementation next to the other options offered earlier in this thread so that people can make their own judgement.

    Edwin

    Edwin
    Reply to this Reply to original

  30. Java + Asynchronous interactions and flow, the BPEL way[ Go to top ]

    <alex>
    What Velare provides is not a java - xml mapping or replacement for concurrency package or anything that java already has. The core Velare's technology - ATCT introduces Execution Context as a first class object and allows one to freese and serialize execution context. The execution context can then be restored and continued.

    ATCT makes implementation of workflow or process engines that allow utilizing java (not xml) to code the business logic in a sequencial manner.What had to be coded as an event handler can be coded in one ! line using ATCT. It also saves you having to preserve state of the process as now, using ATCT, the state of the process is preserved as part of the Excecution Context.
    </alex>

    I believe that's ancient news in orchestration technology, Alex. I've evaluated Collaxa 1.0 a year ago when they've introduced ScenarioBeans (now morphed into JBPEL which can be used alongside standard XML-Based BPEL in their 2.0 version). JBPEL is a reliable long-running thread of execution context which uses a persistent store to save and restore the state and provides for exactly that level of abstraction for composing asynchronous Web services into flows by Java developers. I think this is also patented technology by Collaxa, FYI.

    Cheers.

    Jill.
    Reply to this Reply to original

  31. Java + Asynchronous interactions and flow, the BPEL way[ Go to top ]

    Hi Jill,

    <quote>I think this is also patented technology by Collaxa, FYI.</quote>

    I'd appreciate if you could provide a link to the patent.

    thanks
    alex krut
    Reply to this Reply to original

  32. Java + Asynchronous interactions and flow, the BPEL way[ Go to top ]

    Alex,

    I don't know where Collaxa's patent is issued (it might be pending). However, you can learn a lot about their orchestration server and BPEL & JBPEL support through their online samples and developer's guide. Hope that helps.

    Cheers.

    Jill.
    Reply to this Reply to original

  33. Java + Asynchronous interactions and flow[ Go to top ]

    Jill

    <quote>I don't know where Collaxa's patent is issued (it might be pending).</quote>

    I tried searching on uspto for the patent that might be issued or pending for Collaxa or Edwin or one of you guys, but could not find anyting that was any close to what you described would be patented.

    Thanks for the links to the samples.

    If you have any further interest in Velare's ATCT technology please follow this link to ATCT Overview. The beta1 technology release will be available anytime in the next 2 weeks.

    regards

    alex krut
    Reply to this Reply to original

  34. Web service orchestration with BPEL4WS[ Go to top ]

    <alex>
    If you have any further interest in Velare's ATCT technology please follow this link to ATCT Overview. The beta1 technology release will be available anytime in the next 2 weeks.
    </alex>

    Thanks for the heads up, I will check it out when it's available. Meanwhile, I've noticed that WebServices.org put a BPEL4WS and Web service orchestration section> up.

    Cheers.

    Jill.
    Reply to this Reply to original

  35. Java + Asynchronous interactions and flow[ Go to top ]

    Brian

    There is no question, it’s possible to implement BPEL interpreter in Java using any XML parser. But in this case developer has to define flow using BPEL any ways.
    OTOH we have such excellent thing as Java that is result of many years of design and development of programming languages. And it’s already created to define flow in your program.
    It means that Java is THE flow language. Why should we invent something else?

    But we are talking about very long running processes here, when you have to wait for days and may be months until response on your message will be received back. Unfortunately we cannot use traditional thread semantics in this case.
    Imagine Java thread waiting for so long time; imagine thousands of pending messages waiting for responses, how much system recourses such system will consume, what will happen if server crashes?

    The only Java based solution we can build right now is to use the event-driven architecture that is completely unsuitable for development of the processes with sophisticated flow patterns.

    >I'm just not sure that a custom mapping between WSBPEL and Java, such as yours, is optimal.

    No, no, I’m not proposing to use mapping between WSBPEL and Java, I’m just saying that we don’t need BPEL at all.
    We have Java, and the only thing we need is to create mechanism to handle long-running processes in Java.
    Velare created technology that can be used for “thread serialization”, it allows you to start your process in special “thread” that can be stopped at any moment, serialized and persisted in storage where it will not consume any system resources except HD space. You can store your process at the moment when you send a message.
    After getting response (once again after days or months of waiting) you can deserialize your thread and start execution from exactly the same point where you stopped it. The response message can be passed to your process using various mechanisms.
    And all this can be done using J2SE + small (60K) jar file!!!!
    And you can use Java to program any flow pattern, and you have all the power of OOP and Java API at the same time!!!

    Serguei Mourachov
    Reply to this Reply to original

  36. Java + Asynchronous interactions and flow[ Go to top ]

    <quote>
    No, no, I’m not proposing to use mapping between WSBPEL and Java, I’m just saying that we don’t need BPEL at all.
    </quote>

    Oh. Of course myself and standards bodies W3C and OASIS and commercial hogs like Sun, Microsoft, IBM, and BEA disagree with your last clause. We think choreography should be data driven with XML. Dialects such as XSLT, JSP, Ant, and o:xml show that XML readily captures algorithms, with the added benefits of standard parsing and self description. Toss in JAXB/P and that surely makes a good Java API for controlling choreography via WSBPEL. Of course, except for long-running transactions, as you noted. The matter of pickling participating threads and locks is an interesting problem for which not even J2EE directly helps. Still, there might be some pattern of durable JMS subscription that adequately approximates JVM thread synchronization. Maybe your proprietary snapshotting library deserves to be open sourced. Long-running synchronization is something new for me to ponder.

    <quote>
    And you can use Java to program any flow pattern, and you have all the power of OOP and Java API at the same time!!!
    </quote>

    I'm impressed. Hopefully some day it'll speak WSBPEL. Also, you sell a GUI for visually editing work flow, or just an API?
    Reply to this Reply to original

  37. agent/actor solution ?[ Go to top ]

    Brian,

    To help us better understand what an agent/actor solution would look like, could you please translate the loan flow described earlier in this thread into the abstraction provided by such a framework?

    Thank you,

    Edwin
    Reply to this Reply to original

  38. Here is why we need this[ Go to top ]

    Robert,

    JAX-RPC is only a small part of the solution. Since this is a Java forum lets start with a quote by James Gosling:


    "SOAP is an overhyped rehash of RPC that will evolve into a semi-chaotic system of integrated services." -- James Gosling

    Dr. Gosling is correct. But that is because as you did, he is only looking at 1/2 of the problem.

    Honestly if you step back XML Web Services is nothing but a rehash of CORBA with an ASCII protocol stack.

    WSDL -> IDL
    UDDI - > CORBA Naming
    WSDL2Java -> IDL precompiler
    SOAP -> IIOP

    Now that said, there are two more powerful constructs in the SOAP/WebServices world that we didnt have in CORBA. These were

    1) asynchrnous interactions and
    2) routability.

    Dr. Gosling is right. SOAP is quite likely to just become a chaotic set of flying messages coming from tons of disperate SBA applications. That is because SOAP is simple a transport mecahnism. It does not control of manage what to do with the messages as they fly through the internet cloud. Who gets them, who is interested in them, how are they transformed and when.

    Think of it in terms of telephony. The early telephony systems were like the telegraph. Basically the telegraph was a peer-to-peer propriety business interaction. As time went on, private exchanges were created around the telephone. In these private exchanges within a community we had an operator who routed calls from one person to another. This is somewhat like EDI over a VAN where the VAN provides simple routing and transformation services. Today's telephone systems are automatic, highly distributed, highly available switched networks.

    It is this last step which is missing from the whole XML Web Services world. How do we build these switches which will route, transform, and execute finite business rules and processes on these 'chaotic rpc calls' as they fly across the ether. These specifications like BPEL4WS are designed to solve these problems.

    So saying 'Why not simply use Java and JAX-RPC' is like throwing out todays switched phone system for the old world of telegraphs and operators. Until B2B and EAI can become as automated and robust as picking up the telephone, we are in desperate need of specifications like this.

    Where is the Web Services dial tone.

    /davewolf
    Reply to this Reply to original

  39. Now the real question is....[ Go to top ]

    Why did MS submit to OASIS and not W3C? MS used to consider OASIS about on par with rat poison. Why the change of heart. Is OASIS really the right body?

    /davewolf
    Reply to this Reply to original

  40. Why Microsoft Chose OASIS--[ Go to top ]

    The answer to your question about why MS chose OASIS can be found in an article on this topic. The info on MS's reasons was supplied just a few minutes ago directly by John Evdemon, TC co-chair and MS's program manager for Industry Standards. I know John, and he's a trustworthy source.
    Reply to this Reply to original

  41. Here is why we need this - once verbosity[ Go to top ]

    I would say that Dave is spot on about CORBA analogies.

    Big benies, in addition to asynchronicity are:
    - Vendor acceptance, finally MS seems to be on board and not competing a la DCOM
    - protocol/payload visibility and manipulation. These obviously need to be controlled (eg encrypted where needed) but they further enables lots of more useful *abilities (eg not only routability as you mention but monitorability, transformability, conditionality) via WSBPEL etc. So once verbosity is managed, probably via hardware accelerators INMH (another thread for another day perhaps), XML and web services truly will help solve interoperabilty and economical distributed application deployment.

    Ben


    >
    > JAX-RPC is only a small part of the solution. Since this is a Java forum lets start with a quote by James Gosling:
    >
    >
    > "SOAP is an overhyped rehash of RPC that will evolve into a semi-chaotic system of integrated services." -- James Gosling
    >
    > Dr. Gosling is correct. But that is because as you did, he is only looking at 1/2 of the problem.
    >
    > Honestly if you step back XML Web Services is nothing but a rehash of CORBA with an ASCII protocol stack.
    >
    > WSDL -> IDL
    > UDDI - > CORBA Naming
    > WSDL2Java -> IDL precompiler
    > SOAP -> IIOP
    >
    > Now that said, there are two more powerful constructs in the SOAP/WebServices world that we didnt have in CORBA. These were
    >
    > 1) asynchrnous interactions and
    > 2) routability.
    >
    > Dr. Gosling is right. SOAP is quite likely to just become a chaotic set of flying messages coming from tons of disperate SBA applications. That is because SOAP is simple a transport mecahnism. It does not control of manage what to do with the messages as they fly through the internet cloud. Who gets them, who is interested in them, how are they transformed and when.
    >
    > Think of it in terms of telephony. The early telephony systems were like the telegraph. Basically the telegraph was a peer-to-peer propriety business interaction. As time went on, private exchanges were created around the telephone. In these private exchanges within a community we had an operator who routed calls from one person to another. This is somewhat like EDI over a VAN where the VAN provides simple routing and transformation services. Today's telephone systems are automatic, highly distributed, highly available switched networks.
    >
    > It is this last step which is missing from the whole XML Web Services world. How do we build these switches which will route, transform, and execute finite business rules and processes on these 'chaotic rpc calls' as they fly across the ether. These specifications like BPEL4WS are designed to solve these problems.
    >
    > So saying 'Why not simply use Java and JAX-RPC' is like throwing out todays switched phone system for the old world of telegraphs and operators. Until B2B and EAI can become as automated and robust as picking up the telephone, we are in desperate need of specifications like this.
    >
    > Where is the Web Services dial tone.
    >
    > /davewolf
    Reply to this Reply to original

  42. so these guys (IMB, BEA, MSFT) are going against W3C[ Go to top ]

    To make sure they make money out of this than to submit to W3C and give it to some open source ??
    Reply to this Reply to original

  43. Does BPEL4WS make the grade?[ Go to top ]

    If we apply the criteria for language design mentioned on my previous blog. That is, simplicity, correctness, consistency and completness, it fails to make the grade.

    see: http://www.freeroller.net/page/ceperez/20030423#discordant_web_service_orchestration
    Reply to this Reply to original

  44. The supremacy of XML grammar, Does BPEL4WS make the grade?[ Go to top ]

    Your blog criticizes WSBPEL as: "It assumes programming in XML to be better than programming in a normal language."

    Somehow you've managed to take an immense strength and falsely spin it as an unspecified weakness.
    Reply to this Reply to original

  45. The supremacy of XML grammar, Does BPEL4WS make the grade?[ Go to top ]

    "falsely spin"? So, you disagree with my statement?

    In otherwords, you firmly believe that casting a programming language into xml form is a good idea.

    Well sorry to burst your bubble, fact is, that's not the silver bullet. Just like casting RPC in terms of XML messages doesn't give you instant interoperability. Life isn't that simple, to claim otherwise is what I would call "spin".
    Reply to this Reply to original

  46. XML and programming languages[ Go to top ]

    Carlos,

    Part of the points made earlier in this thread as a response to Robert concerns was that as the industry matures, developers will not have to manually write BPEL4WS. Instead they will use visual process modelling and process scripting[1]. Both abstraction will be pre-processes into BPEL4WS flow byte code and run in standard infrastructure.

    [1] by process scripting I mean new programming interface that will combining a 3GL language (Java, C#, EcmaScript, etc) with BPEL annotation/semantics. This is similar to how JSP combines HTML and Java into a higher level abstraction.

    By the way, I understand how you might prefer XQuery to XSLT. But I do not understand why you do not like Tag Libraries...they promise better encapsulation, reuse and change management and actually deliver on that promise! Would you rather see tons of spaghetti code in your JSPs?!!?

    Edwin
    Reply to this Reply to original

  47. XML and programming languages[ Go to top ]

    Edwin,

    Precisely, you shouldn't have to write BPEL4WS its just too ugly. You can think of it rather as a means of exchange between various platforms. The way I look at it is this: BPEL4WS is a view (possibly one of many) that allows me to interchange information about my process. That I think is necessary, however inventing an XML language to define workflow is the wrong emphasis.

    Here's my take on that: http://www.freeroller.net/page/ceperez/20030423#why_programming_in_xml_is

    TagLibs aren't that bad, however have you seen the ones with programming constructs (i.e. if, else, etc), its just plain ugly!

    Carlos
    Reply to this Reply to original

  48. XML and programming languages[ Go to top ]

    <carlos>BPEL4WS is a view (possibly one of many) that allows me to interchange information about my process</carlos>

    Interestingly, as far as I know, BPEL4WS scripts are for internal consumption only.
    It’s an orchestration script; it’s not very useful for anyone else.
    Where is no inter-script communication except the case when you wrap one script in WSDL-SOAP call and invoke it from another script.
    BPEL4WS doesn’t introduce any new level of interoperability on top of SOAP-WSDL.

    Serguei Mourachov
    Reply to this Reply to original

  49. XML and programming languages[ Go to top ]

    Serguei,

    Is that correct? You mean its not something that I can interchange so I can coordinate my business process?

    Now if that's true, then what in the world is BPEL4WS for anyway?

    Carlos
    Reply to this Reply to original

  50. XML and programming languages[ Go to top ]

    Carlos

    I couldn’t find anything about peer-to-peer message exchange pattern in BPEL4WS spec.
    For me it looks like BPEL4WS defines some orchestration flow with multiple partners (webservices) without explicit isolation of the peer-to-peer subflows.
    It’s not clear how to extract information about concrete peer-to-peer subflow (stateful interaction) from a BPEL4WS script.
    I think it will be really difficult to develop partner application scripts without having such subflow definition.


    Serguei Mourachov
    Reply to this Reply to original

  51. XML and programming languages[ Go to top ]

    Seguei,

    I don't quite understand your terminology, can you explain a little bit more?

    What do you mean by "peer to peer subflow"?

    Anyway, going back to the subject. The primary reason, if there's any reason at all, for representing workflow in terms of xml is to provide a mechanism of interchange. What then is interchanged? My hunch is that is should be something that allows be to implement and validate my side of a business process. It should be a high level specification, declarative perhaps, and possibly independent of implementation. Anything that couples the definition with the actual implementation should be shunned.

    My question is, if anybody can answer, does BPEL4WS provide the necessary information so that 2 or more parties can interact to perform a business process?
    Reply to this Reply to original

  52. XML and programming languages[ Go to top ]

    Carlos

    I looked at new BPEL4WS spec and found that it has better explanation about abstract processes and business protocols.

    <BPEL4WS spec>The definition of such business protocols involves precisely specifying the mutually visible message exchange behavior of each of the parties involved in the protocol, without revealing their internal implementation. </BPEL4WS spec>

    It looks like business protocol defined as an abstract process is a public interface that can be used by partner application developers. Therefore my previous message is misleading.

    But still, it’s not clear how several abstract processes can be combined in one executable process and how abstract processes can be extracted from the existing executable process.

    Serguei Mourachov

    PS “Peer-to-peer subflow” from my previous message is actually a business protocol that defines interaction of two partners.
    Reply to this Reply to original

  53. XML and programming languages[ Go to top ]

    <quote>
    The primary reason, if there's any reason at all, for representing workflow in terms of xml is to provide a mechanism of interchange.
    </quote>

    XML also benefits from standardized text analysis: parsing, validation, syntax coloring, code completion, modular styling, source transformation, querying, fragments, and inclusion. XPath, XLink, XPointer, XSL, CSS, DOM, SAX, and XQuery are standardized patterns that apply immediately to any XML dialect. So users and developers have uniform knowledge they can carry with them to any XML dialect. Whereas the text formatting, processing, and inclusion semantics of C++, Lisp, and ForTran are all terribly peculiar and incompatible. And Perl's grammar and side-effect semantics are indefensible. But there's another immense win for XML: traditional programming grammars are primarily intended for manual authoring only, whereas XML has automatic generation originally designed into it. XML is generative in so many ways: XSL, CSS, DOM, and JAXB all automaticly emit it. Lex and YACC are dead.
    Reply to this Reply to original

  54. XML and programming languages[ Go to top ]

    Brian,

    Let's get something straight here, XML is good for exchange because of the tools you mentioned. But that doesn't mean that its good to implement a lanugage. Have you ever implemented a language? I have, and parsing is just one small part of the overall task. XML tools are just more like tools to support parsing, however all the hard work remains to be done. In short, just because you think that its easier to parse XML than to use a parser generator, doesn't mean it's easier to build a language.

    My point is that implementation should be based on a sound language core, representation for interchange should merely be a view. People seem to make the mistake by approaching it the other way around. That is, build the XML first, build a new language implementation from the xml. That simply is a bad approach, unfortunately that's what most people in industry are doing!

    Carlos

    Carlos
    Reply to this Reply to original

  55. XML and programming languages[ Go to top ]

    People shouldn't forget other aspects of workflow which should be managed in a framework: versioning, for example. If we have lots of concurrent workflows running, and suddenly there's a need to upgrade the process in the middle of that, frameworks should be able to deal with it, finishing running workflows using the "old" specification, and creating new ones using the "new" process. I can't see an easy way to do it unless we use an "external" way of specifying the process. So that's one of the reasons there's a need for a "language" for process specification: so workflow frameworks can manage processes. There are lots of other aspects that demand management of workflow processes, many of which are "dynamic", and you just can't stop your system for a recompile, each time these aspects change.
    Reply to this Reply to original