[wsrp-pfb] SHOULD Vs MUST for producer service reference (by UDDIservice key)

[Andre Kramer <andre.kramer@eu.citrix.com>]

Title: RE: [wsrp-pfb] publishing a categorization scheme

The one remaining publishing question I have, and which we discussed on the pfb call Tuesday but would like the whole group to consider, is whether we should require use of one specific standardized link to a producer service when publishing any portlet. This touches on the ASP (Application Service Provider) use case we are discussing, where a portlet belongs to a business other than the one owning and running the producer, but can occur in other use cases. By standardized, I mean fully specified and required by our UDDI tech note.

In our general portlet publishing scenarios, we may want to publish portlets as either abstracted UI services or as specific specialized services provided by an associated producer:

Abstracted UI services allow a registry publisher to advertise a portlet with, for example, human readable documentation on how to register / sign-up for use of the portlet. Admins can search UDDI and discover such services and then use out of band techniques to bind to a portlet's producer. Here the out-of-band binding would a) negotiate the type of protocol binding to use (e.g. how to configure WS Security / SAML QualityOfProtection) and b) provide a registration handle for the consumer to supply in requests over (a).

We already support the second use case quite well (portlet with specified producer link) at least where (a) is done by following a "producer service reference" from the portlet service to the producer service and then to the producer's service wsdl. We do not address (b), directly but that could be added on by extra meta-data in UDDI. Here, we both want to cater for the common case where the producer is also published as a service in the same registry and provide for maximum interoperability by defining one specific way to link to the producer (through the producer's service key/id) and by specifying that use of this specific reference mechanism is a SHOULD or a MUST when publishing any portlet using our recommended best practice.
 

However, I expect that other types of fully specified producer reference mechanisms are likely in practice. For example, a portlet may be published in a private (intra-net / VPN) UDDI registry, while its producer is published in ebXML or in the global UDDI registry. Since the producer is not published separately in the intra-net registry (presumably we are trying to discourage direct use of the producer from the VPN), we can't meet the "MUST add a producer service reference (containing the service key) when publishing a portlet". Some other kind of producer reference is used for (a). That would make this specific use case non-conformant to the technical note and the practice it defines (iff that said "MUST"). However, we would still wish to us other features of portlet publishing (e.g. the common way to publish the portlet handle) to support this alternative (a) use case. We would be able to do this if the producer service reference was a "SHOULD".

We would still be adding some kind of producer reference (e.g. intra-registry or to some other type of Web Service, e.g. using WS-MetaDataDiscovery) so this is not the abstract UI service use case but the second with an alternative (a) rather than no (a). But the result is the same;- consumers may not be able to bind to our portlet if they do not understand our type of producer linking mechanism. That is the interop cost of choosing not to follow a "SHOULD", but the consumer would then state that it "can't bind to a portlet" rather than stating (i.e. conformance asserting) that the portlet was not published correctly (i.e. did not add a producer service reference which is a "MUST" for wsrp UDDI best practice".

In my opinion, I expect both the no (a) and alternative (a) use cases are likely to occur in practice and suggest we allow for this by making use of our producer service reference by service key a SHOULD. We can still require some logical connection between a portlet and its producer (e.g. a portlet MUST include some information, for example, in human readable registration information, of how to locate the producer for the portlet service) but this would not be testable. This would then fully supports both use cases through re-use of elements from our wsrp/UDDI tech note.

regards,

Andre