Developing Portlets with GWT

How to write a portlet with the aim of GWT.

Pre-development Installation

Modifying Tomcat

1. Replace $CATALINA_HOME/webapps/gridsphere/WEB-INF/CustomPortal/layouts/TemplateLayout.xml with the corresponding one found here.
2. Include the gwt.js and script.html files found here in $CATALINA_HOME/webapps/gridsphere/html directory.

The Service resource

Usually, a Service is defined as a software system that delivers functionalities. In DILIGENT, a Service is a not-empty set of related Packages (connected through dependencies) forming an unique logical entity. A Package is the smallest installable unit of software that can be deployed on a DHN (e.g. a JAR o a GAR archive). Packages are the way in which the software needed to set up a DL has to prepared in order to be used and stored in the system. Once the service components have been developed, they must be described by compiling the service profile.

Package types

Concretely, a Package is a “piece of software” that can be deployed on a DHN. A Package can be:

• a WSRFService, representing a package that once deployed produces a WSRF Service (a service able to manage stateful resources following the WS-Resource patterns);
• a Portlet, representing a package that once deployed produces a portlet (Web components, managed by a portlet container, that process requests and generate dynamic GUI content) that can be hosted in a DILIGENT Portal;
• a GridJob, representing a package containing the code and the related information needed to run a certain job on the grid infrastructure;
• a Library, representing a software library (typically a JAR) that can be hosted on a DHN. There are three types of library:
  • Shared Library, software library offering functionality of common utility, e.g. an XML parser library or a mathematical support library;
  • Stub Library, software library offering functionality for interacting with WSRF Services.
  • External Library, a thirdy party library available on the ETICS Repository that can be dynamically deployed.
• Software, a thirdy party software distributed with the service that can be dynamically deployed;
• ExternalSoftware, a thirdy party software available on the ETICS repository that can be dynamically deployed.

About how to define a package of any type above, see the PackageList section.

Composition

The set of Packages forming a Service is composed by:

1. one and only one Package of WSRFService or Portlet type (the main package)
2. an arbitrary number of other Packages of different type logically related (even if not used) to it.

The "main" part of a Service is, of course, the WSRFService package from which the related Running Instance resource is generated. The other packages can be

• helper modules developed and used by the WSRFService
• thirdy parties software used by the WSRFService
• helper modules developed and distributed with the WSRFService in order to be used by other Services to interact with a Running Instance of the Service.

How to specify dependencies

A package, once deployed, can rely on other software to perform its activities. Let's see how to specify these dependencies by distinguishing among:

• software developed within this service (this is the case of a stub library, for instance)

  → the software has to be declared as Library and the dependency is specified as package Dependency

• software developed and distributed within other DILIGENT services

  → the dependency is specified as package Dependency against a package defined in another Service profile

• thirdy party deployable software used only by this service

  → the software has to be declared as Software or Library (it depends on the nature of the software) and the dependency is specified as package Dependency

• thirdy party deployable software used by other services

  → the software has to be uploaded in the ETICS repository, the package has to be declared as ExternalSoftware and the dependency is specified as package Dependency

• thirdy party software that is not dynamically deployable

  → the software has to be manually installed, the label has to be manually declared in the DHN profile (by the DHN owner) and the dependency is specified as DHN Requirement

How to compile the profile

The following example shows the common elements that compose the Service profile. The Package-specific sections are explained apart later.

<DILIGENTResource xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<UniqueID/>
	<ResourceType>Service</ResourceType>
	<AuthorizationPolicies>
		[...]
	</AuthorizationPolicies>
	<Profile>
		<Class>MetadataManagement</Class>
		<Name>MetadataCatalog</Name>
		<DescriptiveParameters>
			<DescParameter/>
		</DescriptiveParameters>
		<QoS/>
		<DeploymentInfo>
			<Deployable value="true"/>
		</DeploymentInfo>
		<DLDependencies>
			<DLComponent>
				<Class>MetadataManagement</Class>
				<Name>XMLIndexer</Name>
				<DescriptiveParametersValue/>
			</DLComponent>
			<DLComponent>
				<Class>ContentManagement</Class>
				<Name>StorageManagementService</Name>
				<DescriptiveParametersValue/>
			</DLComponent>
			<DLComponent>
				<Class>ContentManagement</Class>
				<Name>CollectionManagementService</Name>
				<DescriptiveParametersValue/>
			</DLComponent>
		</DLDependencies>
		<SpecificData/>
		<PackagesList>
                 [...]
		</PackagesList>
	</Profile>
</DILIGENTResource>

Common elements

Class

The class of a service is it's functional area. The following values are accepted as service classes:

• InformationSystem
• Keeper
• VDLGenerator
• BMM
• DVOS
• Search
• Index
• DataFusion
• CSD
• CSS
• ProcessManagement
• Annotation
• FeatureExtraction
• Personalisation
• ContentSecurity
• ContentManagement
• MetadataManagement
• Portal

Name

The Name is an arbitrary string that uniquely identifies the service within a service class.

DLDependencies

A DILIGENT service is part of a complex system and it makes use of other services. At VDL definition time, firstly, it is compiled the list of services that satisfy the VDL definition criteria and, then, such a list is completed with the other services that allow the first ones to work properly. Therefore it is needed that a service declares which other services it will need to be available in order to do its work once it is deployed. Specify a DL dependency here means that if this service is deployed in a DL, also the service identified by the Service Class and Name has to be deployed in the DL. (The DescriptiveParametersValue sintax still needs to be defined)

PackagesList section

This element groups an unbounded sequence of Package elements. Each element describes a package that belongs the service. The structure of a Package element includes an initial common part and a package-specific part rooted by an element named as the service type (WSRFService, Library, Portlet, GridJob, Software, ExternalSoftware). The only constraint is that one and only one WSRFService element is accepted in the list.