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
'
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:]
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:]
> 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
> '
> 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:]
> 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:]
> 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
> '
> 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
>
>
>
