RE: Sanity check needed for struggling TPA participant

["Moberg, Dale" <Dale_Moberg@stercomm.com>]

Comments in-line responding to Marty's responses (early Thurs responses)
> Capability Capture and The Issue of Association.
>
> <!-- (PartyId+ , PartyDetails , Role+ ,
> Certificate+ , DeliveryChannel+ ,
> Transport+ , DocExchange+ )-->
>
> Are we capturing the associations
> that are needed to understand
> the capabilities enabling b2b interoperability?
> While we have most of the most common capabilities
> described at some level of detail, what is not so
> clear is that we have ways of stating how these
> capabilities are associated and are integrated
> within a given party's software implementation.
>
> MWS:  You seem to be mainly concerned with associating
> doc exchange and transport properties with an individual
> role.  We need to be able to do it but I think we need
> more work with the BP team on this.  At some point, we
> want to be able to associate a delivery channel with a
> role and underneath the role with specific message
> exchanges (business transaction?) and perhaps
> with specific messages. This is equivalent to binding
> a delivery channel with a role but possibly a different
> delivery channel for each business transaction. That
> means being able to point an xlink directly at a business
> transaction, role, or message.  I'm not sure that the
> specification schema is crisp enough yet to do this.
>

I am beginning to appreciate better how we are hemmed
in by not knowing what form the BP specs will take,
even within the ebXML Metamodel schema point of view.


> MWS:  The operative point is your next paragraph;
> the delivery channel is important to your questions,
> though my comment directly above is still part of
> the discussion.

Yes.

>
> So far you will note that I have suppressed
> discussion of the DeliveryChannel. Will that
> set help? In a way the DeliveryChannel
> is itself part of the association, for a look
> inside its structure reveals that a DeliveryChannel
> is an association of a Transport and a DocExchange.
> So perhaps if we focus on DeliveryChannel
> we will find the needed information about
> associations. However, there remains one
> gap-- the Role, which is a view on the BP,
> is not associated with any of the ChannelIds!
>
> MWS:  As I indicated above, there is an implicit
> assocation between the delivery channel and a role
> through the linkage between the delivery channel and
> a specific business transaction or message, once we
> know how to make that linkage. However maybe we
> should make that association explicit.  Read on.
>
> MWS:  One way to directly associate a role with
> a delivery channel is to move the role tag under
> the delivery channel tag and allow inclusion of either
> one or both roles there.  In that case, we could probably
> also eliminate service binding from role since the
> delivery channel service binding should then be sufficient
> for both role and delivery channel.
>

I think I see what you mean. Here is what I had in mind
because it really is a very conservative addition
that more or less uses the apparatus you already 
have built up.

Modify Party element to something like:

<!-- (PartyId+ , PartyDetails , Role+ ,
 Certificate+ , Implementation+, DeliveryChannel+ ,
 Transport+ , DocExchange+ )-->

<!ELEMENT Implementation  EMPTY> 


<!ATTLIST Implementation 
                 roleId ID     #REQUIRED
                 channelID     #REQUIRED >


Of course, this is just the bare association and
maybe some other stuff could be attached.
The idea is that in the Implementation set
we announce for the given roleids we advertise,
just how (delivery channels) we can do them.

There may be a more economical way to announce
these same associations, especially because
we might have many roleIDs all using the same
channel and we might have many channels 
all usable by one roleID (so we have the
typical many-many modelling issue here).




> MWS:  What remains is your question above: "So how do
> we tell which Role goes with which
> Transports and which DocExchange
> instances?". The answer to this question is that we
> define different delivery channels with the needed
> different combinations of transport and doc exchange
> definitions. This capability is already defined in
> the CPP and prior to that in the IBM tpaML proposal.
> We can then associate each of those delivery
> channels with the appropriate role and
> the appropriate  business transaction
> or message.  As long as the different combinations are at
> the granularity of combinations of transport and doc exchange,
> this should work fine.  If we see a need for combinations and
> permutations at a finer level of granularity (i.e. individual
> transport or delivery channel characteristics,  we will need
> to consider a different representation since a
> finer level of granularity could explode the number of
> delivery channels needed to express it to an undesirable
> degree.  My advice is to restrict ourselves to combinations
> of complete doc exchange and transport definitions for now
> and leave finer granularity for beyond version 1.0

OK, I think the <Implementation> association above
doesn't explode stuff anymore than is needed. I just
think I am endorsing your idea expressed earlier that
it may be possible to make this association more
explicit. I understand your wariness about exploding
the channels. But my concern is that we make certain
that we get fine-grained enought so that we can tell
that the channels interoperate--whatever that takes...



--
                               Christopher Ferris
    _/_/_/_/ _/    _/ _/    _/ Sr Staff Engineer - XTC Advanced Development
   _/       _/    _/ _/_/  _/  Phone: 781-442-3063 or x23063
  _/_/_/_/ _/    _/ _/ _/ _/   Email: chris.ferris@East.Sun.COM
       _/ _/    _/ _/  _/_/    Sun Microsystems,  Mailstop: UBUR03-313
_/_/_/_/  _/_/_/  _/    _/     1 Network Drive Burlington, MA 01803-0903