[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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" <satisht@microsoft.com>, "Ron Ten-Hove"
.com> <Ronald.Ten-Hove@Sun.COM>, <ygoland@bea.com>
cc: <wsbpel@lists.oasis-open.org>
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:satisht@microsoft.com]
Sent: Wednesday, November 19, 2003 2:36 PM
To: Ugo Corda; Ron Ten-Hove; ygoland@bea.com
Cc: wsbpel@lists.oasis-open.org
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:UCorda@SeeBeyond.com]
Sent: Wednesday, November 19, 2003 12:52 PM
To: Satish Thatte; Ron Ten-Hove; ygoland@bea.com
Cc: wsbpel@lists.oasis-open.org
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:satisht@microsoft.com]
Sent: Wednesday, November 19, 2003 12:43 PM
To: Ugo Corda; Ron Ten-Hove; ygoland@bea.com
Cc: wsbpel@lists.oasis-open.org
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:UCorda@SeeBeyond.com]
Sent: Wednesday, November 19, 2003 12:37 PM
To: Satish Thatte; Ron Ten-Hove; ygoland@bea.com
Cc: wsbpel@lists.oasis-open.org
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:satisht@microsoft.com]
Sent: Wednesday, November 19, 2003 12:31 PM
To: Ugo Corda; Ron Ten-Hove; ygoland@bea.com
Cc: wsbpel@lists.oasis-open.org
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:UCorda@SeeBeyond.com]
Sent: Wednesday, November 19, 2003 12:07 PM
To: Satish Thatte; Ron Ten-Hove; ygoland@bea.com
Cc: wsbpel@lists.oasis-open.org
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:satisht@microsoft.com]
Sent: Wednesday, November 19, 2003 12:00 PM
To: Ugo Corda; Ron Ten-Hove; ygoland@bea.com
Cc: wsbpel@lists.oasis-open.org
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:UCorda@SeeBeyond.com]
Sent: Wednesday, November 19, 2003 11:53 AM
To: Satish Thatte; Ron Ten-Hove; ygoland@bea.com
Cc: wsbpel@lists.oasis-open.org
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:satisht@microsoft.com]
Sent: Wednesday, November 19, 2003 11:43 AM
To: Ugo Corda; Ron Ten-Hove; ygoland@bea.com
Cc: wsbpel@lists.oasis-open.org
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:UCorda@SeeBeyond.com]
Sent: Wednesday, November 19, 2003 11:19 AM
To: Satish Thatte; Ron Ten-Hove; ygoland@bea.com
Cc: wsbpel@lists.oasis-open.org
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:satisht@microsoft.com]
Sent: Wednesday, November 19, 2003 11:04 AM
To: Ron Ten-Hove; ygoland@bea.com
Cc: wsbpel@lists.oasis-open.org
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:Ronald.Ten-Hove@Sun.COM]
Sent: Wednesday, November 19, 2003 9:09 AM
To: ygoland@bea.com
Cc: wsbpel@lists.oasis-open.org
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.html) 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/leave_workgroup.php
.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]