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:]
> 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
> '
> 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:]
> 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
>
> (919)254-7221 or 8-444-7221, Mobile: 919-624-5123
>
