Dear Amit, let me try to explain further as best I can .... see inline.
Best Steve T On 16 Jan 2006, at 09:28, Amit Gupta ((FSI)) wrote: > Steve, > > I find this comparison of BPEL (process orchestration language) with > Java > (a programming language) a bit out of context of this discussion. > The context is simply why use it anyway. If people are asking about it then they must be interested in using it. I am simply challenging the prevailing market-speak that is often used to justify using it. > > BPEL is obviously not a replacement of Java and no one is denying that > you as a "developer" can write Java (or CSharp) code to create business > processes involving Webservices and other end-points. > I think I may have explained what I mean very badly - a common habit. So let me try again. I do not mean that coding in Java is the same as coding in BPEL. If we followed that through to it's logicial conclusion we would get down to assembler. So that is not what I meant to say as a comparison. What I mean is based on an observation of BPEL tools and prevailing standards. No one codes in BPEL - it's XML and no one really wants to write in XML. Most if not all BPEL tools have a graphical grammar that allows orchestration to be described. The main standard for doing graphical grammars, at least at this stage, is BPMN. So if we have a standard graphical notation and we generate BPEL from it and then generate Java or imbue an application server with the semantics of the generated BPEL, my question is what value is the BPEL. If my language of discourse is BPMN then BPEL does not really give me much at all. I can go from BPMN to Java or imbue some application server with appropriate semantics just as easily as I can do it through BPEL and out the other side. If BPMN can provide the effective high level interchange format for this then my question is simply what does BPEL give me if BPMN describes the same thing? If BPEL gives me more in terms of execution semantics - concrete as opposed to abstract process descriptions - then is BPMN as good at describing abstract processes, in which case what is the value of abstract BPEL? If someone can provide me with good answers I would happily use then to justify using it more than I do (and I am not starting from zero). But as yet I have difficultly when higher level management ask pretty simple questions of this nature. > > BPEL does define "Process Orchestration" in a vendor independent way > - allow processes to be abstract business processes to be defined using > Vendor A's tools and "implemented" using Vendor B's tool. > > "Implementation" in this context refers to actually connecting to > external > entities participating in the business process and making them "talk" > to the business process engine. > > If the enternal participants are already web-services, then this > "implementation" > is built into BPEL semantics itself.. However, as most existing > applications are > not already WebService enabled, most BPEL vendors have extended their > tools to provide a configuration driven approach for exposing a wide > range > of 3'rd party applications as Webservices. > > Hope the above clarifies the level of portability supported by BPEL > semantics. > > Ofcourse, you can create the entire process by writing Java Code - and > some > developers will like to do it this way.. But most business analysts > would like > to work at a higher level of abstraction (as those provided by BPEL > tools)... > > You made a few comments like:- > a) BPEL is not scalable beyond couple of services Its not scalable in terms of describing a business protocol of many roles - partner links are too clumsy for doing this. > b) BPEL does not support recursive model well It does support recursive composition - which I have said. - see Frank Leymann's work on WSFL from which that part is derived. > c) BPEL is centralized execution model See below. > > I think these are likely due to your experience with a particular BPEL > tool, as > most commercial grade BPEL engines suffer from none of the limitations > you > have outlined above. > > BPEL itself neither helps, nor limits the scalability.. Scalability is > simply > a function of how well a particular BPEL engine is architected and > implemented. > > Similarly, BPEL does not hinder recursive execution... Some tools may. > Would appreciate "examples" of the kind of things you think are NOT > possible due to inherent limitations of BPEL > Supposing I want to describe a business protocol between two banks (one acting as a buyer and the other as a seller) and a set of execution vendors (who match buys to sells). If I have a business protocol that requires these roles to interact with each other how can I do this in BPEL without a controlling role? The reason why a controlling role is not allowed is that neither bank nor execution venues will wish to be subservient to any other role. They wish to act as peers but ensure that the services that they connect together work properly (correct sequencing of messages and so on). > > And finally, the market today is starting to see a number of products > which > are offering "distributed BPEL" - where a large business process, > spanning > multiple BPLE processes running on a network of machines, from a single > node in the network. > What are the semantics of such a distributed BPEL process? Given that BPEL describes orchestration from a specific perspective (that of the composed service) is it not the case that there is always a controller at the top. If so how can that controller be distributed and how can you guarantee that BPEL semantics are enforced across such distribution? > Thanks, > Amit Gupta > Fiorano Software Inc. > > ----- Original Message ----- >> From: Steve Ross-Talbot >> To: [email protected] >> Sent: Sunday, January 15, 2006 8:39 PM >> Subject: Re: [service-orientated-architecture] BPEL+ >> >> Interesting questions and answers. Let me try to ground it in what >> Architects want as opposed to >> what vendors suggest we want. And here I have my architect hat on as >> opposed to any of the other >> multitude that I wear. >> >> See inline .... >> >> On 15 Jan 2006, at 06:02, Amit Gupta ((FSI)) wrote: >> >> > Patrick, >> > >> > Please read on for my comments on some of your questions:- >> > >> > > Does any other implementation provide JavaSnippet? >> > > >> > I think most BPEL implementation provide mechanism to include "Java" >> > Snippet. >> > Either directly as Java code embedded within BPEL process translated >> > to Java >> > code during "compilation" of BPEL - or as pluggable components >> (which >> > in >> > turn can be written in Java). >> > >> > Fiorao's BPEL, Oracle's (collaxa) BPEL, BEA's etc.. all provide >> > it...and I am >> > assuming that this is supported in other BPEL engines as well. >> > >> SRT> I am not interested in suppositions. Either it is portable and >> vendor neutral or it is not. >> SRT> Java in itself may well be a language I prefer to use but it does >> not mean as an architect >> SRT> I am free to use it. If I have a large .NET legacy what use are >> Java snippets to me? >> SRT> If we agree that the world is divided into two, the .NET route >> and >> the Java route then >> SRT> BPEL is not at all interesting if it does not provide me with >> interop and vendor >> SRT> neutrality. If it does not what does it give me that Java does >> not >> (and presumably CSharpe)? >> SRT> For example in Java I can write orchestrations and interact with >> Web Services. This is >> SRT> what BPEL is supposed to do. If it doesn't do it in vendor >> neutral >> way then what compelling >> SRT> reason, as an architect, do I have to use it? (You can regard >> that >> as a challenge). >> >> > >> > > What good is BPEL since every implementation seems to have >> multiple >> > > extensions? >> > > >> > This is an often asked question.. Here's how I look at it. >> > >> > BPEL is a language standard for Process "Orchestration" - not >> process >> > implementation. So while most vendors claiming BPEL compliance have >> > completely standard based process orchestration capabilities, the >> > implementation capabilities is where most of the extensions are. >> > >> > As such BPEL value is portable "Process Orchestration" - but not >> > necessarily portable "Process implementation" (unless each end-point >> > of the process is already Web-service enabled). >> >> SRT> What do we mean by "Process Orechstration"? Is it really no more >> than >> SRT> Composition of Web Services into new services such that the new >> service >> SRT> controls (as a broker does) interactions with the other services >> in order >> SRT> to realise a new service? If so again it is what do I get that >> Java (and CSharpe) >> SRT> do not provide me? >> >> SRT> If "Process Orchestration" does not mean this centralised >> brokering of interaction >> SRT> and the associated control then does it mean that BPEL can >> describe some sort >> SRT> of design blue print for interaction of a collection of services? >> This is something >> SRT> that BPEL cannot do in any scalable way. It breaks down after two >> services. If >> SRT> you have three services then the partner links and control become >> far too complex >> SRT> to get any real benefit because you have to describe from a >> single >> service >> SRT> perspective. It has not global model. It was never designed to >> have one and was >> SRT> designed for recursive Web Service composition, whereas WS-CDL >> was >> designed >> SRT> to describe (hence the D in CDL) the blue print interactions. >> SRT> BPEL is somewhat constrained in its execution model. It is >> centralised, hence the >> SRT> vendor implementation that exist today. As an architect I >> certainly want to describe >> SRT> interactions but I do not want to mandate a particular execution >> style. >> >> SRT> If anyone has clear referencable evidence that BPEL is better >> than >> Java I and many >> SRT> other would like to understand why? The only thing that makes >> BPEL >> attractive is the >> SRT> dollars behind it and not the technology nor the standard (in >> waiting) that underpin >> SRT> it. >> > >> > Thanks, >> > Amit Gupta >> > Fiorano Software Inc. >> > >> >> ----- Original Message ----- >> >> From: Logan, Patrick D >> >> To: [email protected] >> >> Sent: Sunday, January 15, 2006 2:15 AM >> >> Subject: [service-orientated-architecture] BPEL+ >> >> >> >> >> >> "IBM... has... Process Server (a BPEL+ engine)" >> >> >> >> I cannot tell for sure looking through some of the results of a >> google >> >> search. Is BPEL+ a standard beyond BPEL or just a name for IBM's >> >> extensions? >> >> >> >> There appear to be multiple implementations beyond IBM that mention >> >> BPEL+. Are they implementing the same extension? >> >> >> >> IBM's BPEL+ mentions JavaSnippet. Is this the same as BPEL/J? Does >> any >> >> other implementation provide JavaSnippet? >> >> >> >> What good is BPEL since every implementation seems to have multiple >> >> extensions? >> >> >> >> Are there any non-trivial in-production orchestrations that are >> >> represented as pure BPEL? >> >> >> >> Are there any reported cases of a team moving BPEL representations >> >> from >> >> one implementation to another beyond the trivial? >> >> >> >> Thanks >> >> -Patrick >> >> >> >> >> >> >> >> >> >> YAHOO! GROUPS LINKS >> >> >> >> ▪ Visit your group "service-orientated-architecture" >> on the web. >> >> >> >> ▪ To unsubscribe from this group, send an email to: >> >> [EMAIL PROTECTED] >> >> >> >> ▪ Your use of Yahoo! Groups is subject to the Yahoo! >> Terms of >> >> Service. >> >> >> >> >> >> >> >> >> YAHOO! GROUPS LINKS >> >> ▪ Visit your group "service-orientated-architecture" on the web. >> >> ▪ To unsubscribe from this group, send an email to: >> [EMAIL PROTECTED] >> >> ▪ Your use of Yahoo! Groups is subject to the Yahoo! Terms of >> Service. >> >> Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/service-orientated-architecture/ <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
