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


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]