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

["Edwin Khodabakchian" <edwink@collaxa.com>]

Sazi,

The experience we are seeing from our customers/developers with regarding to
BPEL is very similar to what we saw in the early days of HTML at Netscape.
People would ideally author the entire solution in a design view but they
end up having to sometimes switch to source view (a la dreamweaver). You can
expect that as the language matures (post 1.0 release), it will have better
support for parametric patterns such as for each, etc.. In the meantime,
people will develop custom annotations to encode pattern related information
into the source...at least this is what we are seeing in the field.

Edwin

> -----Original Message-----
> From: Sazi Temel [mailto:sazi@bea.com] 
> Sent: Tuesday, October 21, 2003 5:57 PM
> To: edwink@collaxa.com; Harvey Reed; bpel implementation
> Subject: RE: [wsbpel-implement] Portable BPEL source code 
> usage scenario 
> 
> 
> Hmm.. yes, I think all are human readable, and portable.. 
> Well, one may still find some portability issues in all of 
> them and some may be very difficult to read! Anyway, what I 
> meant was executable code versus source code portability of 
> BPEL process'.
> 
> 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: Edwin Khodabakchian [mailto:edwink@collaxa.com]
> Sent: Tuesday, October 21, 2003 8:32 PM
> To: Sazi Temel; 'Harvey Reed'; 'bpel implementation'
> 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
> > 
> > 
> > 
> 
>