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 (was RE: [wsbpel-implement] Implementation subgroup call 10/13)


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)

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