Re: [uddi-dev] Multiple access points II

[Paul Sterk <paul.sterk@sun.com>]

Claus,

Thanks for your response.  To conclude then, a UDDI businessService can be composed of 1 or more service endpoint URLs.  So, when doing programmatic searches against the Registry, you will first have to find the businessService and then find the bindingTemplate that points to the particular service
endpoint through a tModel.

The next conclusion is that it is a design decision whether or not each businessService implements just one WSDL spec and has just one service end-point.  It can definately have more than one bindingTemplate for indicating other tech specs and classifications. I just think this is more intuitive for
businessService to have one service end-point URL.

To use the example below, I think it is more intuitive for the user to see two businessService entries, one for BOM Explode and one for BOM Implode since each has a different service contract (WSDL) and service end-point URL.

businessService     Binding Template
----------------------------------------------------------------
BOM Implode      Service end-point -> http://hostname1/BOMI
                             tModel                 -> bomi.wsdl

BOM Explode      Service end-point  -> http://hostname2/BOME
                             tModel                 -> bome.wsdl

rather than this:

businessService     Binding Template
----------------------------------------------------------------
BOM                    BOM Implode -> http://hostname1/BOMI
                             tModel             -> bomi.wsdl
                             BOM Explode -> http://hostname2/BOME
                             tModel             -> bome.wsdl

But again this is a design decision.

Paul


"Von Riegen, Claus" wrote:

> Hi Paul,
>
> The answer is the same as the one for your previous question: there is no technical limitation on the type of bindingTemplates your want to group within one businessService. Though, it migth a good modeling approach to separate bindingTemplates that implement different Web service types.
>
> Finding a specific bindingTemplate is carried out by using the find_binding API and putting the wanted tModel in the find_binding's tModelBag. Thus, you can programmatically find only bindingTemplates that implemented bomExplode or bomImplode, respectively - independently of the modeling approach
> used.
>
> I don't have any experience with JAXR. Whether this works in JAXR or not depends on how the mapping to the UDDI APIs is defined.
>
> Claus von Riegen, SAP
>
> -----Original Message-----
> From: Paul Sterk [mailto:paul.sterk@sun.com]
> Sent: Freitag, 7. März 2003 02:30
> To: uddi-dev@lists.oasis-open.org
> Subject: [uddi-dev] Multiple access points II
>
> Hi,
>
> Second question regarding multiple access points per service. A proposal has come up to allow someone to register a service and have multiple accessPoints for the service.  The issue here is that each accessPoint points to a different service.
>
> Let me give an example:
>
> The service is registered as Bill of Materials.  It has two accessPoints:
>
> Bill of Materials Explode
> http://hostname/bomExplode
>
> Bill of Materials Implode
> http//hostname/bomImplode
>
> These are two different services with different associated WSDL docs.
>
> I am personally uncomfortable with this model because I believe that each businessService should be mapped to one service implementation. I feel that BOMExplode and BOMImplode are two different services and should be registered separately.
>
> However, I would like here what your experience and opinions are in this area.
>
> If this model is acceptable, how do you find a specific accessPoint programmtically (JAXR) in UDDI v2.0?  Do you use the tModelInstanceDetails object?
>
> Any feedback in this regard would be very helpful.
>
> Thanks,
> Paul