Tuesday Dec 26, 2006

A proposal for Portlet Repository Protocol

Here is the excerpt on the proposal that I wrote earlier on using the existing Registry Information Model (RIM) and Maven repository for the Portlet Repository Protocol (PRP) definition. Note : The following content is just a proposal for PRP that I sent earlier on the PRP mailing list by no means a agreed interface.

The Portlet Repository Protocol (PRP) is a initiative that tries to define a set of agreed interfaces and meta-data for implementing portlet repositories. The intent of PRP is facilitate distribution of portlets binaries over the wire, where an administrator or a user can download and install portlets by a look-up or search on a PRP based repository.  Its a cross-vendor initiative and more vendors interested in the definition. We encourage you to join the alias and contribute to this definition.

The proposal is based on using the existing standard's and infrastructure rather than building everything from scratch. The proposal uses/builds-upon on the the following infrastructure.

  1. Maven repository infrastructure and its dependency resolution mechanism for download and install &
  2. The standard webservices (WS) registry infrastructure for meta-data definition/search/publish functionalities.

Here are more details/steps of the proposal on PRP in using the existing WS & maven infrastructure.

A. Steps for publishing a portlet:

  1. The portlet-binary /war would be published to a maven repository.
  2. A meta data about the above portlet would be published to the standard WS registry.

B. Download & install:

  1. If the client knows the artifact id i.e not interested in searching the repository.
  2. It can use the standard maven way of downloading the artifact by specifying it in the pom.
  3. A mvn plugin can be provided to install the above artifact on to the portal server ( Note:  Each vendor can provide their own maven plugin for installation, hence it also solve the problem of where each vendor have their own way of deploying a portlet)

C. Search, Download and Install :

  1. A WS client may search the registry based on various query parameters and search for a portlet on the WS registry (this would be a maven plugin too)
  2. It obtains the maven repository and the artifact id as the response of the query.
  3. The client uses the search results to download the maven artifact from the maven repository.
  4. As indicated above the maven plugin to deploy the portlet could be used

D. Supporting preview for a portlet :

  1. While publishing a portlet the administrator could publish the WebService for Remote Portlets(WSRP) artifacts associated with the portlet  (WSRP artifact meaning WSRP Registry Information Model-RIM defined by OASIS). We can even think even about PRP as an add-on to the WSRP RIM or vice versa.
  2. The WSRP artifact points to the WSRP Producer which offers this portlet
  3. The client which is interested in a preview of the portlet could use the standard WSRP interfaces to get the content.

Note : The above need not be limited to preview mode as WSRP supports all modes. So rather than a preview we could call it as "test drive" a portlet.

Note : The above could be a extension and not mandated in the RIM. So this would be a optional meta-data.

E. Cross referencing.

  1. It MAY be possible to cross reference registries that would allow us to import all the data from other vendor hence offering more portlet (Need to check on cross referencing feature in registry)
  2. Worst case importing the meta-data from other registries and importing to our registry would work.

Advantages :

  1. We'd using the standard WS infrastructure (defining metadata, searching and publishing to the registry)
  2. We can take advantage of the maven dependency resolution mechanism ie. a portlet may depended on some software that needs to be in the server classpath etc which can be resolved by the POM.
  3. No need to invent any on the wire protocol rather use maven + WS registry infrastructure.
  4. We can take advantage of the mvn distribution (i.e. we need not write new client or cli etc)
  5. Everything defined above are based on standards so any one can implement their own solution . All we have to agree upon is the meta data.

Items to be done:

  1. Define a meta data for the PRP
  2. Write maven plugins for
    1. publish
    2. search
    3. install of the portlet

If you have any comments or want to see the responses for the above proposal. Pls join the mailing list for PRP.

Wednesday Aug 16, 2006

WSRP and ebXML

The Sun Portal Server 7 is integrated out-of-the-box with Sun Service Registry which allows WSRP artifacts to be published and discovered from the Service Registry. The integration implements some of the usecase mentioned in the ebXML-WSRP integration technote from OASIS

Sun Service Registry is a ebXML based implementation of an webservices registry server. In short Registry Server its a repository of metadata of contents. The registry also offers
  1. Validation, Cataloging, Versioning & Lifecycle Management Service
  2. Notification Service
  3. Discovery & adhoc Query Service
  4. Federated and inter registry links
  5. Access Control Digital Signature etc.
  6. Taxonomies, Classification etc.
A webservice is represented in an ebXML Registry through what is known as a Registry Information Model (ebRIM). Think of the ebRIM as a schema which describes how a service can be represented inside the ebXML registry.

The WSRP - ebXML Registry Technical note is the one which maps the WSRP artifacts to the ebRIM, It also defines some of the usecase on how these WSRP artifacts can be manipulated on the registry server.

To be more specific about WSRP artifacts representation with ebXML registry. The integration/technote allows publishing and discovery of the following WSRP artifacts
  1. A WSRP Producer
  2. A WSRP Portlet
Both the above artifacts are defined as "Services" using the ebRIM.

Apart from the above defined WSRP artifacts the specification allows binding or creating association with the following ebXML artifacts
  1. An Organization
  2. An Administrator/User
The relationship between the objects is as follows
  • An Organization can have 'n' number of Producers (offers Producer Service)
  • A Producer can offer 'n' number of Portlets
  • An Organization can have 'n' number of administrators/users associated with it
The WSRP-ebXML tech note does not mandate that a Producer service should publish all the portlets that are available within the Producer. This is attributed to the fact that given a Producer service a Consumer can discover all the Portlets that are available in other words the WSRP Protocol itself provides discovery of Portlets published by an Producer.

Despite the above discovery mechanism supported by the Producer, there may be a need publish a portlet apart from the Producer that offers the portlets. This is mainly to facilitate finer search criteria's for a Consumer, while searching for portlets.

With the above defined bindings to the registry. A WSRP Producer Portal would have ability to
  • Publish for a WSRP Producer
  • Optionally publish or associate an Organization that offers this Producers
  • Optionally publish the Portlets that this Producer Offers
  • Optionally publish a user/administrator who is associated with the Organization
Alongside an WSRP Consumer Portal would have the ability to
  • Search for a WSRP Producer
  • Search for the WSRP Portlet
  • Search for an Organization that offers WSRP Services
That wraps up short summary of the technote. Will try to post something on Sun Portal specific configuration and steps for doing the above sometime later.

<script type="text/javascript" src="http://www.google-analytics.com/urchin.js"> </script> <script type="text/javascript"> _uacct = "UA-898027-1"; urchinTracker(); </script>



« July 2016