RE: [wsbpel-implement] Portable BPEL source code usage scenario (wasRE: [wsbpel-implement] Implementation subgroup call 10/13)

[Harvey Reed <hreed@sonicsoftware.com>]

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