[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [uddi-dev] Multiple access points II
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]