RE: [uddi-spec] Open issue (#16) w.r.t. UDDI-ebXML TN

[Tom Bellwood <bellwood@us.ibm.com>]

Keisuke & Daniel,

If we can come up with a common (recognized) set of roles, why not just
define a roles taxonomy and then categorize the binding or service with
these values?  That would make it simple to do role based inquiries.  Even
if we can't (such as with the url examples below), it still might be
valuable to include this data via a categoryBag to enable the searching for
knowledgable inquirers.

Regards,
Tom

"Daniel Feygin" <feygin@unitspace.com> on 04/07/2003 11:13:08 AM

To:    "'Keisuke Kibakura'" <kibakura@jp.fujitsu.com>,
       <uddi-spec@lists.oasis-open.org>
cc:
Subject:    [ProbableSpam] RE: [uddi-spec] Open issue (#16) w.r.t.
       UDDI-ebXML TN



Keisuke,

I was thinking of a simpler plain text-based value for role in
instanceParms.  The inquirer can determine the role's applicable namespace
from the tModelKey of the tModelInstanceInfo element.  After all, the
client
knows about the BPSS, which means that role name is also known at the time
of inquiry.  Perhaps something along these lines would be sufficient:
<tModelInstanceInfo tModelKey="...tmodelkey of the BPSS...">
    <instanceDetails>
        <instanceParms>
            role=Seller
        </instanceParms>
    </instanceDetails>
</tModelInstanceInfo>

This allows for expansion as we add other parameters in a future version of
the TN while satisfying the needs of the inquiring party to determine
publisher's role in a given business collaboration.  The above may be
sufficient for the reference scenario (actually I'm not convinced - you be
the judge of that), but we can add another parameter to support better
linking of the bindingTemplate to the CPP as below:
<tModelInstanceInfo tModelKey="...tmodelkey of the BPSS...">
    <instanceDetails>
        <instanceParms>
            CollaborationRole=http://www.a.com/ebxml/cpp.xml#SellerRoleID
        </instanceParms>
    </instanceDetails>
</tModelInstanceInfo>

The CollaborationRole parameter would point to the relevant
CollaborationRole in the CPP.  This way we would defer to the CPP all
further binding details that are specific to ebXML (remember there are some
ebMS settings that do not directly map to UDDI's bindingTemplate, like
non-repudiation and transport security).  Although BPSS role can be
retrieved from the CollaborationRole content, the publisher can provide
both
pieces of information in one tModelInstanceInfo as follows:
<tModelInstanceInfo tModelKey="...tmodelkey of the BPSS...">
    <instanceDetails>
        <instanceParms>

role=Seller;CollaborationRole=http://www.a.com/ebxml/cpp.xml#SellerRoleID
        </instanceParms>
    </instanceDetails>
</tModelInstanceInfo>

This syntax of instanceParms follows the examples of WS-I's Sample
Application Working Group's Supply Chain Management Architecture, see
http://www.ws-i.org/SampleApplications/SupplyChainManagement/2002-11/SCMArch

itecture-0-11-WGD.mht.  Perhaps the naming of those parameters can be
tweaked a bit, e.g. bpss_role and cpp_role or some such.  This is a
separate
issue that needs to be addressed, possibly by the ebXML folks.

Regards,
Daniel


> -----Original Message-----
> From: Keisuke Kibakura [mailto:kibakura@jp.fujitsu.com]
> Sent: Wednesday, April 02, 2003 4:48 PM
> To: Daniel Feygin; uddi-spec@lists.oasis-open.org
> Subject: Re: [uddi-spec] Open issue (#16) w.r.t. UDDI-ebXML TN
>
>
> Daniel,
>
> In ebXML, some layered concepts are introduced to express
> collaborations between parties, which are "business
> transaction", "binary collaboration" and
> "multiparty collaboration". It is not always true that a
> service would be
> equivalent to the simplest case of a binary collaboration.
> Mapping issues
> between "collaborations" in ebXML and "services" in UDDI are
> really really
> complicated matters, and I think there are no established
> solution yet. (It could be possible for someone to write
> about it as an another Technical Note.)
>
> I don't think it's a good idea for us to go into deep
> discussion on "collaboration
> vs. service" at this time; nevertheless I can appreciate the
> importance of modeling "role" with a BPSS reference in
> bindingTemplate.  The option 2 you suggested
> seems fine. According to it, a role information could be modeled in
> tModelInstanceInfo using instanceParms like below:
>
> <tModelInstanceInfo tModelKey="...tmodelkey of the BPSS...">
>     <instanceDetails>
>         <instanceParms>
>             <![CDATA[
>                 <?xml version="1.0" encoding="utf-8" ?>
>                 <BPSSinstanceParmsContainer
>
> xmlns="urn:abc-org:StandardProcess:1:instanceParms">
>                     <role>seller</role>
>                 </BPSSinstanceParmsContainer>
>             ]]>
>         </instanceParms>
>     </instanceDetails>
> </tModelInstanceInfo>
>
> (Since each business process (= BPSS) has its own vocabulary
> to specify
> a role, e.g., "seller", "provider", "retailer", "service
> provider", and so on,
> we cannot prepare fixed word set for this in advance.)
>
> I hope the role information is very helpful for readers of
> this TN to understand.
> In the above case, find_xxx operations does not use the
> information to filter,
> but I don't think it is serious detect.
>
> What do you think?
>
> Keisuke Kibakura
>
>
> ----- Original Message -----
> From: "Daniel Feygin" <feygin@unitspace.com>
> To: "'Keisuke Kibakura'" <kibakura@jp.fujitsu.com>;
> <uddi-spec@lists.oasis-open.org>
> Sent: Wednesday, April 02, 2003 1:45 AM
> Subject: RE: [uddi-spec] Open issue (#16) w.r.t. UDDI-ebXML TN
>
>
> Keisuke,
>
> There is a fundamental discrepancy between ebXML and UDDI
> modeling concepts resulting from the fact that ebXML is
> process-oriented and UDDI is service-oriented.  The
> difficulty in representing ebXML "services" in UDDI has
> substantially deep roots, associated with the lack of a
> service concept per se in ebXML.  Instead ebXML BPSS uses a
> "collaboration" abstract, which aims to specify the process
> of communication between collaborating parties. In doing so
> BPSS also specifies what would be considered service type
> information in Web services parlance, but it covers all
> parties involved in a collaboration in a single document.
>
> I can identify common ground between services and the usable
> subset of collaborations, called binary collaborations, by
> considering both parties to a service - a service provider
> and a service consumer.  Then a service would be equivalent
> to the simplest case of a binary collaboration.  That implies
> changes to the way services are registered in UDDI in order
> to accommodate ebXML, which apparently is the opposite of the
> resolution we seek wrt the issue at hand.
>
> I am afraid that proper modeling of ebXML service types in
> UDDI would be a more laborious undertaking than the most
> recent WSDL TN effort.  However I am willing to propose
> several distinct possibilities for dealing with this issue.
>
> 1. Leave modeling as is.
> Then we have to remove or reword text suggesting that BPSS
> instance references allow to infer supported service's type.
> Instead we need to state that BPSS allows to conclusively
> determine only the types of collaborations supported by the
> organization or its particular service. This raises questions
> about whether BPSS keyedReferences should be in
> businessEntity, in businessService, either of them or both.
> IMO it does not make sense to convey this information in a
> bindingTemplate, because the "technical fingerprint" of the
> binding would be incomplete and therefore inoperable by a
> client.  This would cause bindingTemplates to disappear and
> would make ebXML Messaging Service irrelevant in UDDI.  Also
> we would need to point out that service type and binding
> information would have to be accessed in the organization's CPP.
>
> The value of this approach is questionable, as in the TN's
> reference scenario the BPSS references are used to locate and
> communicate with a trading partner.  This wouldn't  work,
> because the inquirer will find both buyers and sellers by
> issuing the query suggested in the TN.
>
> 2. Use instanceParms to specify role.
> I believe this is the most effective solution pending the
> group's comments. The TN would instruct service publishers to
> include instanceParms in their service binding's BPSS
> tModelInstanceInfo.  Service inquirers would be instructed to
> examine instanceParms to determine who they are dealing with,
> e.g. buyer or seller.  The one functional limitation I see
> right away is that inquiry API does not allow instanceParms
> in find_xxx operations, therefore all bindingTemplates would
> have to be retrieved and filtered for the role being searched
> on by the inquirer.  Anyone sees other problems?
>
> 3. Reject the attempt to directly represent ebXML services.
> This way we would substantially reduce the TN and limit it to
> registering just file-based metadata, such as CPP's, BPSS
> instances and CPA templates. The text would instruct users to
> communicate all ebXML-specific service type and binding
> information through those resources, which are discoverable
> via UDDI.  In practice, most will probably take this route
> anyway.  We can come back to the more substantive issues,
> including this one, in a later revision of the doc.
>
> Thank you,
> Daniel
>
> > -----Original Message-----
> > From: Keisuke Kibakura [mailto:kibakura@jp.fujitsu.com]
> > Sent: Tuesday, April 01, 2003 9:30 AM
> > To: UDDI Spec. TC
> > Subject: [uddi-spec] Open issue (#16) w.r.t. UDDI-ebXML TN
> >
> >
> > Daniel and TN editors,
> >
> > UDDI ebXML TN sub-committee have to resolve the issue raised
> > by Daniel.
> > His comment on the section 2.2.5 (line 514) in
> > uddi-spec-tc-tn-uddi-ebxml-20030319.doc says:
> >
> >   "I am wondering whether this would be sufficient for the
> > counterparty to
> >    determine the service type.  BPSS describes multiple
> > parties to a process
> >    (e.g., a buyer and a seller), but in this context it is
> > impossible to determine
> >    which party of the ones described in BPSS instance the
> > service belongs to.
> >    It is the role in BPSS collaboration that determines the
> > service type, not
> >    BPSS instance itself.  If we do want to venture into
> > registering ebXML services
> >    (and not just file-based metadata), then we need to model
> > every bit of service
> >    type information from the CPP.  Would it be sufficient at
> > this time to allow
> >    registering just the CPP in UDDI?"
> >
> > I think the current solution is sufficient.  It is true that
> > BPSS describes multiple
> > parties involved in a business process. They are 'a buyer'
> > and 'a seller', for instance.
> > As you say, a BPSS instance itself doesn't prescribe a role
> > the service belongs
> > to. Instead, a CPP provides such information that the
> > counterparty can determine
> > the role which the service acts as in the business process.
> > That is, looking inside a CPP, the role of the service can be
> > determined.  If it is needed to re-model some
> > bits of service type information from the inside of the CPP,
> > we might do it. It could
> > be an evolutional version of this TN.  But in that case, what
> > part of the information
> > do we extract from the CPP and re-model? It must depend on
> the case.
> >
> > As for the purpose of this TN which provides basic design for
> > modeling ebXML components and services for UDDI registry, I
> > believe the current solution is
> > good enough as fundamentals
> >
> > How do we resolve this issue? Do you have supplementary text
> > for the current TN?
> >
> > Comments are welcome.
> >
> > Keisuke Kibakura
>
>