RE: message routing

Title: message routing

Dale

 

I 
agree with a lot that you have to say. But to call out a few points 
...

 

>>>I think we are also going to need to 
revisit terminology, because the tag "Service" has gotten just too tangled up 
now to use.<<<

 

I 
agree. What I think we are really lacking is some good examples that show the 
relationship between a Business Process Collaboration, Business Transaction, 
Role, Service and Action. I have a clear picture in my mind of the relationship 
... but I don't know if everyone will agree. I hope to send something to the 
list soon that we can have a constructive discusion.

 

>>> ... talking about the selling service or 
buying service is semantically like what had previously been called the role in 
a BP.<<<

 

I 
think they are very similar however there are some differences to my mind. 
Specifically, I think that services are re-usable in many roles and therefore 
many business processes. For example consider a company which sends an invoice 
to one of their customers and also makes an insurance claim of some kind 
...

EXAMPLE 1

Buyer                   
Seller

<----------------------Invoice

Invoice Response 
------------>

...

Payment --------------------->

<-------------Payment Response

 

EXAMPLE 1

Insurer                Insured

<------------------------Claim

Claim Response 
-------------->

...

Payment 
--------------------->

<-------------Payment Response

 

The "Payment" 
part could be common to both even though the business process and the roles are 
the same. It could also result in the same messages being sent to the company's 
bank. I don't think that the bank would want to offer two different payment 
"services" just because they are part of a different business 
process.

 

>>>... 
what capabilities are being advertized when the "service" , "action" and 
"role" fields are included in a CPP? or a recipient ... are we saying anything 
more than we can handle the incoming payload so that the output response 
payload(s) can eventually be made available back to the sender (or to other 
nterested parties in the multilateral case)?<<<

 

I don't think so. 
How a message is handled by the recipient is up to that recipient. The sender of 
the message should not need to know.

 

Regards

 

David

 -----Original Message-----
From: Dale Moberg 
[mailto:]
Sent: Friday, July 20, 2001 8:57 
AM
To: Martin W Sachs; 

Subject: RE: message 
routing

  
Marty and Prasad,

  
 

  
It would be useful to assemble some examples/scenarios/etc

  
that show why conversationId, service, and action

  
(and I would add Role in there to the mix) fail to capture

  
what needs to be asserted about multilateral conversations/flows.

  
I suspect that it is true, but we are saying that there 
  is something

  
not expressible by means of certain semantic elements, so

  
we need to be able to show and agree upon some of what is being

  
left out. 

  
 

  
There was general agreement for 
  v1.0 that multilateral CPAs

  
were not in scope, but, as I recall, 

  
it was more because there wasn't

  
enough time to sort all the issues out

  
than a highly principled omission!

  
 

  
I think we are also going to need to revisit terminology, 

  
because the tag "Service" has gotten just too tangled

  
up now to use. For example, (referring to the

  
recent PIP threads), talking about the

  
selling service or buying service is semantically like

  
what had previously been called the role in a BP.

  
[I had always thought that the cluster part ("3A" )of a PIP

  
designation was like a service (which I construed

  
as a bundle of "actions"), whereas the "4" in 3A4 was

  
like the Action designator. Returning the POAck 

  
was the Action that was the business level Response

  
to the PO (3A4), which was the Request. But that

  
might have been entirely my own picture!] And this is

  
still while thinking about conversations, and

  
before we even get to the web "services" turf!

  
 

  
Finally, I think the concern with what information

  
is needed for "routing" to the "application"

  
(and the related process, which is receiving payload(s)

  
from the application and knowing how to 

  
send it off), are basically kinds of information

  
that pertain to the "private intranet side of 

  
integration" and not to the secure packaged

  
transport or public side of integration. This information

  
is important for the configuration of a MSH on its

  
"application" interfacing sides, but is not clearly

  
something that is needed for a CPA when understood

  
as an agreement on those factors needed to

  
exchange business data interoperably. We have

  
always had a tension in deciding how much

  
of this information to capture in CPPs or a CPA.

  
One place to start in rethinking this issue is

  
what capabilities are being advertized when the

  
"service" , "action" and "role" fields are included 

  
in a CPP? For example, for a recipient, 

  
are we saying anything more than

  
we can handle the incoming payload so that 

  
the output response payload(s) can eventually be

  
made available back to the sender (or to other

  
interested parties in the multilateral case)?  

  
Similar issues can be posed about what is

  
being claimed within the CPA context. The

  
point is that the CPA pertains mostly to the contract

  
among/between MSHs, and not to 

  
contracts between MSHs and "applications".

  
 

  
 

  
-----Original Message----- 
From: Martin W Sachs 
  
Sent: Fri 7/20/2001 7:07 AM 
To: 
   
Cc: 
Subject: message 
  routing

  
    
FYI

*************************************************************************************

Martin 
    W. Sachs
IBM T. J. Watson Research Center
P. O. B. 704
Yorktown 
    Hts, NY 10598
914-784-7287;  IBM tie line 863-7287
Notes 
    address:  Martin W Sachs/Watson/IBM
Internet address:  mwsachs 
    @ 
    us.ibm.com
*************************************************************************************
---------------------- 
    Forwarded by Martin W Sachs/Watson/IBM on 07/20/2001
10:06 AM 
    ---------------------------

Prasad Yendluri 
    <> on 07/19/2001 03:58:18 
    PM

To:   Scott 
    Hinkelman/Austin/IBM@IBMUS
cc:   Arvola Chan 
    <>, Martin W 
    Sachs/Watson/IBM@IBMUS,
      David Fischer 
    <>, Burdett 
    David
      
    <>, ebXML 
    Msg
      
    <>, Pete 
    Wenzel
      
    <>
Subject:  Re: PIP 
    IDs

Folks,

I think I agree with Scott, Arvola and 
    Marty :). Bottomline is, the current
model based
on the 
    ConversationId, Service and Action is too inadequate to represent 
    an
arbitrarily
large "conversation", that is potentially 
    "multilateral" (as opposed to the
current
bilateral)  and 
    consists of >= 1 sub bilateral business processes.

I think this 
    would be one of important pieces of work for the next version
of the 
    MS
spec. We need to come up with a more comprehensive, generic, robust 
    and
extensible model
of a "conversation", that identifies a specific 
    exchange belonging to a
"conversation", a
business process instance 
    within, the specific action with that process,
the originating
and 
    receiving parties, the originating and receiving service entities 
    etc.

Regards, Prasad

-------- Original Message 
    --------
Subject: Re: PIP IDs
Date: Thu, 19 Jul 2001 11:41:19 
    -0700
From: Scott Hinkelman <>
To: Arvola Chan 
    <>
CC: Martin W Sachs 
    <>,David 
    Fischer
<>,Burdett
David 
    <>,ebXML 
    Msg
<>,Pete
Wenzel 
    <>

>From the RosettaNet point of 
    view, it will be  desirable if we can have
distinct Service, PIP 
    (equivalently BPSS Business  Transaction), and action
elements in 
    the message header.

Again, my view on this is to define a Qualified 
    Invocation sequence
generically with an arbitrary number of tags, 
    and
drop the tag names "Service" and "Action". Just as ebXML Message 
    Service
defines a SOAP+Attachments Profile,
RosettaNet would define an 
    ebXML Message Service Profile, which would
contain mapping to its 
    PIP,etc,etc, (its invocation qualification).

Scott Hinkelman, Senior 
    Software Engineer
XML Industry Enablement
IBM e-business Standards 
    Strategy
512-823-8097 (TL 793-8097) (Cell: 
    512-940-0519)
, Fax: 512-838-1074

Arvola 
    Chan <> on 07/19/2001 09:03:32 
    AM

To:   Martin W Sachs/Watson/IBM@IBMUS, David 
    Fischer
      
    <>
cc:   Burdett David 
    <>, ebXML 
    Msg
      
    <>, Pete 
    Wenzel
      
    <>
Subject:  Re: PIP 
    IDs

Marty,

Up to now, RosettaNet PIPs are 
    either  request-response (two-actions) or
notification (one-action) 
    style business  processes. Earlier versions of
PIP 3A4 are an 
    exception in the sense  that PIP 3A4 covers Create Purchase
Order 
    (request-response), Change  Purchase Order (request-response) 
    and
Cancel Purchase Order (request-response)  interactions. 
    Recently, PIP 3A4
has been split into 3A4 (Create Purchase Order),  
    3A8 (Change Purchase
Order), and 3A9 (Cancel Purchase Order) in order to 
    achieve  some degree of
uniformity across PIPs (I believe). 
    Therefore, I think it is  reasonable to
equate existing RosettaNet 
    PIPs with BPSS Business  Transactions.

In the RosettaNet message 
    header, there are  separate elements to identify
the PIP ID, the PIP 
    action and the Service.  Multiple PIPs may be
implemented by the 
    same service, e.g., there may be a Buyer  service
implementing PIPs 
    3A4, 3A8, 3A9 from the buyer perspective, and a Seller
service 
    implementing the same PIPs from the seller perspective.

I don't think 
    we should equate PIP ID with Service  and action with 
    "the
particular business transaction within the PIP". Otherwise,  we 
    will not be
able to capture the role information, e.g., the ability 
    to  distinguish a
Buyer Service from a Seller Service, and a request 
    action from a  response
action.

From the RosettaNet point of 
    view, it will be  desirable if we can have
distinct Service, PIP 
    (equivalently BPSS Business  Transaction), and action
elements in 
    the message header. Alternatively, we can  use the Service
element 
    to capture role information (e.g., Buyer vs Seller), and  use 
    the
Action element to capture the PIP ID. Whether we are dealing with 
    a
request action or a response action will have to be inferred from 
    the
Service  element.

Regards,
-Arvola

Arvola Chan 
    ()
TIBCO Software (on loan to 
    RosettaNet)
+1-650-846-5046 (US-Pacific)

----- Original Message 
    -----
From: "Martin W Sachs" <>
To: "David 
    Fischer" <>
Cc: "Burdett, David" 
    <>;  "ebXML Msg" 
    <
>
Sent: Thursday, July 19, 2001 
    8:07 AM
Subject: Re: PIP IDs

In my opinion it makes more 
    sense for Service to point to the PIP ID  and
action to point to the 
    particular business transaction within the PIP.  In
other words one 
    execution of a PIP is a conversation.  I believe that  some
of 
    the PIPs include multiple business  
    transactions.

Regards,
Marty

*************************************************************************************

Martin  
    W. Sachs
IBM T. J. Watson Research Center
P. O. B. 704
Yorktown 
    Hts, NY  10598
914-784-7287;  IBM tie line 863-7287
Notes 
    address:   Martin W Sachs/Watson/IBM
Internet address:  
    mwsachs @  
    us.ibm.com
*************************************************************************************

David  
    Fischer <> on  07/19/2001 10:45:54 
    AM

To:   "Burdett, David" 
    <>
cc:   ebXML Msg 
    <>
Subject:  PIP 
    IDs

David, in the F2F you  mentioned the need for a 
    new element to contain
industry specific business  process 
    identifiers such as a RosettaNet PIP
identifier. Could this be done  
    with Service/Action where the Service would
be something like RNet and 
    the  Action something like PIP3A1  
    (Request
Quote)?

<eb:Service>urn:services:RNet</eb:Service>
<eb:Action>PIP3A1</eb:Action>

Regards,

David  
    Fischer
Drummond  
    Group.

------------------------------------------------------------------
To 
    unsubscribe from this elist send a message with the single 
    word
"unsubscribe" in the body to: