Sharing Science Gateway Artefacts Through Repositories - Science Gateways for Distributed Computing Infrastructures - page 125

9.4 SCI-BUS Portlet Repository

Much like the SHIWAWorkflow Repository, the SCI-BUS portlet repository offers a
service that aims to simplify the way in which developers and researchers use dis-
tributed computing infrastructures. This repository increases the availability of
portlets, providing a service to aid their discoverability, uploading, and downloading.
Repository users : There are three main user groups for this service; portlet
developers, portlet users, and repository administrators. Portlet developers use the
repository to publish their portlet. From the interface they can describe the portlet,
assign its attributes, relate its dependencies, and release

—
different versions of their portlet. The portlet users can search, investigate, and
ultimately download and install a portlet of their choice through the repository GUI.
Finally, the repository system administrator has super-user powers over all the
information stored and the users registered. The overall design of the repository is
centered on assumptions made about each user

— and upload files for

c knowledge domain.
Again, like the SHIWA Workflow Repository, certain views are only applicable to
speci

' s speci

c user types.
Repository data : The portlet repository and the SHIWA Workflow Repository
share many of the design concepts, and the back-end infrastructures are similar.
There are three main data constructs used in the portlet repository: portlet, portlet
version (or implementation), and attributes that can be assigned to both the portlets
and their versions. The portlet can be seen as an abstract de nition of the appli-

cation is behavior. This is aided by a set of attributes to store a description and

several URLs that point to support or documentation. In addition, developers can
assign their portlet to a category or de

'

ne a set of attributes (or tags), both of which
aim at helping the users search for and discover portlets relating to their speci c

knowledge domain or need. To aid the process of selection and discoverability the
developer can also upload screenshots of their portal in use (Fig. 9.4 ). The portlet
version speci es a concrete implementation of the portlet. This has a version

number, a set of dependencies, and any files or other information that help describe
this particular version. The dependencies describe the environment that the user
must have in order to install and run the portlet. They could be a gUSE version, a
Liferay portal version, or a link to a workflow on the SHIWA Repository.
Portlet visibility : Both a portlet and its versions have a visibility status attached
to them, which can be either public or private. After creation this value is always
private assuming the portlet is under development. Next, the developers have to set
manually the visibility to public to enable it to be seen by users, effectively pub-
lishing their portlet. This can work the other way around, in order to hide a portlet
or version from public viewing.
Repository usage scenario : There are two main usage scenarios. In the rst

scenario a portlet developer wants to publish a portlet. The repository gives him/her
the ability to create a new portlet entity, specify its attributes, upload its

files, and
manage any data he/she decides to store. After creating and describing any portlets
or their versions, they can associate tags and a category to portlets and their