OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [wsbpel] Issue - 87 - Proposal for Vote - Part 1


+1

Satish Thatte wrote:
If the extra data is binding dependent how can the process logic rely on it?  Processes should not be binding dependent.  If the data is binding invariant then why is it not in the abstract port type?  As we said in the discussion of issue 77, if the port (or message) type is incomplete, you can add a "shim" port type that will provide what you need.  It is not BPEL's business to fix your abstract interface for you.

________________________________

From: Yaron Y. Goland [mailto:ygoland@bea.com]
Sent: Tue 10/5/2004 4:45 PM
To: Eckenfels. Bernd
Cc: wsbpeltc
Subject: Re: [wsbpel] Issue - 87 - Proposal for Vote - Part 1



In your case issue 87 wouldn't apply because you model the binary data
as a WSDL part.

87 only applies to data that is in a message, is not associated with a
part and that the binding chooses to make available.

A classic example of how to use this feature are optional headers. For
example, if someone is using SOAP and wants to have an optional SOAP
header they are out of luck because it is impossible to model optional
headers using WSDL message parts and the standardized SOAP/WSDL binding.
Parts are always mandatory therefore if a header is optional it cannot
be modeled as a part.

A similar problem exists with HTTP and SMTP. Both of those bindings
support optional headers but WSDL isn't currently able to express the
optionality at the part layer.

Issue 87 gets around this problem by providing another point at which
one can get access to message information. The non-bound parts of the
message would show up inside of the ApplicationData container. How this
would occur would be binding specific.

        Thanks,

                Yaron



Eckenfels. Bernd wrote:
  
Hello Yaron,

in our engine we have a similiar extension, which allows us to transport
binary (attachment) data. However we do this inside the WSDL limits, and
require a  part to be defined of a special type. Essentially this part
carries the reference id to the binary attachment. When receiving the
id, you are free to assign it to any outgoing mesage, which will
automatically attach the binary (in a somewhat lazy fashion).

I am not sure if using a element outside the usual WSDL possibilities is
a good ideas since that is somewaht against the idea of well defined
services. Perhaps you have a practical example for your extension?

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: Yaron Y. Goland [mailto:ygoland@bea.com]
Sent: Tuesday, September 28, 2004 8:36 PM
To: wsbpeltc
Subject: [wsbpel] Issue - 87 - Proposal for Vote - Part 1


The original proposal for vote contained two parts, one that defined the
generic mechanism and another that specified language for specific
bindings. In order to allow us to make forward progress I am removing
the section on specific bindings for this vote and instead just focusing
on the mechanism. This vote will not close issue 87 as, if it is passed,
we will still need to decide if we wish to address any binding specific
issues.

14.9 Application Data

Application data is data transmitted in a message outside
of the normal message channel, specifically data in a message that is
not bound to a WSDL message part referenced in the portType/operation
definition that applies to the sent or received message.

To enable BPEL processes to access application data the from-spec is
extended to include:

<from appDataForMessage="ncname"/>

The value of the appDataForMessage attribute MUST be the name of a WSDL
message type variable. The output of this from-spec will always follow
the schema:

<element name="applicationData" type="bpws:tApplicationData">

<complexType name="tApplicationData">
     <sequence>
        <any processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
     </sequence>
     <anyAttribute processContents="lax"/>
</complexType>

The application data will be recorded inside of the applicationData XML
element.

To enable BPEL processes to set application data the to-spec is extended
to include:

<to appDataForMessage="ncname"/>

The schema of the data assigned using this to-spec MUST follow the
previously defined schema or a bpws:mismatchedAssignmentFailure MUST be
thrown.

When a message is received by the BPEL process any application data
associated with the message MUST be made available via the application
data from-spec. The exact means by which application data is retrieved
from a message is binding specific and the binding definition has final
say as to what data will appear as application data but in general any
parts of the incoming message that do not have bindings to specific WSDL
message parts are considered application data. Similarly when a message
is sent if any application data has been associated with the message
then the application data MUST be sent with the outgoing message using
the rules defined for the particular binding in use.

Any application data associated with a WSDL message type variable is
replaced with application data from the incoming message, if any,
whenever that variable is used to receive a new message.

Schema Changes:

Add to tFrom:

<attribute name="appDataForMessage" type="NCName"/>

Add to to:

<attribute name="appDataForMessage" type="NCName"/>

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.



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.


    

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.




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]