IBM® WebSphere® Service Registry and Repository V6 (hereafter referred to as Service Registry and Repository) is an industrial-strength tool that helps you achieve more business value from your service-oriented architecture (SOA) by enabling better management and governance of your services. You can use Service Registry and Repository to store information about services in your systems, or in other organizations' systems, that you already use, plan to use, or want to be aware of. For example, an application can check with Service Registry and Repository just before it invokes a service to locate the most appropriate service that satisfies its functional and performance needs. This capability helps make your SOA deployment more dynamic and more adaptable to changing business conditions.
Service Registry and Repository also provides extensive customization capabilities for its user interface, allowing you to modify the way in which information about your services is presented to the user. These customization capabilities range from simply modifying the properties that are displayed on an existing view of a service to deploying a whole new perspective that defines new views for the information stored in Service Registry and Repository. This new perspective may be specific to a certain kind of user within your organization, using terminology that the user can understand and restricting the information displayed to the minimum that allows the user to perform their day-to-day job.
Part 1 of this article series describes the concepts and architecture of the Service Registry and Repository Web user interface. It also describes a simple business scenario that will be used in the following articles in this series to design and develop a custom perspective that will be deployed to Service Registry and Repository.
The Service Registry and Repository Web user interface is structured in a fairly standard way familiar to most users. A frameset is used to divide the page into three areas, as shown in Figure 1.
Figure 1. Web user interface frameset
The only portion of the Web user interface that cannot be customized is the banner. However, if you deploy a custom perspective to Service Registry and Repository that the current user is permitted to view, the display name of the custom perspective will appear in the User perspective list within the banner frame. The user can then switch to the custom perspective by selecting its name from the list and clicking Go, as shown in Figure 2.
Figure 2. User perspective list
The content that is displayed within the Navigation and Workarea frames is controlled by a number of XML definition files. A set of system definition files is loaded into Service Registry and Repository as part of the installation process. These files define the Administrator and User perspectives that are available by default within Service Registry and Repository. The XML definition files for these system perspectives can be modified to tailor them to your business needs.
There are five different types of definition file used by the Service Registry and Repository user interface, as follows:
- Navigation Tree
- Collection View
- Detail View
- View Query
Certain definition files may reference objects that are defined in other definition files. For instance, a perspective definition must specify the navigation tree that will be displayed when a user is viewing that perspective as well as the collection views and detail views that should be used when viewing different types of object within the perspective. The dependencies that exist between the different types of definition file form a hierarchical structure for any given perspective, as shown in Figure 3.
Figure 3. Definition file hierarchy
The sections that follow describe the key concepts of each of the definition file types used by the Service Registry and Repository user interface.
A perspective defines the views that users will see when they are browsing the content of Service Registry and Repository in the context of that perspective. More specifically, a perspective defines:
- The user roles whose members are permitted to view the perspective.
- The navigation tree that will be displayed in the Navigation frame.
- The collection views that will be used when displaying collections of objects in the Workarea frame.
- The detail views that will be used when displaying a specific object in the Workarea frame.
A perspective is intended to provide the user with a consistent view of the data within Service Registry and Repository. For instance, a Business Analyst perspective would display a navigation tree and a number of detail views and collection views that all use consistent terminology that is meaningful to a business analyst. A Service Developer perspective, on the other hand, would display a different navigation tree, detail views, and collection views that would be likely to use more technical terminology that is meaningful to a service developer.
Service Registry and Repository defines the Administrator and the User roles. You can use these roles when creating a perspective to define the users that are permitted to view that perspective. By default, any user that is able to log into the Web user interface is able to see all perspectives that are visible to the User role. However, it is possible to define additional roles to Service Registry and Repository that match the roles performed by the users in your organization. Users or groups can then be mapped to these custom roles and the the visibility of a perspective can then be restricted to just those users or groups that are mapped to the custom role.
It is important to note that a perspective does not contain or own any of the objects that it refers to. It simply specifies the views that should be used to display data in the context of the perspective. This allows navigation trees, collection views and detail views to be shared across several perspectives at the same time. In fact, many of the system collection views and detail views are actually shared by the Administrator and User perspectives. This is shown in Figure 4.
Figure 4. Reusing view definitions
Due to the loose coupling that exists between the various definition files that make up a perspective, Service Registry and Repository does not mandate the order in which the files must be loaded. As a result, the Web user interface delays attempting to resolve any of the references between the files until they are required at runtime. This late binding allows a perspective within the Web user interface to continue to operate even if some of the view definitions that are referenced by the perspective have not been loaded into Service Registry and Repository. It is only when the user attempts to navigate to an area of the perspective with the missing view definitions that any problems will occur. At this point, a suitable error message will be displayed and a Service Registry and Repository administrator will need to take suitable action to resolve the problem.
We have explained that users browse the information within Service Registry and Repository in the context of a perspective. The view definition mappings for the users current perspective are searched when attempting to resolve the collection or detail view definition that should be used to display a certain type of object. By default, the Service Registry and Repository Web user interface will simply use the name of the underlying SDO object type in order to select a suitable view definition to use to display the data. For instance, if you are attempting to view the details of a WSDL document object, the Web user interface will attempt to find a view definition within your current perspective that is mapped to "WSDLDocument".
However, it is possible to control how a perspective selects the view definition to use when displaying an object. This is achieved using display types in the other types of definition files within the user interface. If a display type is specified, this display type is passed to the perspective and used when attempting to resolve the view definition mapping instead of the name of the underlying SDO type. In effect, when you use display types within view query, collection view or detail view definitions you are stating that you want the information displayed using a specific view definition.
The navigation tree is key to the definition of any perspective. It is the starting point for browsing the information stored within the Service Registry and Repository. A well designed navigation tree can help to ensure that a user can find the information that they are looking for quickly and without the need to browse through several other panels of information.
Within Service Registry and Repository, the definition of the navigation tree is actually split into two different configuration file types:
- The visible portion of the navigation tree is defined within a navigation tree definition file. This defines the physical structure of the navigation tree and the text that is displayed for each node of the tree. It also defines whether a node will be rendered as a link and what action should be performed when the link is selected.
- The query that will be executed when a node in the navigation tree is selected is defined within a view query definition file. A view query definition file can define multiple view queries, each with an ID. It is possible to override the behavior of an existing system view query by defining a new view query with the same ID. However, since view queries are shared across all of the perspectives defined within Service Registry and Repository, overriding a system view query may modify the behavior of another perspective. For this reason, overriding an existing view query should only be done with caution. View queries can vary in complexity, from simply returning all objects of a specific type to returning all of the objects that satisfy certain search criteria. A view query can also specify the collection view that should be used to display the results of the query.
Figure 5 below shows how the navigation tree definition file links the nodes within the navigation tree to the corresponding view queries that will be executed when the node is selected.
Figure 5. Defining a navigation tree
As its name suggests, a collection view is used to display information about a collection of objects in Service Registry and Repository. A collection view definition describes the properties of the underlying object that are to be displayed in columns within the view and also which action buttons should be displayed. A collection view definition file can only contain a single collection view definition.
A collection view must also specify which columns within the view will be displayed as HTML links. Selecting one of these links will navigate the user to the detail view for the object on the corresponding row in the collection view. A collection view can control the detail view definition that is used to display the details of the selected object by specifying a display type. Recall that, if a display type is specified the Web user interface will attempt to resolve it to a detail view definition using the mappings defined within the current perspective. If a display type is not specified, the Web user interface uses the SDO type name of the object in the selected row to find the detail view definition to use.
Figure 6 shows the areas of a collection view that are controlled by a collection view definition.
Figure 6. Collection views
As its name suggests, a detail view is used to display the details of a specific object in Service Registry and Repository. A detail view definition describes the properties of the underlying object that are to be displayed in the detail view and where within the detail view they will be displayed. A detail view definition file can only contain a single detail view definition. However, detail views do support the concept of tabs. Tabs allow different views to be defined onto the same underlying data. However, currently the only type of tab that supports customization is the Details tab. The area of a detail view defined with a tab definition is shown in Figure 7.
Figure 7. Detail view tabs
The way in which a property is displayed on the details tab within a detail view depends on the type of the property itself and where in the detail view it is displayed. The details tab is divided into a General Properties section and multiple Additional Properties sections, as shown in Figure 8.
Figure 8. General and additional properties
Properties that are displayed within the General Properties section of the details view must be of type string. The value of the property is displayed within a text entry field. Properties that are displayed in an Additional Properties section of the details view must represent a reference to another object or objects in Service Registry and Repository. Properties displayed in the Additional Properties section of a details view are displayed as HTML links. Selecting one of these links navigates the user to a detail or collection view for the corresponding property on the object in question. A detail view can control the view definition that is used to display the resulting page by specifying a display type. Recall that, if a display type is specified the Web user interface will attempt to resolve it to a view definition using the mappings defined within the current perspective.
In order to provide some context for the following articles in this series, we describe a scenario on which we will base the artefacts that are produced in this series.
Our sample company, WSRR Traders Inc. provides a number of services to their customers in the area of trading stocks and shares. One of the most popular services that it provides is the Stock Quote service. As its name suggests, the Stock Quote service returns a quote for the value of a specified stock based on its ticker symbol.
Customers of WSRR Traders Inc. can pay for one of three different levels of service and the accuracy, response time and availability guarantees made by WSSR Traders Inc. for the stock quote service varies based on the level of service that a customer has paid for. The levels of service are as follows:
WSRR Traders Inc. have registered all of the services that are deployed in their production environment with their production instance of Service Registry and Repository. Metadata have been added to these services within Service Registry and Repository in order to identify the level of service expected and the contact details of the business owner. This metadata is described in Table 1.
Table 1. Static Metadata
|Metadata Property Name||Description|
|serviceLevel||Specifies the level of service that the service is expected to provide (Gold, Silver, Bronze).|
|contactEMail||The person who should be contacted with regard to the service.|
WSRR Traders Inc. also have an application that is deployed in their production environment that monitors the deployed services to ensure that they are delivering the qualities of service that their customers have paid for. This application has been modified to dynamically update the metadata of the services registered in Service Registry and Repository in order to provide operational information about each service. The metadata that the monitor application adds to the services within Service Registry and Repository is described in Table 2.
Table 2. Operational Metadata
|Metadata Property Name||Description|
|availabilityPercent||Indicates the overall availability of the service.|
|slaCount||Specifies the number of Service Level Agreements (SLAs) that are currently active for the service, that is, the number of SLAs that the service is currently expected to meet.|
|slaViolations||The number of times that the service has violated one of its SLAs.|
WSRR Traders Inc. would now like to customize the Service Registry and Repository Web user interface in order to be able to view and use the metadata described above. The rest of this series describes how to produce the various user interface definition files that are required to define a custom perspective that meets their needs.
The various definition files that you will create as you work through the following articles in this series are simply XML files that conform to the relevant XML schema defined by Service Registry and Repository. As such, any number of tools can be used to create and edit the definition files. However, we recommend that you use a tool that performs XML validation to ensure that the definition files produced are correct.
The tool that will be used throughout the following parts in this series is IBM Rational Software Architect. However, other IBM Rational Software Development Platform products, such as IBM Rational Application Developer and IBM Rational Web Developer, provide the same functionality.
The following steps must be performed in order to configure IBM Rational Software Architect so that it is ready to start authoring the definition files:
- Create a workspace or use an existing one
- Enable XML capabilities for the workspace
- Switch to the resource perspective
- Create a new project
- Import the Service Registry and Repository user interface XML schemas
- Create the properties file for the custom perspective
- Launch IBM Rational Software Architect.
- The Workspace Launcher dialog is displayed.
- If you wish to use an existing workspace, you can specify its location at this point. If you wish to use a new workspace, enter a suitable location.
- Click OK.
- If you created a new workspace, Rational Software Architect will open displaying a Welcome view that contains shortcuts to various resources for first time users. This view is not required and can be closed.
The IBM Rational Software Development Platform provides multipurpose integrated development environments (IDE's) that have a wide range of capabilities for different user roles. As a result, it is possible to disable capabilities that are not relevant to your type of usage. By default, the XML Developer capability is not enabled within a new Rational Software Architect perspective. Perform the following steps to enable this capability.
- Select Window > Preferences from the menu bar.
- The Preferences dialog is displayed.
- Expand Workbench and select Capabilities.
At the bottom of the list of capabilities on the right-hand side of the dialog, select the check box for the XML Developer capability, as shown in Figure 9.
Figure 9. Preferences dialog
- Click OK.
The majority of the files that you will be working with in the following articles in the series are XML files. The most suitable perspective in which to edit these files is the Resource perspective. Perform the following steps to open this perspective within your workspace.
- Select Window > Open Perspective > Other from the menu bar.
- The Select Perspective dialog is displayed.
- Select Resource from the list of perspectives.
- Click OK.
- The Resource perspective will open with your workspace.
The files that you create must exist within a project in Rational Software Architect. The most suitable project type is a Simple project. Perform the following steps to create a simple project within your workspace.
- Select File > New > Project from the menu bar.
- The New Project dialog is displayed.
- Expand Simple and select Project as shown in Figure 10.
Figure 10. New project dialog
- Click Next.
- Enter a suitable name for the project in the Project name entry field as shown in
Figure 11. Specifying the project name
- Click Finish.
- The new project is created and will appear within the Navigator view in your workspace.
The XML files that you create for your custom perspective must conform to the relevant XML schema. The XML schemas for the various Web user interface definition files are provided within the install image for Service Registry and Repository. Perform the following steps to import these XML schemas into your new project.
- Right-click on your new project and select Import from the context menu.
- The Import dialog is displayed.
- Select File System from the list of import sources as shown in Figure 12.
Figure 12. Selecting the import source
- Click Next.
- On the following panel, click Browse.
- The Import from directory dialog is displayed.
- Navigate to the Service Registry and Repository installation directory and select the admin folder.
- Click OK.
Within the Import dialog, expand the admin folder in the left hand tree view and check the check box for the schemas folder as shown in Figure 13.
Figure 13. Completing the import
- Click Finish.
- The schemas folder and all of the files that it contains is imported into your project. Not all of the XML schemas that are imported are actually required when creating the definition files for the Web user interface. However, it does not matter if they are present in the schemas directory.
The navigation tree and views that you will define in the following articles in this series all contain a number of text strings that are specific to the customized perspective that is being defined. These strings are used in a number of places, such as providing the label for a node on the navigation tree. The Service Registry and Repository Web user interface requires that you provide these string resources using a properties file that is made available on the classpath at runtime. Using a properties file allows you to support multiple languages within your custom perspective at runtime by providing translated versions of the file with a suitable locale specific name. Perform the following steps to create the properties file in the correct location within your project.
- Right-click on your new project and select New > Folder from the context menu.
- The New Folder dialog is displayed.
Enter com as the name for the new folder in the Folder name entry field as shown in
Figure 14. Specifying a folder name
- Click Finish.
Repeat this process to create a directory structure of com/ibm/sr as shown in
Figure 15. Complete folder structure
- Right-click on the sr folder and select New > File from the context menu.
- The New File dialog is displayed.
Enter MonitorPerspective.properties as the name for the new file in the File name
entry field as shown in Figure 16.
Figure 16. Specifying a file name
- Click Finish.
- The MonitorPerspective.properties file is created within the sr folder and it is opened within an editor in your workspace.
In this article you have learned about the various configuration files that are used to define how content is displayed within the Service Registry and Repository user interface. You also learned about how the different types of configuration files reference information that may be defined in other configuration files.
Future articles in this series explain, in more detail, how you can create your own configuration files to customize the Service Registry and Repository user interface to suit your needs. They use the scenario that we have described within this article to provide the context for the artifacts that they generate.
|WSRR downloads for the article series1||WSRR_UI_Downloads.zip||15KB||HTTP|
- Contains WSRR downloads for the four-part article series.
WebSphere Service Registry and Repository Version 6.0 Information Center
Introducing IBM WebSphere Service Registry and Repository, Part 1: A day in the life of WebSphere
Service Registry and Repository in the SOA life cycle
Introducing IBM WebSphere Service Registry and Repository, Part 2: Architecture, APIs, and content
developerWorks WebSphere Business Integration zone
For developers, access to WebSphere Business Integration how-to articles, downloads, tutorials, education, product info, and more.
WebSphere Business Integration products page
For both business and technical users, a handy overview of all WebSphere Business Integration products
Product-specific forums where you can get answers to your technical questions and share your expertise with other WebSphere users.
Most popular WebSphere trial downloads
No-charge trial downloads for key WebSphere products.
Trial downloads for IBM software products
No-charge trial downloads for selected IBM® DB2®, Lotus®, Rational®, Tivoli®, and WebSphere® products.
Safari Bookshelf: e-library designed for developers
Complete search and download access to thousands of technical books for a one-time subscription fee. Free trial for new subscribers.
developerWorks technical events and Webcasts
Free technical sessions by IBM experts that can accelerate your learning curve and help you succeed in your most difficult software projects. Sessions range from one-hour Webcasts to half-day and full-day live sessions in cities worldwide.
Ongoing, free-form columns by software experts, to which you can add your comments.
Rob Breeds is an Advisory Software Engineer at IBM Hursley Laboratories, UK, in the WebSphere Service Registry and Repository development team. He was previously lead developer for user interfaces and tooling in WebSphere UDDI Registry in WebSphere Application Server 6.0 and 5.0, and earlier in his IBM career co-authored the book "Designing and Programming CICS Applications". Acquiring a BSc. in Chemistry at the University of Bath and training to be a school teacher didn't stop Rob building 20 years of IT experience working in software development, technical sales, marketing, and publishing roles. Prior to joining IBM, Rob was a TPF mainframe developer at Galileo International.
Kevin Marsh is a Software Engineer at IBM Hursley Laboratories, UK, currently in the service team for WebSphere Service Registry and Repository, having previously worked in the user interface development team. Before this, Kevin helped develop WebSphere UDDI Registry for WebSphere Application Server (versions 6.0 and 5.1) gaining valuable experience of J2EE. Kevin began his career with IBM in 2001 after graduating from the University of Kent at Canterbury with a BSc. in Computer Science.
Dave Seager is a Software Engineer working on WebSphere Service Registry and Repository at IBM's lab in Hursley, England. He has nine years of experience working in software development and customer support roles within IBM. He is a co-author of "CICS Transaction Gateway V5 The WebSphere Connector for CICS" and is the author of several articles on developerWorks WebSphere. He holds a degree in Software Engineering from Oxford University.
Martin Smithson is a Senior IT Specialist working on WebSphere Service Registry and Repository at IBM's lab in Hursley, England. He has ten years of experience working in the IT Industry, five of which he spent working as a technical consultant for the EMEA IBM Software Services for WebSphere team. His areas of expertise include the architecure, design, and development of J2EE applications; he is also an expert on IBM WebSphere Application Server. He is the author of " Securing connections between WebSphere Application Server and WebSphere MQ, Part 2 " and is a co-author of " WebSphere Application Server V6: System Management & Configuration Handbook" and CCF Connectors and Database Connections Using WebSphere Advanced Edition". Martin also developed the IBM Client Application Tool for JMS that is available for download from IBM's alphaWorks Web site.
Philip Taunton is a Staff Software Engineer at IBM Hursley Laboratories, UK, in the WebSphere Service Registry and Repository development team. He was previously in the Pervasive Computing division and is an expert in computer telephony and real-time voice products on Java, Unix and Windows. He has also specialized in user interface programming and design. He holds a degree in Electrical and Electronic Engineering from Bath University. Philip has 14 years of experience in software development and has also worked in customer support roles.