60 likes | 71 Views
This proposal presents a straightforward method to publish WSRP Producers and Portlets in UDDI by categorizing them and utilizing minimal structural elements. Emphasis is placed on simplicity and ease of extension for further discovery. The document outlines the process for publishing the service URL and descriptions, categorizing business services, and referencing the Producer entities. Questions and considerations regarding categorization and extension possibilities are also discussed.
E N D
Publishing Producers – basic ideas • Publish WSRP Producer as a businessService • Categorize this businessService as being of type WSRP-Producer • Use simple approach to publish the URL of service-WSDL and then use the service’s DescriptionInterface for further discovery • At the beginning use an approach as simple as possible, perhaps with minimum amount of tModels and other structures needed. • Proposal should allow easy extension to the UDDI-WSDL documents
Producer <businessService> <Name=…/> <Description=…/> <categoryBag> <keyedReference> tModelKey=… keyName=“WSRP Type” keyValue=“Producer” <tModel> <Name=WSRP Type/> Unchecked Categorization KeyValues would be Producer or Portlet, later might be even PortletApplication <bindingTemplate> <accessPoint=“http://your.com/service.wsdl”/> <tModelInstanceDetails> ..tModelKey=… <tModel> <wsrp_v1_bindings wsdl/> Type: wsdlSpec To indicate it implements the wsrp wsdl Publishing Producers – approach 1
Publishing Portlets – basic ideas • Publish Portlet as a businessService • Categorize this businessService as being of type WSRP Portlet • Need to publish the Portlet handle somehow • Need to reference the Producer the Portlet belongs to • This could be done in two ways: • Either pointer to the Producer’s wsdl • Or reference within the directory to the Producer entity (seems better for to me) • Try to keep it as simple as possible with minimum amount of tModels and other structures needed
Portlet <businessService> <Name=…/> <Description=…/> <categoryBag> <keyedReference> tModelKey=… keyName=“WSRP Type” keyValue=“Portlet” <keyedReference> tModelKey=… keyName=“WSRP Producer Ref” kevValue=“Producer Business Service Key” <tModel> <Name=WSRP Type/> Unchecked Categorization KeyValues would be Producer or Portlet, later might be even PortletApplication <tModel> <Name=WSRP Producer Ref/> Unchecked Categorization KeyValues would be the Producer’s businessService Key <bindingTemplate> <accessPoint=“PortletHandlel”/> Publishing Portlets – approach 1 Note: same tModel as used for Producer categorization
Approach 1 – summary/questions/… • 3 tModels used in total • No redundant information about wsdl, just stored on the producer entity (seems to be natural), Portlets refer to Producer • WSRP Type tModel • Is it sufficient for searching WSRP Producer/Portlets? • Could it be a checked categorization allowing only distinct values? • Producer’s bindingTemplate • tModelInstanceKey references the wsrp-wsdl tModel to indicate a wsrp impl • Do we need this if we have the categorization WSRP Type tModel? • It could be defined as UDDI-tn-v2, Appendix a (external wsdl documents) • Here UDDI defines a WSDL Address tModel to indicate the accessPoint is not an actual access point but the service wsdl URL, do we need that? • Contradiction to UDDI-WSDL proposals (v1 and v2) • We would have one tModel for the WSRP wsdl (containing 4 bindings/portTypes) • While UDDI defines that for each binding/porttype there should be one tModel… • Also UDDI says there must be one bindingTemplate for each portType used (don’t see really why in this case) • Producer Reference tModel • How easy is it to find the businessService entity in UDDI the Portlet businessService is pointing to? • Better ways to add such a reference? • This model could be easily extended to the WSDL-UDDI best practices/technical note proposals