[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsbpel] Issue - 72 - ( was RE: [wsbpel] Issue 47 and WS-I BP 1.0)
Paco,
The reason why bindings and ports were introduced in this discussion is because our use cases will likely say something in that area. (That's why some people have been so concerned about BP 1.0's implications on bindings).
Our TC is about something that has a BPEL component and a WS component (that's why it's called WSBPEL ;-). The main reason for the existence of Web services is interoperability, and I believe the WSBPEL TC should preserve that aspect.
If we only specify our connection to WSDL 1.1, while we know about all its interoperability problems, we do a disservice to the Web services community. So I believe our "allegiance" should be to the combination WSDL 1.1 + BP 1.0. (As discussed before, we all understand that we have to deal with "legacy" WS implementations, so that subject has also to be properly addressed).
Ugo
> -----Original Message-----
> From: Francisco Curbera [mailto:curbera@us.ibm.com]
> Sent: Thursday, October 02, 2003 7:26 PM
> To: Ugo Corda
> Cc: Furniss, Peter; BPEL OASIS
> Subject: RE: [wsbpel] Issue - 72 - ( was RE: [wsbpel] Issue
> 47 and WS-I
> BP 1.0)
>
>
>
>
>
>
> Ugo,
>
> I think Peter already made a related point, but just to
> reiterate the idea:
> BPEL has nothing to say about what ports are offered when the
> process is
> deployed. The validity of a process definition is really not
> affected by
> how the process gets deployed.
>
> When thinking about interop one has to keep the layering of
> specs in mind.
> At some point WS-I may decide to define a profile that includes BPEL.
> Following the natural layering of specs, it should leave all
> BP 1.0 issues
> to WSDL/XSD/SOAP and concentrate on the additional function that BPEL
> introduces. The BPEL interop discussion should not be about
> what ports are
> deployed, but about consistently interpreting process
> behavior, something
> we should be able to do that even in deployments that use proprietary
> protocols (such as SOAP over MQ.)
>
> This is independent of the fact that to achieve end-to-end
> WS-I interop at
> all levels of the stack you'll need to apply the whole stack of WS-I
> profiles.
>
> Paco
>
>
>
>
>
>
> "Ugo Corda"
>
> <UCorda@SeeBeyond To:
> "Furniss, Peter" <Peter.Furniss@choreology.com>, "BPEL OASIS"
>
> .com>
> <wsbpel@lists.oasis-open.org>
>
> cc:
>
> 10/02/2003 01:19 Subject: RE:
> [wsbpel] Issue - 72 - ( was RE: [wsbpel] Issue 47 and WS-I BP 1.0)
> PM
>
>
>
>
>
>
>
> My point is that, for interoperability purposes, a BPEL process should
> provide at least one BP-compliant portType/binding/port. In
> addition to
> that, it could provide any other non-compliant elements.
>
> The "at least one" requirement assures that we would not get into the
> embarrassing situation where two companies build two brand new BPEL
> processes (not talking about legacy Web services here) and
> still the two
> processes would not be able to talk to each other (not too
> good for BPEL's
> reputation ...).
>
> Ugo
> -----Original Message-----
> From: Furniss, Peter [mailto:Peter.Furniss@choreology.com]
> Sent: Thursday, October 02, 2003 10:04 AM
> To: Ugo Corda; BPEL OASIS
> Subject: RE: [wsbpel] Issue - 72 - ( was RE: [wsbpel] Issue
> 47 and WS-I BP
> 1.0)
>
> How on earth is that to be enforced ? Are we considering an
> abstract case,
> a bpel engine, a process script or a particular running
> instance ? Does a
> BPEL script that has one BP-compliant partnerlink become
> illegal if one day
> it's bound (via appropriate WSDL) to MQ ? Must a BPEL engine fault an
> attempt to use it to map between a non-BP 1.0 client and a differently
> non-BP 1.0 service, mangling between the messages to make
> them acceptable
> to each.
>
> Peter
>
> -----Original Message-----
> From: Ugo Corda [mailto:UCorda@SeeBeyond.com]
> Sent: 02 October 2003 17:54
> To: Furniss, Peter; BPEL OASIS
> Subject: RE: [wsbpel] Issue - 72 - ( was RE: [wsbpel] Issue
> 47 and WS-I BP
> 1.0)
>
> Please keep in mind that saying that BPEL should offer a BP-compliant
> service only means that at least one WSDL port offered by
> the BPEL process
> has to be BPEL-compliant. The BPEL process could provide additional
> non-compliant ports and still be considered BP-compliant.
>
> Ugo
> -----Original Message-----
> From: Furniss, Peter [mailto:Peter.Furniss@choreology.com]
> Sent: Thursday, October 02, 2003 2:30 AM
> To: BPEL OASIS
> Subject: [wsbpel] Issue - 72 - ( was RE: [wsbpel] Issue 47
> and WS-I BP
> 1.0)
>
> I would strongly support Postel's law in general, but I'm not sure it
> applies so easily to BPEL.
>
> The detailed content and format of particular messages sent from (be
> conservative) or received by (be liberal) a BPEL process are
> obviously
> subject to Postel's law, but that's a matter for the binding and the
> involved protocols, and their profiles.
>
> The equivalent for BPEL would first appear to be, as Ron
> says, be liberal
> in the web services you use, conservative in the ones you
> offer. However,
> the use/offer polarity is determined by the WSDL MEP's in
> use. In the case
> of asynchronous relationships, where there are paired port
> types one-way
> operations, there isn't any obvious distinction as to which
> side is doing
> the specifying and which is obediently following it. Even for
> request/response patterns, it isn't invariably the case that
> the server
> has freedom to choose (and thus to obey BP 1.0) and the client has to
> follow the dictates of the server (whether it obeys BP 1.0
> or not), which
> is the basis of Postel's law.
>
> For BPEL, or indeed for business protocols in general, which
> side has the
> initiative is probably determined by other features (which
> side has more
> economic clout or more deployed implementation or less intelligent
> developers or got there first). Postel's law applies as
> something like "be
> generous in what you demand of others, providing there is
> unambiguity; be
> precise in how you follow the demands of others, even if it
> doesn't seem
> entirely reasonable".
>
>
> Peter
> -----Original Message-----
> From: Ron Ten-Hove [mailto:Ronald.Ten-Hove@Sun.COM]
> Sent: 01 October 2003 21:48
> To: Eckenfels. Bernd
> Cc: BPEL OASIS
> Subject: Re: [wsbpel] Issue 47 and WS-I BP 1.0
>
> Perhaps we should invoke Postel's law, with respect to
> basic profile
> conformance. To promote interoperability, we should be as
> permissive as
> possible when dealing with (other) web services, but as
> conformant as
> possible when creating our own (BPEL engine provided) web services.
>
> I realize this falls mostly on implementations to worry
> about, but
> the basic profile does contain a lot of restrictions and
> clarifications
> for the "abstract" service model that may be of interest..
> The ban on
> operation overloading might be slightly simplifying, for example.
>
> Anyway, a quick scan of the BP didn't reveal anything
> scary to me. It
> seems to me that WS-I BP 1.0 compliance will be an
> implementation worry,
> but as a technology that will rely on interoperation of our SOAP
> infrastructure, we ought to encourage (but not mandate) BP
> compliance.
>
> -Ron
>
> Eckenfels. Bernd wrote:
> Hello Ugo,
>
> I think it is not good to speak about violation if an
> implementation is able to communicate with an larger number of
> systems.
>
> Perhaps we should chnage this: "conformant BPEL
> engines must be
> able to provide and consume Web Services according to BP 1.0a
> specification. Engine should not provide Web Services
> with HTTP
> SOAP binding other than BP1.0 conformant.
>
> Actually I see the point of requiring BP1.0 support as a
> conformance rule, but I dont see a point of
> restricting engines to
> that, even if it applies.
>
> 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: Ugo Corda [mailto:UCorda@SeeBeyond.com]
> Sent: Wednesday, October 01, 2003 8:28 PM
> To: Satish Thatte; Prasad Yendluri; Eckenfels. Bernd
> Cc: BPEL OASIS
> Subject: RE: [wsbpel] Issue 47 and WS-I BP 1.0
>
> Right, RPC literal would be fine, but RPC
> encoded would be in
> violation.
> -----Original Message-----
> From: Satish Thatte [mailto:satisht@microsoft.com]
> Sent: Wednesday, October 01, 2003 11:23 AM
> To: Ugo Corda; Prasad Yendluri; Eckenfels. Bernd
> Cc: BPEL OASIS
> Subject: RE: [wsbpel] Issue 47 and WS-I BP 1.0
>
> So for instance the RPC encoded services bound
> to SOAP/HTTP
> would be in the “in scope but in violation” category?
>
> From: Ugo Corda [mailto:UCorda@SeeBeyond.com]
> Sent: Wednesday, October 01, 2003 11:18 AM
> To: Satish Thatte; Prasad Yendluri; Eckenfels. Bernd
> Cc: BPEL OASIS
> Subject: RE: [wsbpel] Issue 47 and WS-I BP 1.0
> Let me clarify point 4 (sorry, I mislabeled it as 3) in
> relation to point 1.
> I think we should distinguish services that are
> not compliant
> with BP 1.0 from those that are simply out of
> scope for BP
> 1.0.
> If I have a Web service that is not bound to
> SOAP/HTTP, then
> I would say it is out of scope for BP 1.0, so
> it's OK for
> BPEL to interact with it.
> My point 4 is about services that are within
> the scope of BP
> 1.0 and still do not comply with its requirements.
> Ugo
> -----Original Message-----
> From: Satish Thatte [mailto:satisht@microsoft.com]
> Sent: Wednesday, October 01, 2003 11:09 AM
> To: Ugo Corda; Prasad Yendluri
> Cc: BPEL OASIS
> Subject: RE: [wsbpel] Issue 47 and WS-I BP 1.0
> I doubt that we can mandate BPEL to be used with BP 1.0
> compliant services only especially given the
> answer to 1
> assuming it is correct, and given that there are many
> services today that are not compliant (e.g.,
> RPC encoded
> ones).
>
> From: Ugo Corda [mailto:UCorda@SeeBeyond.com]
> Sent: Wednesday, October 01, 2003 10:55 AM
> To: Satish Thatte; Prasad Yendluri
> Cc: BPEL OASIS
> Subject: RE: [wsbpel] Issue 47 and WS-I BP 1.0
> I see a few separate issues/questions connected to the
> relationship of BP 1.0 and BPEL.
> 1- Would BP 1.0 be restricting BPEL to the
> point that some
> of BPEL's functionality would not be available?
> I cannot think of any such restriction off the
> top of my
> head.
> 2- Would the fact that BP 1.0 only addresses
> the SOAP/HTTP
> binding imply that also BPEL should be limited
> to that type
> of binding?
> I don't think that anybody would imply that.
> 3- Should a BPEL process be offered as a Web
> service that is
> BP 1.0 compliant?
> My answer would be yes.
> 3- Would it be fair to limit BPEL use to
> interacting with BP
> 1.0 compliant Web services only?
> My personal answer would be yes. But I am a
> member of WS-I,
> and I understand other people might have
> different answers.
> Ugo
> -----Original Message-----
> From: Satish Thatte [mailto:satisht@microsoft.com]
> Sent: Wednesday, October 01, 2003 10:39 AM
> To: Prasad Yendluri
> Cc: BPEL OASIS
> Subject: RE: [wsbpel] Issue 47 and WS-I BP 1.0
> For the benefit of the non-expert could post a salient
> example please? Specifically, a BPEL usage
> pattern that
> would not work if BP 1.0 is followed but would
> work if any
> WSDL 1.1 portType is allowed. In other words,
> is BP 1.0 a
> restriction on the WSDL artifacts we use or
> potentially on
> BPEL itself?
>
> From: Prasad Yendluri [mailto:pyendluri@webmethods.com]
> Sent: Wednesday, October 01, 2003 10:11 AM
> To: Satish Thatte
> Cc: BPEL OASIS
> Subject: Re: [wsbpel] Issue 47 and WS-I BP 1.0
> The sections 5.5 and 5.6 in the basic profile (
>
http://www.ws-i.org/Profiles/Basic/2003-08/BasicProfile-1.0
a.htm) are devoted to binding aspects but, several major
sections including section 4, other sections of 5 address
abstract aspects of WSDL, which is a pretty large portion.
All those are applicable BPEL IMO.
Prasad
Satish Thatte wrote:
Most of the BP 1.0 directives are binding related. BP also
forbids outbound operations which BPEL does not use. Can
someone identify a directive in BP 1.0 that actually affects
BPEL?
Satish
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]