[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsrp-pfb] [UDDI#1] How to represent Producer Service Reference
see my comments/answers inline in <rj> Mit freundlichen Gruessen / best regards, Richard Jacob ______________________________________________________ IBM Lab Boeblingen, Germany Dept.8288, WebSphere Portal Server Development Phone: ++49 7031 16-3469 - Fax: ++49 7031 16-4888 Email: mailto:richard.jacob@de.ibm.com |---------+----------------------------> | | Andre Kramer | | | <andre.kramer@eu.| | | citrix.com> | | | | | | 01/19/2004 11:07 | | | AM | |---------+----------------------------> >--------------------------------------------------------------------------------------------------------------------------------------------------| | | | To: wsrp-pfb@lists.oasis-open.org | | cc: | | Subject: RE: [wsrp-pfb] [UDDI#1] How to represent Producer Service Reference | >--------------------------------------------------------------------------------------------------------------------------------------------------| Firstly, I would include the possibility of other (unspecified) kinds of producer reference in 3, and not restrict to only producer wsdl reference (which we would not specify after all). If we can name this bigger option "4", then I would go for that and drop 3 altogether. As I already indicated, this (4) would strongly encourage a producer service key to be used, and the additional complexity would only need to be dealt with when a wsrp consumer goes to use a producer service. <rj> I don't get the point here. The consumer would always need to go to the producer service to retrieve the wsdl URL. This is what the data model defines. If we allow multiple and probably even not specified methods we end up either with consumers picking up the data by merging the result sets from the various methods (what to do if we do not have empty intersections?) or by incompatible publish/find paradigms used by producer/consumers. </rj> It's very much like how we allow a producer to support multiple Web service bindings (SOAP http and https; DIME, SwA etc) via our wsdl. <rj> well, basically we don't since they are not specified. The producer of course may implement additional bindings and even portTypes but it then must not expect any consumer to understand them. So putting this back to the publishing model, we *must* define one crisp method, to allow publish/find work in an interoperable manner accross producer/consumer implementations. Of course a producer can implement any further publishing scheme - but then in must not expect consumers to understand it. </rj> However, our main difference seems to be on what types of query to support (directly in UDDI, without client side result set filtering). I would say we only need to support "find wsrp portlets and wsrp producers" which one can do using the WSRP_PRODUCER and WSRP_PORTLET tModel keys. <rj> this is definitly the basic one, I agree </rj> Producers are "businesses", as are *portlets*, at the logical level. The fact that portlets are hosted in a producer service may not reflect business level realities (e.g. a portlet hosted by an Application Service Provider (ASP)). <rj> I would rather say they are business services. But as of now this reflects the technical level of reality. This is how WSRP is defined. A Portlet is hosted by a Prodcuer, and a Portlet handle is valid within a Producer scope. Therefor we naturally model this relation into the UDDI structures. </rj> The "find all portlets in a producer service" is thus a second-level implementation question only. However, we may want to support this, and the (1) category based scheme can address this requirement when needed (as Richard & Alan point out). However, I would not mandate it, preferring 2 to 1. <rj> I agree, it is not a firstl level business process question, because once we now the producer we can discover all portlets from the service description. However I found that this must be usefull especially when making some "garbage collection" in uddi. We found that sometimes using network connections and having no distributed transaction things might screw up. Es an example when deleting a producer service from uddi one could easily delete all the portlets from that producer, too. It may happen that "dead" entries are made into uddi simply because we don't have distributed transactions. Imagine a portal publishing itself along with 20 portlets to UDDI. Somewhere in the middle the network connection crashes (or whatever). You may end up in an situation where your local transaction (storing information about published portlets into the database) did not complete (because you write to DB after UDDI returns success) and restart the publishing. Know you may end up in published portlets you don't even know about. I think there are more use cases we might think of. So to summerize I found this possibility to find the entities in either way usefull and helpfull. However I agree that to pure "portlet business" this may not be necessary. </rj> This makes publishing portlets more flexible (and easy via UIs) but requires consumers to discover binding information in the following more complex way: <rj> I don't see why we would really want this flexibility. It seems to me that thing get more complicated. On the UI: while exploring the web UIs out there we have seen various flaws or features not implemented. Some web UI can do that other can to this. I wouldn't restrict our model to just rely on current and evidently not completly implemented web UIs. Rather than this I would rely on the UDDI API spec, which is the only interface which defines the communication between registries and clients. I also wouldn't expect to extensive use of the web UIs and think most products will do publish/find under the covers using the API. Btw. allowing multiple methods of how things can be published even confuses users even more. As an example users would have to "mentally build the union" of the different result sets - provided they recalled all methods how to obtain the correct results. </rj> a) look for producer_service_reference binding template (scheme 2) b) look for producer_service_reference category information (scheme 1) c) look for other types of producer reference (4, possibly 3 as first) For the above, we would not specify (c), only allowing it by use of MAY/SHOULDs and would re-order the document to favour (b/2) over (a/1), which I did not do as I was only enumerating options. regards, Andre -----Original Message----- From: Richard Jacob [mailto:richard.jacob@de.ibm.com] Sent: 16 January 2004 17:42 To: wsrp-pfb@lists.oasis-open.org Subject: [wsrp-pfb] [UDDI#1] How to represent Producer Service Reference We discussed different methods on how to represent a reference from the Portlet to its hosting Producer. Following has been put on the table yet. 1. use a categorization scheme The Portlets businessService refers to a "Producer Service Reference" tModel in its categoryBag, the keyValue holds the UUID of the Producer's businessService in the registry. See technote 5.3.1 2. use a binding template The Portlet businessService contains an additional bindingTemplate with a reference to the "Producer Service Reference" tModel, the access point value holds the Producer's businessService UUID in the registry See technote 5.3.3 3. Portlet businessService provides directly the Producer WSDL Not discussed yet the details, but basicly would end up in an addition bindingTemplate, with access point holding the WSDL location. Additional discussion is centered around whether we want to allow for multiple methods or concentrate on one. First I would like to start by repeating my argument from the other threads. In general my opinion is that we should to establish only one way for the representation of the reference. I see the following reasons here: Firstly by makeing things more complicated we raise the barrier for implementors of the search funcionality. Basicly when having Portlets published in different allowed ways we would end up in the need for products which want to support their users with UDDI search functionality to to a programmatical maintainance of result sets, i.e. the set of Portlets found by using method 1 needs to be merged with the set found using method 2 (or 3,4...). It should remain the repositories domain to deliver only one set so applications can pass it directly to the enduser, i.e. we need to make sure that we disconnect data management and programm logic. Furthermore having multiple methods means also to have multiple queries against the directory while in essence searching for one result set. Secondly even if this can be done programmatically we also want to think of users using the standard UDDI UIs (not using product's search facilities). Here the users would have to manually merge the results sets which seem cumbersome to me. Remember that we discuss the introduction of additional methods because option 1. does not allow UI usage in some cases (some UIs do not allow to enter the data needed to implement scheme 1). I was able to use the SAP UDDI test registry UI to implement the scheme, while I was not able to enter the data necessary in IBM's and Microsoft's UDDI UIs. I would also question whether it makes sense to limit ourselves because of UI limitations. Thirdly making things more complicated might reduce acceptance of both programmers and end users. Let's look at two relevant use cases and the methods we have currently: 1. search for portlet(s), find producer hosting it/them, bind... This is possible with approach 1. and 2. because a search for Portlets would be basically a search for businessServices referring to the WSRP_PORTLET tModel. The question how best to obtain the reference to the Producer's businessService can be left out here. It is clear that 1. and 2. both allow it in a quite easy way. 2. search for Portlets that are hosted by a specific Producer This is possible with scheme 1., here categorization can be utilized and the Producer's businessService key can be set to limit the search result to those Portlets which reference that particular Producer. I was able to test this scenario with the SAP UDDI test registry UI, while I was not for the IBM and MS registry for the given reasons. With scheme 2. it is not possible to discover this relation since the inquiry API does not allow to search for businessServices whose bindingTemplate contains a particular value in its access point element. In principle I could happily go either for scheme 1. or 2. depending on the use cases we consider important. However use case 2. seems to me to be a valid question and worth targeting a solution which answers that question. For reasons of referencial integrity I would also discourage us to refer to the Producer by holding the WSDL of the Producer in each Portlet's datastructures. Mit freundlichen Gruessen / best regards, Richard Jacob ______________________________________________________ IBM Lab Boeblingen, Germany Dept.8288, WebSphere Portal Server Development Phone: ++49 7031 16-3469 - Fax: ++49 7031 16-4888 Email: mailto:richard.jacob@de.ibm.com To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/wsrp-pfb/members/leave_workgroup.php .
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]