[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsbpel-implement] Portable BPEL source code usage scenario
Sazi, What is a portable human readable source? Are HTML, XSLT, XQuery or SQL a portable human readable source? Edwin > -----Original Message----- > From: Sazi Temel [mailto:sazi@bea.com] > Sent: Tuesday, October 21, 2003 5:22 PM > To: Harvey Reed; Diane Jordan; bpel implementation > Subject: RE: [wsbpel-implement] Portable BPEL source code > usage scenario > > > Harvey, > You got it. The example that Bernd mentioned is I think a > good and 'real' one! I am trying to explore the portability > issue that we have discussed last week at the implementation > subgroup, and thought that this scenario could be a tool to > draw attention one of the interesting portability issue. > > I am not sure yet on the question of whether BPEL should be > portable (executable) process or portable source code.. > Although I cannot remember anywhere in the spec stating it, I > assume John is correct as he mentioned that "... BPEL is > designed for portable processes, not portable human readable > source". Perhaps making this point clearer in the spec would > benefit implementers.. > > 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: Harvey Reed [mailto:hreed@sonicsoftware.com] > Sent: Tuesday, October 21, 2003 9:33 AM > To: Sazi Temel; 'Diane Jordan'; 'bpel implementation' > Subject: RE: [wsbpel-implement] Portable BPEL source code > usage scenario (was RE: [wsbpel-implement] Implementation > subgroup call 10/13) > > > Sazi, > > What you have described sounds like a variant of the "round > trip" story, but with two different tools. In the XML parsing > case, a round trip can be to read in XML, edit, then write > XML, and hopefully the output XML is darn close to the > original, minus editing changes. > > In your use case (which I agree is a different purpose than > the typical use cases discussed in the UC group), you > describe a scenario where the round trip is between two > different tools. In other words after output from the second > tool, you then cannot use it as input back to the first tool. > > Am I close? > ++harvey > > > > -----Original Message----- > From: Sazi Temel [mailto:sazi@bea.com] > Sent: Monday, October 20, 2003 10:01 PM > 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]