[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
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]