OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel-implement message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: [wsbpel-implement] Portable BPEL source code usage scenario


What is a portable human readable source? Are HTML, XSLT, XQuery or SQL a
portable human readable source?


> -----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]