Amit, see inline. I hope that people are not getting board by the exchanges but I think and hope that they are valuable to a better understanding of how to use different technology solutions to solve problems.
See inline .... On 17 Jan 2006, at 15:54, Amit Gupta ((FSI)) wrote: > Dear Steve, > > Thanks for sending in further details... Please note my comments on > some of the > queries posted by you... > > > 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. > > > Let me try and explain the difference between BPMN and BPEL with an > example. > > If we have to represent a simple banking transaction with BPMN, where > we need > to DEBIT $100 from 'Amit' account and CREDIT the same to 'Steve' > account. > > In this case, the BPMN based graphical semantics will simply state the > steps > as Start of Process --> "Validate" Input ---> DEBIT Amit's account --> > Apply Transformation of data --> CREDIT Steve's account --> end of > Process. > > The above BPMN semantics do not define the DATA associated with each of > the steps in above process flow. It simply shows a SHEMATIC of the > process > flow. > > However, when this BPMN compliant flow is converted to BPEL, one can > add > specifics of the "format" of data "going in" or "coming out" of each > of he > steps defined above (and details of the actual transformation applied > as well). > Besides, each of the "steps" can be represented as a WSDL invocation > (which may or may not be implemented using WS over SOAP).. > > As such, I see BPMN as simply the "visual face" of BPEL. > Interesting. I'm not at all sure that BPMN see it like this. They may see it that way in part but I think BPMN has wider applicability that just BPEL. > > > 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. > > > Yes - but some products available in the market today, allow > composition > of multiple such BPEL flows, stung together into a larger BPEL process > either using request/reply semantics or events - resulting in a number > of "centralized" BPEL controllers, working collaboratively to result in > what can be called a "distributed BPEL engine". > But if you have a larger BPEL process something has to orchestrate it. Now you have your server centric single point of failure problem all over again. > > > If so how can that controller be distributed and how can you > guarantee > > that BPEL semantics are enforced across such distribution? > > > See above. Multiple controllers, each running a BPEL "snippet" can be > distributed on a set of nodes (one of the ways to "distribute" such > snippets is using an underlying ESB framework)... > This is not really distributed in any sensible semantic manner. It is just a simplistic design pattern for hierarchical BPEL. Real distribution can only be derived if you know, from a neutral perspective, what the behavior of you entire system should be. Then at least you can project out what you want services to do. You might indeed use BPEL to realise some of those services and you might use C++, Java and CSharpe too. > > Thanks, > Amit Gupta > Fiorano Software Inc. > > > > > >> ----- Original Message ----- >> From: Steve Ross-Talbot >> To: [email protected] >> Sent: Tuesday, January 17, 2006 7:40 PM >> Subject: Re: [service-orientated-architecture] BPEL+ >> >> 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 >> >> ▪ 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/
