RE: Draft of Requirements for Intermediary Support for discussion.

Title: RE: PIP IDs

Yes, I 
believe that it may be useful to have a word

such 
as "accountable" to mark when an intermediary

needs 
to be included in the business choreography.

 

There 
may also be other aspects at the technical

level 
that are not so "transparent"-- especially

connected with RM, signals and timeouts, 

and 
the synch and asynch bundling or separation

of 
payload and signals... So I would probably

have a 
1.5 case...

 

Dale

 

-----Original Message-----
From: Stefano POGLIANI 
[mailto:]
Sent: Friday, August 03, 2001 12:25 
AM
To: Dale Moberg; 
Cc: 
Burdett, David
Subject: RE: Draft of Requirements for Intermediary 
Support for discussion.

I 
may state the obvious here, in which case I apologies.

 

But, 
in my opinion:

  
if 
  the intermediary is a "transparent" gateway, i.e. if it is 
NOT ACCOUNTABLE 
  for any problem that may happen 
between the parties, then it may be simply 
  a redirected
URL (in some way, when A wants to talk to B, instead
of 
  specifying http://ebXML.B.com/port it 
  could 
specify http://ebXML.C.com/port )

From A's 
  perspective, the intermediary C is almost 
invisible, it is a "technical 
  issue".

  
if 
  the intermediary is ACCOUNTABLE for any issue that
may happen during the 
  execution of the agreement, then
I think it becomes an ACTOR in the 
  choreography and
should be modelled as such.
I am not sure if it needs 
  to be included in the BPSS or 
if it may simply "mirror" the original CPA 
  (I mean, 
C will play B's role in the CPA with A and it will play
A's 
  role in the CPA with B).

Does 
this make any sense? 

 

/stefano

  
-----Original Message-----
From: Dale Moberg 
  [mailto:]
Sent: 02 August 2001 
  22:10
To: 
Cc: Burdett, 
  David
Subject: RE: Draft of Requirements for Intermediary Support 
  for discussion.

  
         
   DavidBurdett>

  
         
   >> Here is my first cut of the requirements for CPPA 
  that are needed to support  

  
          
  >>  intermediaries. It suggests the 
  development of several  

  
          
  >> different types of CPA/CPP 
  ... 

  
    
 

    
Before getting 
    into the details of your proposed new partitioning of 
    information,

    
I am 
    interested in understanding the need for new 
    functionality. 

    
 

    
Let me start 
    with an intermediary that serves to 
    

    
re-send ebXML 
    messages. A minimalist

    
intermediary could 
    be represented within a CPA by the Endpoint 
    elements

    
within the 
    Transports used by two participants in a collaboration. In other 
    words,

    
for A to send to B 
    via C, A would look at the Endpoint URL for B, and 
    find

    
http://intermediary.net/pathForMsgRouter

    
while B would find 
    the Endpoint URL for A, which perhaps is the 
    same,

    
http://intermediary.net/pathForMsgRouter.

    
 

    
In this case, the URL needed by the 
    intermediary to forward its arriving 
    messages

    
would occur nowhere in the CPA of the 
    two participants. It would be 
    privately

    
maintained in the intermediary's 
    "routing table." This is the current 
    state

    
of "support" for intermediaries, and 
    it is admittedly very meagre and 
    really

    
abstracts an intermediary down to the 
    URL Endpoints it presents to 
    the

    
non-intermediary 
    participants.(I recall that the above is 
    

    
basically how the POC handled 
    CPAs

    
for scenarios involving 
    "hubs")

    
 

    
Given that the CPA 
    is to provide some configuration information needed by 
    MSHes,

    
one step beyond what 
    we now have would be to consider how the CPP and 
    CPAs

    
could be extended to 
    support participants using the Via element within ebXML 
    messages.

    
In other words, we 
    could add something to transport Endpoint notation so 
    that

    
the participants 
    would be able to populate the Via field in their messages 
    that

    
they send. 
    

    
 

    
Beyond this, we 
    could begin to explicitly represent the intermediary as a 
    participant,

    
along with the other 
    parties. To do so, we first could consider 
    the representations

    
within the BPSS for 
    a BP involving an intermediary. Will the BPSS for

    
an intermediary be a 
    multiparty BPSS or will it in fact be the same as for 
    the

    
2 party case? In 
    other words, does the presence of the intermediary 
    make

    
the BP a different 
    business process somehow? If so, how? If not, why 
    not?

    
Presumably the 
    Request and Response documents will stay the same. 
    Will

    
any other aspects of 
    the message change-- packaging, signals, security

    
parameters, and so 
    on? If none of these elements are modified,

    
is  it 
    then safe to assume that the presence

    
of an intermediary 
    does not make any difference for the BPSS?

    
 

    
I suspect that the 
    main impact of having an intermediary will be on

    
the reliable 
    messaging apparatus, possibly some impact on 
    security

    
(though this has 
    possibly been confined and dealt with under the

    
XPath transforms 
    used for signing messages), and possibly some

    
impact on the synch 
    and asynch modes. Are there other impact

    
points when an 
    intermediary is present in the process? These 
    specifics

    
need to be 
    inventoried first, IMO, before we launch off with new 
    flavors

    
of CPPs and CPAs. 
    

    
 

    
For the most part, 
    it seems to be that your requirements jump 
    straight

    
to some proposed 
    solutions, while I had hoped to have requirements, use 
    cases,

    
special situations, 
    and related information that would help us 
    understand

    
the problem better. 
    Then we can consider potential solutions, and 
    evaluate

    
their comparative 
    strengths. We do now have more time to analyze 
    whether

    
to assimilate the 
    intermediary CPA to be a special case of multiparty, 
    or

    
to rather add 
    intermediaries in through special modifications or qualifications 
    under

    
transport, packaging, synch/asynch, and so 
    on.