[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsbpel-implement] Portable BPEL source code usage scenario (was RE: [wsbpel-implement] Implementation subgroup call 10/13)
Hello, Sazi Temel mentioned the problem, that tools may expand simple constructs into a BPEL form, and that process might be therefore much more complicated on another tool. I just wanted to add a typical example for that: BPMN specifies a lot BPEL bindings, which are more complex than a 1:! mapping, and the resulting BPEL gets pretty hard to read. Actually nobody would model that with a BPEL only tool. I have another example: in our Tool it is possible to do a assign right before an invoke, and it will not require to define a variablke. Of course internally it creates one to satisfy BPEL, but on the graphical layer it is just a parameter mapping from the variable into the invoke message. On import of BPEL we recognize this. But we have great work to do, if we want to recognize this for BPEL scripts which are generated by other tools and possibly have another order (i.e. having the assign right after the receive instead of right bevore the invoke). Just wanted to name those cases, dont know what the reader will do with them :) Mit freundlichen Grüßen Bernd Eckenfels Chief Architect -- SEEBURGER AG - Edisonstr.1 , D-75015 Bretten, Germany Fax: +49 (0)7252 96-2400 - Phone: +49 (0)7252 96-1256 mailto:b.eckenfels@seeburger.de - http://www.seeburger.de -----Original Message----- From: Sazi Temel [mailto:sazi@bea.com] Sent: Tuesday, October 21, 2003 4:01 AM To: Diane Jordan; bpel implementation Subject: [wsbpel-implement] Portable BPEL source code usage scenario (was RE: [wsbpel-implement] Implementation subgroup call 10/13) Diane, Here is the example (usage scenario) that I have mentioned in our last conf call. It is originally suggested by Yaron Golan. The purpose of this usage scenario is to explore whether the purpose of BPEL is to provide portable execution or portable human readable source code. I do not have a concrete example with WSDL/BPEL files etc., after all it is not one of the usual use case which is related to a business process; and I don't think we need one to discuss it anyway. There are different implications for BPEL depending on the answer [ a) provide portable execution, b) provide portable source code or c) both ]. Since it is related to portability issue, I thought the implementation group might find it interesting/useful to discuss. Here is the scenario: Portable Execution or Portable Source? ------------------------------------------------------------ - User A writes a BPEL using their favorite tool Tool_A - User A uses a typical programming construct not provided in BPEL like for-each or if-then or until - Tool A translates the programming construct into a form supported by BPEL - User A hands their BPEL to User B to edit. - User B tries to edit the BPEL using their favorite tool, Tool_B - User B is confused because a lot of the BPEL code looks weird, what has happened is that Tool_B doesn't encode the programming constructs the same way Tool_A has so Tool_B can't represent the constructs in their higher level semantic (e.g. as a for-each) and instead has to show a ton of strange BPEL code with counters and lots of fancy XPATHs etc. Sazi ' Sazi Temel Principle Consultant, Integration Architect ' Sazi.Temel@bea.com BEA Systems Inc. http://www.bea.com 140 Allen Road Office: +1 908 580 3123 Liberty Corner, NJ 07938 Mobile: +1 856 261 8582 -----Original Message----- From: Diane Jordan [mailto:drj@us.ibm.com.bea.com] Sent: Monday, October 13, 2003 5:59 PM To: bpel implementation Subject: [wsbpel-implement] Implementation subgroup call 10/13 Attendees on the implementation subgroup call today were: Monica Martin, Ron Ten Hove, Mike Marin, Ugo Corda, Rania Khalaf, Sazi Temel, Bernd Eckenfels. Major points of discussion (feel free to correct, comment or add to this): - Interoperability for BPEL has a couple facets. By virtue of being based on web services, a level of interoperability is obtained. For this level of interoperability we should reference the work of WSI and BP1.0. We discussed whether there is a higher level of interoperablity for BPEL which would involve the ability for BPEL processes on different deployments to interoperate on a collaborative business process. This concept needs further definition and may evolve from the work of this subgroup. - Portability would be the next level to explore after the intrinsic web services based interoperability. By this we mean the ability to deploy a BPEL process to different BPEL implementation and get the same results at least in the interpretation of the process by the BPEL engine. The execution may vary based on the deployment environment and bindings and actual messages on the wire will differ because of bindings. Identical message flows at this level would not be an objective of portability but might come into play for interoperability. - Scenarios for interoperability and portability would help us to crystalize these points. Sazi has a use case showing interoperability that he will share with us for the next call. We noted that the use case subgroup is developing use cases top down based on business requirements whereas the scenarios we're talking about would be more bottoms up technology examples. - Interoperability at the business process level may bring up QoS issues, for example reliable messaging. Since there are other specs that attempt to address many of these issues that are not widely accepted yet, we will avoid dependancies on them and scope our work to the functions absolutely required. - we have an offer to hold the next face to face in Melbourne Fla either the first or second week of Dec. If we had enough interest we can arrange for space for an implementation workshop of some sort - possibilities range from a showcase of members' implementations to some interoperability or portability work. It was noted that it might be very aggressive to try to do portability or interoperability work in that timeframe. I will discuss this on the next TC call and see if we have sufficient interest (eg, at least 3-5 companies willing to at bring implementations). In a later conversation, I was asked if this would be a public event, and I do not think it should be. - It was suggested that we might want to include consideration of tooling products that produce BPEL as we proceed with implementations. - This group is not intended to focus exclusively on portability and interoperability although the first two meetings were spend discussing this. As a group with particular expertise and interest in BPEL implementations, there are many types of input that would be valuable to the TC and other members of this subgroup (maintaining appropriate confidentiality regarding your companies' plans, products, etc. ). Since the subgroup is not "normative", it will not have formal work products or issues independent of the full TC but can make recommendations to the TC. Additional topics of discussion related to implementations should be sent to the email list. Thanks for your participation - next call is Oct. 27. Regards, Diane IBM Dynamic e-business Technologies drj@us.ibm.com (919)254-7221 or 8-444-7221, Mobile: 919-624-5123
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]