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

[Keisuke Kibakura <kibakura@jp.fujitsu.com>]

Daniel, 

Thanks for your feedbacks. We've got so many numbers of technique-
oriented ideas to specify "role" with a provider's service information. 
The options are as follows; 

a. Leave the current modeling as is (Daniel thinks this has problem.)
b. Use instanceParms. The content of the instanceParms could be:
      b-1. <role>seller</role>
      b-2. role=seller
      b-3. CollaborationRole=http://a.com/url-of-cpp#SellerRoleID
      b-4. (concatenation of b-2 & b-3, delimited by ';')
      b-5. CollaborationRole=<serviceKey-of-CPP>#SellerRoleID
c. Use categoryBag in businessService. The keyedReference could consist of:
      c-1. tModelKey of the universal roles taxonomy if we can maintain such
             set of role, and the role in the keyValue. (thanks Tom)
      c-2  tModelKey=<BPSS_instance_tModelKey>  keyValue="seller"
      c-3. any keywords by general_keyword tModel.
d. Create BPSS role tModels one by one and put them into tModelInstanceInfo

Each solution may have merits and demerits.  Before examining them 
one by one, we have to reconfirm the reason why we want to put "role" 
information into provider's service information, otherwise we get caught 
in technical "cal-de-sac". 

In the reference scenario, these steps below are assumed:

(1) A fictitious consortium (ABC Consortium) creates standard business 
     process for a given industry vertical, and register the tModel of the BPSS.
(2) Fictitious seller Company A implements an ebXML-based service 
     which is conformant to the ABC's standard process. Company A 
     registers its CPP. 
(3) Company A registers the ebXML-based service.
(4) Fictitious buyer Company B finds Company A's service. B is familiar 
      with the standard process (which means that B knows "role") and 
      has already prepared ebXML-enabled business collaboration software. 
(5) Company B locates A's CPP (and start business process).

The current scenario assumes that a buyer company finds a seller company, 
and I believe it is simple and explanatory enough for the readers of this TN 
to understand the fundamental concepts.  If we dare to extract and model 
any information inside a CPP or BPSS instance into UDDI data structure, 
such information should be of that it is really necessary for discovery, and 
should be modeled in the way that it helps discovery via find_xxx operation. 

The "role" information is undoubtedly useful for an inquirer to filter out 
undesirable parties in the step (4) above. Therefore, it should be modeled 
into other than instanceParms so that a knowledgeable inquirer can use it 
for a query. And we should avoid creating more tModels for simplicity. It 
is desirable to make life easier to the potentially UDDI-challenged ebXML
user community. 

I propose compromises:

- We handle "role" information in the TN.
- We put "role" in the categoryBag in seller Company A's service information, 
   so that an inquirer can make use of it.
- We use general_keywords simply to describe "role", e.g.: <keyedReference 
   keyName="role" keyValue="seller"/>,  because:
     1. it is impossible to define universal role taxonomy (objection to the option c-1); 
     2. it is not reasonable to categorize a BPSS instance tModel as 'categorization' 
         (objection to c-2);
     3. it is complicated to create separate tModels for each BPSS instance's 
         role and put them in tModelInstanceInfo (objection to the option d.).

Comments?

Keisuke Kibakura

----- Original Message ----- 
From: "Daniel Feygin" <feygin@unitspace.com>
To: "'Tom Bellwood'" <bellwood@us.ibm.com>; "Keisuke Kibakura" <kibakura@jp.fujitsu.com>
Cc: <uddi-spec@lists.oasis-open.org>
Sent: Tuesday, April 08, 2003 4:38 PM
Subject: RE: [uddi-spec] Open issue (#16) w.r.t. UDDI-ebXML TN


Tom, Keisuke,

I have considered this path, although I do not believe it would be feasible
to define and maintain a universal set of values for such a taxonomy, if I
understand correctly that you suggested so.  We can, however, define an
unchecked roles taxonomy, in which values would be dependent on and derived
from a BPSS instance.  The BPSS instance is where the values will be
defined.  Following this logic I have attempted to craft a plausible set of
modeling proposals, but ended up with the instanceParms.

Because bindingTemplates do not allow categoryBags in V2, each BPSS role
would have to be mapped to a separate tModel, categorized by the
corresponding BPSS instance tModel.  Those tModels would also be categorized
by the roles taxonomy tModel with a role value as defined in the BPSS
collaboration.  These tModels would then become the ones used to signify the
technical fingerprint of the service.

However I still believe that a reference to a corresponding CPP-resident
binding definition is required to obtain the complete details of the
service's technical fingerprint in order to make 'spontaneous'
interoperability possible.  In my view the best way to provide that
reference is still through the service's UDDI binding.  The only way I see
of doing that in V2 is via instanceParms.  That's how I reached the
conclusion that we can make life easier (i.e. lower the learning curve,
reduce barriers to adoption, etc.) to the potentially UDDI-challenged ebXML
user community is by letting them do without the extra tModels.  My feeling
is that instanceParms would be simpler and more ebXML-friendly given that
instanceParms have to be used anyway to refer to the relevant CPP section.

Of course, we can adopt both the BPSS roles taxonomy and the CPP-linked
instanceParms parameter.  The former would enable intelligent
registry-assisted discovery while the latter would apply to post-discovery
phases of collaboration.

Perhaps a more plausible possibility is to elevate BPSS instance
categorization and role value to the businessService categoryBag.  Then we
can categorize the businessService with the BPSS instance tModel, while
putting the role in the keyedReference's keyValue.

What do you think?

Daniel


> -----Original Message-----
> From: Tom Bellwood [mailto:bellwood@us.ibm.com] 
> Sent: Monday, April 07, 2003 10:35 PM
> To: Daniel Feygin; feygin@unitspace.com
> Cc: uddi-spec@lists.oasis-open.org
> Subject: RE: [uddi-spec] Open issue (#16) w.r.t. UDDI-ebXML TN
> 
> 
> 
> 
> 
> 
> 
> 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#S
> ellerRoleID
>         </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/2
> 002-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
> >
> >
> 
> 
>