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

["John Evdemon" <jevdemon@microsoft.com>]

I'm not sure how useful this scenario may be.  I believe BPEL is
designed for portable processes, not portable human readable source
code.  XML doesn't necessarily guarantee readability (see SVG or any
complex RDF representation).  Human readability should not be a goal of
BPEL since most BPEL will not be consumed by humans.  

> -----Original Message-----
> From: Sazi Temel [mailto:sazi@bea.com]
> Sent: Monday, October 20, 2003 7: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
>