OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

uddi-spec message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


Claus, You are right. A CPP has a reference to a BPSS instance which defines interactions between the parties, and has role information which the owner of the CPP plays. A publisher should pick up the name of the role in the CPP carefully and use it as the keyedReference's keyValue. In the case that an inquirer seeks a service provider whose service is conformant to the BPSS instance (as in the reference scenario), it is quite natural to suppose that the inquirer is very familiar with the business process. Therefore, the inquirer has already known the roles used in the BPSS instance at the time of the query. Role information is essentially shared by an inquirer and publisher. What is needed is convention of keyValue's value, which the TN should prescribe. Regards, Keisuke Kibakura ----- Original Message ----- From: "Von Riegen, Claus" <claus.von.riegen@sap.com> To: "'Keisuke Kibakura'" <kibakura@jp.fujitsu.com>; "Daniel Feygin" <feygin@unitspace.com>; "'Tom Bellwood'" <bellwood@us.ibm.com> Cc: <uddi-spec@lists.oasis-open.org> Sent: Thursday, April 10, 2003 10:41 PM Subject: RE: [uddi-spec] Open issue (#16) w.r.t. UDDI-ebXML TN > Keisuke, > > Your analysis of the requirement and the several options is well done and the solution you propose seems to be the most appropriate one: while pretty light-weight, it captures the role information, makes it accessible for inquiries and is easily extensible. > > All what is needed is an explanation for how to consistently use the keyedReference's keyValue. I assume that the keyValue's value is scoped to the (implicitly) referenced CPP. > > Claus > > -----Original Message----- > From: Keisuke Kibakura [mailto:kibakura@jp.fujitsu.com] > Sent: Donnerstag, 10. April 2003 15:15 > To: Daniel Feygin; 'Tom Bellwood' > Cc: uddi-spec@lists.oasis-open.org > Subject: Re: [uddi-spec] Open issue (#16) w.r.t. UDDI-ebXML TN > > > 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 > > > > > > > > > > > >

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]