Hi Paco,
Just curious: does WSIF allow you to define abstract messages that are not part of an abstract operation?
Ugo
> -----Original Message-----
> From: Francisco Curbera [mailto:]
> Sent: Wednesday, November 19, 2003 3:34 PM
> To: Ugo Corda
> Cc: Ron Ten-Hove; Satish Thatte; ;
>
> Subject: RE: [wsbpel] Issue - 77 - Under specified operation
> definitions
>
>
>
>
>
>
> Hi Ugo,
>
> It is interesting that you mention WSIF because WSIF follows
> very strictly
> the notion that one programs against the explicit porttype
> definition only,
> and relegates all protocol specific stuff down to the
> middleware - where it
> belongs. When we developed WSIF two years ago the whole idea
> was to have a
> Web services programming model counterpart of the WSDL
> separation between
> business interface (the porttype) and protocol and QoS
> specific function
> and artifacts. BPEL embodies today that same approach of
> trying to keep
> binding stuff from obfuscating the business logic while at
> the same time
> allowing you to run over multiple protocols (a fact which we
> conveniently
> exploited building the BPWS4J engine on top of WSIF.)
>
> In any case, I have to agree with you that WSIF lets you do
> really cool
> stuff ;-)
>
> Paco
>
>
>
>
>
>
> "Ugo Corda"
>
>
> <UCorda@SeeBeyond To:
> "Satish Thatte" <>, "Ron Ten-Hove"
>
> .com>
> <>, <>
>
> cc:
> <>
>
> 11/19/2003 05:51 Subject: RE:
> [wsbpel] Issue - 77 - Under specified operation definitions
>
> PM
>
>
>
>
>
>
>
>
>
> All that needs to be said here is that some WS designers
> decided to use the
> full spectrum of the WSDL abstract interface, including
> abstract messages
> not belonging to abstract operations, to define their message
> contents.
> Even though it might be argued that it was not a good
> decision for various
> reasons, they still did that in complete compliance with the WSDL 1.1
> rules.
>
> Exactly how they did their binding mappings is really hard to
> tell in all
> possible cases. You know very well that SOAP has not been the
> only binding
> being deployed so far. For instance, IBM's WSIF
> implementation has been
> around for quite a while and has been supporting all kind of
> other bindings
> other than to SOAP, including (if I remember well) JMS, RMI
> and plain Java
> code.
>
> Ugo
>
> -----Original Message-----
> From: Satish Thatte [mailto:]
> Sent: Wednesday, November 19, 2003 2:36 PM
> To: Ugo Corda; Ron Ten-Hove;
> Cc:
> Subject: RE: [wsbpel] Issue - 77 - Under specified operation
> definitions
>
> My problem is that I can’t pin down where the requirement
> comes from — if
> it is relative to legacy services presumably in the real world that is
> because they are using SOAP. If not, what is it? We can’t
> have a very
> abstract requirement based on arguments about dirty legacy
> problems without
> being specific about those problems.
>
>
> From: Ugo Corda [mailto:]
> Sent: Wednesday, November 19, 2003 12:52 PM
> To: Satish Thatte; Ron Ten-Hove;
> Cc:
> Subject: RE: [wsbpel] Issue - 77 - Under specified operation
> definitions
>
> You are referring to one binding officially supported by WSDL
> (by the way,
> it is not the only one). But this group has previously decided that we
> don't want to limit ourselves to that. So I don't think using
> that argument
> is appropriate in this discussion.
>
> Ugo
>
> -----Original Message-----
> From: Satish Thatte [mailto:]
> Sent: Wednesday, November 19, 2003 12:43 PM
> To: Ugo Corda; Ron Ten-Hove;
> Cc:
> Subject: RE: [wsbpel] Issue - 77 - Under specified operation
> definitions
> The only well-defined way in WSDL to actually use parts of abstract
> messages not appearing in abstract operations is through SOAP header
> binding is it not? Not mentioning it does not make it go
> away, much like
> those legacy services ;-)
>
>
> From: Ugo Corda [mailto:]
> Sent: Wednesday, November 19, 2003 12:37 PM
> To: Satish Thatte; Ron Ten-Hove;
> Cc:
> Subject: RE: [wsbpel] Issue - 77 - Under specified operation
> definitions
>
> The requirement to deal with legacy Web services (it just
> happens to be a
> hot item with my company ;-).
>
> Please keep in mind that my proposed resolution does not
> even mention SOAP
> and bindings. It just extends the current coverage of the abstract
> interface to include abstract messages not appearing in abstract
> operations (which, whether you like it or not, are still
> part of the WSDL
> abstract interface).
>
> Ugo
>
> -----Original Message-----
> From: Satish Thatte [mailto:]
> Sent: Wednesday, November 19, 2003 12:31 PM
> To: Ugo Corda; Ron Ten-Hove;
> Cc:
> Subject: RE: [wsbpel] Issue - 77 - Under specified operation
> definitions
> We came back full circle.
>
> I am starting with the assumption that we do not want to
> deal with SOAP
> complexities and binding issues in BPEL. That leaves us
> with abstract
> WSDL interfaces. This is also Yaron’s position.
>
> Now given this as the starting position (which I know you
> disagree with,
> but suspend disbelief for a moment), what requirements could motivate
> Issue#77?
>
>
> From: Ugo Corda [mailto:]
> Sent: Wednesday, November 19, 2003 12:07 PM
> To: Satish Thatte; Ron Ten-Hove;
> Cc:
> Subject: RE: [wsbpel] Issue - 77 - Under specified operation
> definitions
>
> Satish,
>
> Which requirement are you referring to? A BPEL requirement? A WSDL
> requirement?
>
> As far as I know, according to WSDL (and SOAP too) there is no such
> requirement that a header must be associated with a
> secondary protocol or
> used by intermediaries.
>
> BPEL of course is free to add this requirement, but if it does so it
> should clearly specify that it is something above and beyond what is
> required by the basic specs (and it would still leave us to
> deal - or not
> to deal - with legacy Web services that took a different
> interpretation).
>
> Ugo
> -----Original Message-----
> From: Satish Thatte [mailto:]
> Sent: Wednesday, November 19, 2003 12:00 PM
> To: Ugo Corda; Ron Ten-Hove;
> Cc:
> Subject: RE: [wsbpel] Issue - 77 - Under specified
> operation definitions
> Ugo,
>
> This is just a requirements issue. You are absolutely correct that
> abstract message parts might reflect anything. The
> question is: where is
> the requirement for any additional mechanism coming from if not from
> contingent data being added via secondary protocols or by
> intermediaries?
>
> Satish
>
>
> From: Ugo Corda [mailto:]
> Sent: Wednesday, November 19, 2003 11:53 AM
> To: Satish Thatte; Ron Ten-Hove;
> Cc:
> Subject: RE: [wsbpel] Issue - 77 - Under specified
> operation definitions
>
> The connection between "optional headers" and "secondary
> protocols" is
> completely arbitrary. There is nothing in the WSDL spec
> that says that a
> header that appears in an operation is not related to a "secondary
> protocol", or vice versa that a header that appears in an abstract
> message not part of an operation is indeed related to a "secondary
> protocol".
>
> So BPEL already deals with headers that might be related to
> "secondary
> protocols" and that just happen to be part of an abstract
> operation. Are
> you suggesting we say something in the spec to disallow
> those headers?
>
> Ugo
> -----Original Message-----
> From: Satish Thatte [mailto:]
> Sent: Wednesday, November 19, 2003 11:43 AM
> To: Ugo Corda; Ron Ten-Hove;
> Cc:
> Subject: RE: [wsbpel] Issue - 77 - Under specified
> operation definitions
> Agreed. I was referring more to the intent of Ron’s
> rinsing proposal.
> To repeat his second paragraph
>
> I'm a little leary about having processes directly mess around with
> secondary protocols (i.e. headers). A process could easily become
> overwhelmed with chewing on and processing headers, signatures,
> assertions, and the actual business process being implemented could
> become unreadable. Do we want, at a business level, to be
> messing around
> with such low-level protocols? My sense is that BPEL ought
> to work at a
> higher level of abstraction, if it is to be used to express business
> processes rather than a lot of technical protocol processing.
> This suggests that the *source* of optional headers (“secondary
> protocols”) is out of scope for BPEL, which should “work at a higher
> level of abstraction.”
>
> In case it is not obvious, I should add that I am in
> complete agreement
> with the way Ron has characterized the issue.
>
> Satish
>
>
> From: Ugo Corda [mailto:]
> Sent: Wednesday, November 19, 2003 11:19 AM
> To: Satish Thatte; Ron Ten-Hove;
> Cc:
> Subject: RE: [wsbpel] Issue - 77 - Under specified
> operation definitions
>
> Satish,
>
> The concept of optional header needs to be better specified in the
> context of Yaron's message. There are two cases:
>
> 1 - The optional header is defined in an abstract message
> (this is the
> case I used when raising this issue).
>
> 2 - The optional header is not defined in any part of the abstract
> interface (this is not the case I exemplified when I filed
> this issue,
> and I prefer to keep it out of the discussion of the issue itself).
>
> Yaron's discussion about introspection does not apply to
> case 1. In case
> 1 BPEL does not need to concern itself with how to get to
> the abstract
> message: that is just part of the underlying binding
> machinery. All BPEL
> sees is the abstract message. Reaching that abstract
> message is not any
> more complicated for BPEL than reaching any other component of the
> abstract operation.
>
> Ugo
>
> -----Original Message-----
> From: Satish Thatte [mailto:]
> Sent: Wednesday, November 19, 2003 11:04 AM
> To: Ron Ten-Hove;
> Cc:
> Subject: RE: [wsbpel] Issue - 77 - Under specified
> operation definitions
> Ron,
>
> With your idea of rinsing SOAP off the body of BPEL, your
> agreement with
> Yaron also amounts to rejecting Yaron’s proposals for dealing with
> optional headers. I assume that is intentionally left
> unsaid .. ;-)
>
> Satish
>
>
> From: Ron Ten-Hove [mailto:]
> Sent: Wednesday, November 19, 2003 9:09 AM
> To:
> Cc:
> Subject: Re: [wsbpel] Issue - 77 - Under specified
> operation definitions
>
> Yaron,
>
> I have to agree with you; the only sane course of
> action here is to
> demand that any message constructs that BPEL can use must
> be described
> in WSDL, otherwise BPEL is blind to them. This doesn't prohibit
> lower-levels of a "stack" from mucking around with the
> message further,
> injecting or processing headers as needs be. We sure don't
> want to be in
> business of building exceptions to this rule into the BPEL
> vocabulary!
>
> I'm a little leary about having processes directly
> mess around with
> secondary protocols (i.e. headers). A process could easily become
> overwhelmed with chewing on and processing headers, signatures,
> assertions, and the actual business process being implemented could
> become unreadable. Do we want, at a business level, to be
> messing around
> with such low-level protocols? My sense is that BPEL ought
> to work at a
> higher level of abstraction, if it is to be used to
> express business
> processes rather than a lot of technical protocol processing.
>
> Getting back on topic: some confusion arises with the
> confusion of
> SOAP with WSDL. I know that SOAP and WSDL could have been better
> designed to keep this clearer, but the fact is some (many,
> perhaps?)
> associate web services only with SOAP, and look at BPEL
> as, in part, a
> way to play directly with SOAP messages. This is a
> misleading way to
> look at it, just as it is misleading to regard SOAP as
> just HTTP. Let's
> just rinse all that SOAP off our thinking, and stick with
> nice, clean
> WSDL. :-)
>
> -Ron
>
> Yaron Goland wrote:
> Issue - How do to deal with message content that is not
> specified in the
> WSDL abstract operation definition?
>
> For example, if a BPEL process receives a SOAP
> message with a
> SOAP
> security header that wasn't specified in the WSDL abstract
> operation
> definition then how does the BPEL process reach into the
> header and pull
> out
> the name of the sender so that the BPEL process can send a
> message such
> as
> "I just got a signed message from Joe"?
>
> The inverse example is also possible. The BPEL
> engine may have
> been
> given a standard WSDL definition that does not specify the use of a
> callback
> header in the WSDL abstract operation definition. If the
> BPEL process
> needs
> to insert such a header, how does it do it?
>
> The original issue that started this thread
>
> (http://lists.oasis-open.org/archives/wsbpel/200310/msg00197.h
tml) also
> provides another example of the problem that uses some
> fairly naughty
> but
> not apparently illegal WSDL behavior.
>
> There would seem to be two fairly straight forward solutions to the
> issue -
> Introspection or re-write the WSDL.
>
> Introspection would require us to introduce a new BPEL
> activity that
> could
> somehow plum a message so that it is possible to 'see' parts of the
> concrete
> message that are not present in the abstract operation definition.
> Similarly
> we would need to be able to edit the concrete message
> before it goes out
> in
> order to include content that wasn't defined in the WSDL abstract
> operation
> definition. The complexity of introspection makes for what
> appears to me
> to
> be a solution that is much worse than the problem.
>
> The other solution is to require that people re-write
> their WSDLs. If
> you
> want to receive message content that isn't in the abstract
> operation
> definition you were given then you need to edit the WSDL
> you feed your
> BPEL
> engine to include that content in its abstract operation
> definition. The
> same logic applies to sending messages with content that wasn't
> specified in
> the original WSDL abstract operation definition.
>
> Re-writing WSDLs may not be pretty but introducing
> introspection seems
> worse.
>
> Yaron
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> To unsubscribe from this mailing list (and be removed from
> the roster of
> the OASIS TC), go to
>
> http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/le
ave_workgroup.php
.
