RE: [wsbpel-implement] RE: [wsbpel-dev] RE: [wsbpel-implement] what attributes the correlation knows about incoming messages?

Title: what attributes the correlation knows about incoming messages?

Hi Bernd,

 

I see your point now, and in a scenario
like that, I really see it as being communication-specific. If the message does
not have enough information in it to be able to use BPEL high-level correlation,
and you use the same port (in the WSDL sense), then you must rely on some communication
implementation-specific correlation to make the message end up at the right
partner link, such as using WS-Addressing in case of SOAP messages (for
example, by using the wsa:ReplyTo and wsa:RelatesTo elements in the
request/reply messages respectively), or perhaps JMS correlation IDs if you use
a JMS binding. My point is that there are many ways of accomplishing this, and
they all depend on what communication binding you use. 

 

Regards,

 

Kristofer

 

From: Eckenfels. Bernd
[mailto:] 

Sent: Monday, April 19, 2004 8:06
PM

To: ;
bpel implementation

Subject: [wsbpel-implement] RE:
[wsbpel-dev] RE: [wsbpel-implement] what attributes the correlation knows about
incoming messages?

 

Hello Kristofer,

 

a simple example, where the part er link
is not know, is the case where you have 2 Business Process, say
"Purchasing" and "Inventory". Both have a partner supplier,
and the engine knows about lets say 10 suppliers. The scenario featres an
acknowledgment business message, which contains
<ack><messagetype>ORDER</messagetype><refnum>123</refnum></ack>
to acknowledge the receipt of an order with the number 123 and the same vor an
inventory message. If I now receive a message from an supplier on the business
signal port, I find 2 business process definitions receiving on that port type
and from one of the suppliers. Therefore the correlator is the only one who can
decide, if this was a message for the inventory or purchasing process.

 

 

This roblem is more common for reliable
B2B messaging than Web services. We use our engine for EDI scenarios, and here
it is common to have hundreds of actual endpoints (for example VAN mailboxes)
behind the same port type, and more than one process definition use this port
type).

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: -
http://www.seeburger.de

-----Original Message-----

From: Kristofer
 Agren [mailto:]

Sent: Monday, April 19, 2004 11:26
PM

To: Eckenfels. Bernd; 'bpel
implementation'; 

Subject: [wsbpel-dev] RE:
[wsbpel-implement] what attributes the correlation knows about incoming
messages?

Bernd,

 

In our case, we rely on knowing the
partner link and operation for an incoming message, and the
“normal” input to the engine consists of the partner link,
operation and the message itself. I do not really understand why the partner
link is so hard to discern, since when a BPEL process is deployed, the engine
knows what partner links, port types and, ultimately, ports that are used to
realize the operations of the process. In our case, the communications binding
that is constructed during deployment is responsible for creating a
“static” route between the actual port, regardless if it is a Web
Service, .NET, JMS, EJB, etc. binding, and the partner link/operation.

 

Regards,

 

Kristofer

 

From: Eckenfels. Bernd
[mailto:] 

Sent: Monday, April 19, 2004 1:33
PM

To: bpel implementation;


Subject: [wsbpel-implement] what attributes
the correlation knows about incoming messages?

 

Hello,

this
is a question to implementors, how they understood the specification:

if
I asume a SOAP Servlet, which will receive HTTP Calls with SOAP (maybe a Axis
Srvice or something like this), it receives a SOAP Call on a specified URL (ip,
port, local part) to a method and with a specific message type. 

With
those parameters, the servlet can look up the operation and port type. 
(since those are not part of the soap call)

It
also has some information about the called (ip, basic authentication, xml
security, soap headers) and may be able to lookup a implementation specific
trading partner. 

But,
it has a hard time to actually know about a partner link. In fact due to
correlations it may not even try to find out the partner link.

So
I asume, that the normal "input" to the correlation engine of a BPEL
engine is the representation of the call, the portType/operation, but not the
partner link. This also means, that the correlation must be able to find the
input message across multiple receives from different or the same process
definitions (i.e. with different partner links).

I
also guess, that most engines will support some policies for actually
restricting incoming messages to a subset of the receive activities, but thtat
does not affect the basic asumption, that the implementaiotn of a bpel engine
has to deal with events to a specified porttype/operation with unspecified
partner link.

Especially
since in the incoming case late binding is as common as in the outgoing case
(partners and partner links in process definitions are very often only
"roles" in B2B scenarios).

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: -
http://www.seeburger.de 

 

Yahoo! Groups Links

 
To visit your group on
     the web, go to:

     http://groups.yahoo.com/group/wsbpel-dev/

       

 
To unsubscribe from
     this group, send an email to:

     

       

 
Your use of Yahoo!
     Groups is subject to the Yahoo!
     Terms of Service.