Developing a standalone EJB Java client application with WebSphere Service Registry and Repository

This article shows you how to develop a standalone EJB Java client application to invoke a WebSphere Service Registry and Repository runtime that has metadata artifacts populated into it, using predefined persisted queries and a Java API.

Bhargav Perepa , WebSphere Architect and IT Specialist, IBM China

Bhargav PerepaBhargav Perepa is a WebSphere Brand Architect and IT Specialist at IBM Federal Software Group in Washington D.C. He has been a WebSphere developer in the IBM Austin WebSphere Development Lab, and before that had Smalltalk and C++ development experience in IBM Chicago. Bhargav holds a Masters degree in Computer Sciences from the Illinois Institute of Technology in Chicago and an MBA degree from the University of Texas in Austin.



11 April 2012

Introduction

This article shows you how to design, develop, test, and implement a client application that invokes an IBM® WebSphere® Service Registry and Repository V7.5.0.2 (hereafter called WSRR) runtime. The runtime has SOA metadata artifacts populated into it using predefined and persisted queries that are provided by WSRR. The article shows you how to create relationships between the various artifacts as you populate them into WSRR, so that you can test the client application. You can design and develop the client application using either an Eclipse workbench or IBM Integration Designer, and similarly, you can run and test the client application using either a Windows® command window or IBM Integration Designer.

The WSRR Java API lets you design and develop client applications to interact with the WSRR runtime from the client side using local or remote EJB interfaces, or to design and develop delegate applications to interact with WSRR runtime from the server side using local EJB interfaces in plug-ins. The WSRR Java API facilitates WSRR content encapsulation and Create, Retrieve/Query, Update, and Delete (CRUD) operations on WSRR content. WSRR stores its content in the form of Service Data Objects (SDOs), and the Java API uses the SDO Version 2 specification. WSRR allows two types of client applications to interact with it, using the same interfaces: an EJB client and a web services client. However, only an EJB client application can exploit additional method signatures that require passing in list type parameters to update and delete WSRR content.

Use case

The purpose of the standalone EJB Java client application described in this article is to exercise each method of the WSRR predefined persisted queries using the Java API in a secure environment. When taken together, the application described in this article, the application in the referenced developerWorks article, and the example code in the WSRR information center topic User-defined persisted queries provide everything you need to develop client and delegate-side EJB Java applications. Prior to invoking each of WSRR predefined persisted queries, you need to populate the WSRR with SOA artifacts.

The rest of this article consists of the following sections:

  • Populating SOA artifacts into WSRR
  • Developing the client application
  • Executing the client application

Populating SOA artifacts into WSRR

First, define a named property query that retrieves content of any type from WSRR and saves it under the All Entities name, as shown in Figures 1 and 2:

Figure 1. All Entities named property query
All Entities named property query
Figure 2. All Entities named property query details
All Entities named property query details

Run the query to confirm that WSRR has no content at the beginning:

Figure 3. All Entities named property query execution results
All Entities named property query execution results

Populate WSRR with a set of related SOA artifacts consisting of XSD and WSDL documents packaged into a zip archive file document. The AddressDetailsProvider.zip archive contains a related set of XSD documents and WSDL documents capturing interface and implementation details. The abstract Address XML schema definition (XSD) is shown in Figure 4:

Figure 4. abstract Address XSD
Abstract Address XSD

One concrete HomeAddress XSD is derived from the abstract Address XSD:

Figure 5. Concrete HomeAddress XSD
Concrete HomeAddress XSD

Click to see larger image

Figure 5. Concrete HomeAddress XSD

Concrete HomeAddress XSD

One concrete WorkAddress XSD is derived from the abstract Address XSD:

Figure 6. Concrete WorkAddress XSD
Concrete WorkAddress XSD

Click to see larger image

Figure 6. Concrete WorkAddress XSD

Concrete WorkAddress XSD

One concrete Person XSD document can have a related HomeAddress and/or WorkAddress XSD specified:

Figure 7. Person XSD
Person XSD

Figure 8 shows the interface WSDL definition for the AddressDetails service:

Figure 8. AddressDetails.wsdl – interface WSDL
AddressDetails.wsdl – interface WSDL

Figure 9 shows the implementation WSDL definition for the AddressDetails service:

Figure 9. AddressDetailsProvider.wsdl – implementation WSDL
AddressDetailsProvider.wsdl – implementation WSDL

Load AddressDetailsProvider.zip archive file document into WSRR with the following metadata specified, as shown in Figures 10, 11, and 12:

  • WSDL Document (AddressDetailsProvider.zip)
  • http://WSRREJBQueryClient
  • Address Details Provider Service Documents
  • 1.0
Figure 10. AddressDetailsProvider.zip document loading
AddressDetailsProvider.zip document loading
Figure 11. AddressDetailsProvider.zip document loading confirmation
AddressDetailsProvider.zip document loading confirmation
Figure 12. AddressDetailsProvider.zip document loading success
AddressDetailsProvider.zip document loading success

Load wssecurity-policy document into WSRR with the following metadata specified, as shown in Figures 13, 14, and 15:

  • wssecurity-policy.xml
  • Policy
  • WS-Security Policy Document
  • 1.0
Figure 13. wssecurity-policy document loading
wssecurity-policy document loading
Figure 14. wssecurity-policy document loading confirmation
wssecurity-policy document loading confirmation
Figure 15. wssecurity-policy document loading success
wssecurity-policy document loading success

Load Note.xml into WSRR with the following metadata specified, as shown in Figures 16, 17, and 18:

  • Note.xml
  • XML
  • http://WSRREJBQueryClient
  • Note XML Document
  • 1.0
Figure 16. note.xml document loading
note.xml document loading
Figure 17. note.xml document loading confirmation
note.xml document loading confirmation
Figure 18. note.xml document loading success
note.xml document loading success

You are now ready to load RelChild.txt into WSRR with the following metadata specified, as shown in Figures 19, 20, and 21:

  • RelChild.txt
  • Other
  • http://WSRREJBQueryClient
  • Relationship Child Document
  • 1.0
Figure 19. RelChild.txt document loading
RelChild.txt document loading
Figure 20. RelChild.txt document loading confirmation
RelChild.txt document loading confirmation
Figure 21. RelChild.txt document loading success
RelChild.txt document loading success

Load RelParent.txt other document into WSRR with the following metadata specified, as shown in Figures 22, 23, and 24:

  • RelParent.txt
  • Other
  • http://WSRREJBQueryClient
  • Relationship Parent Document
  • 1.0
Figure 22. RelParent.txt document loading
RelParent.txt document loading
Figure 23. RelParent.txt document loading confirmation
RelParent.txt document loading confirmation
Figure 24. RelParent.txt document loading success
RelParent.txt document loading success

Perform four security policy attachments to AddressDetails.wsdl – for security encoding and signing of request and response flows, as shown in Figures 25, 26, and 27:

Figure 25. Policy Attachment
Policy Attachment
Figure 26. Policy Attachment confirmation
Policy Attachment confirmation
Figure 27. Policy Attachment success
Policy Attachment success

Next, define two custom relationships to AddressDetails.wsdl, as shown in Figure 28:

  • Custom-Relationship-Parent -- RelParent.txt
  • Custom-Relationship-Child -- RelChild.txt
Figure 28. Definition of custom relationships
Definition of custom relationships

Define a test environment for SOAP Service Endpoint, as shown in Figures 29 and 30:

Figure 29. Definition of SOAP service endpoint environment
Definition of SOAP service endpoint environment
Figure 30. Definition of SOAP service endpoint environment confirmation
Definition of SOAP service endpoint environment confirmation

Developing the client application

Table 1 shows the WSRR-populated SOA artifacts with the respective document bsrURIs. You need this information to develop the client application. When you download and run the client application sample, adjust the client application logic to reflect the bsrURIs generated in your instance of WSRR:

Table 1. WSRR populated SOA artifact details
Artifact NameArtifact TypebsrURI
AddressDetails.wsdlWSDLDocument98a21f98-d43b-4b3b.b9d9.a373a8a3d986
AddressDetailsProvider.wsdlWSDLDocument83e8c983-dea4-44d3.8019.324d213219c9
Person.xsdXSDDocument19fdff19-834d-4deb.9f67.ca6b62ca6735
Address.xsdXSDDocument254fed25-2138-4855.8f5b.c4d449c45b4d
wssecurity-policy.xmlPolicyDocument30b22b30-64cd-4dba.9e20.c4675ec42068
note.xmlXMLDocument1bda171b-f1ba-4ad6.82eb.2f9ce32feb01
AddressDetailsProvider_AddressDetailsHttpServiceWSDLService76c51976-51a9-4974.b4f3.f79ad7f7f32a
AddressDetailsProvider_AddressDetailsHttpPortWSDLPorteb7a08eb-ccf7-47f2.8275.12020a12751f
AddressDetailsWSDLPortType98c36498-66d3-4324.a9e1.a3cb9ca3e18b
http://localhost:9082/WSRREJBQueryProvider/SOAPServiceEndpoint8441f684-a391-41d0.8951.2d6a7f2d519b
AddressDetailsProvider_AddressDetailsHttpService
RelChild.txtOtherDocuments7eab137e-964a-4a90.8a8f.f02b23f08ff4
RelParent.txtOtherDocumentse438cbe4-109c-4c4a.8d3f.1be2771b3fcd

Developing the client application requires adding the indicated JAR files to the client-side classpath to resolve the imported packages at build time and to run the client at run time. The required JAR files are sdo-int.jar, ServiceRegistryClient.jar, and com.ibm.ws.webservices.thinclient_7.0.0.jar, as shown in Figures 30 and 32. The client application features private static string variables to hold information about userid, password, initial bootstrap host/port, and location of security context setup files.

The client application class constructor method has two method calls to register governance and ontology SDO factory package instances. You need to register the three separate packages listed below prior to using SDO objects in the client application. One of the method calls implicitly registers the third package.

  • com.ibm.serviceregistry.sdo.SdoFactory
  • com.ibm.serviceregistry.governance.sdo.SdoFactory
  • com.ibm.serviceregistry.ontology.sdo.SdoFactory

The client application program consists of one main static method, and two public methods named getMySRSession(.,.) and exerciseAPIs(.).

The getMySRSession(.,.) method defines four system properties, which are briefly explained below. For more details, see Resources at the bottom of the article.

Context.PROVIDER_URL
Specifies the namespace of bootstrap server for the initial context factory to construct initial context object. In this scenario, our bootstrap server happens to be running on localhost at Port 2811.
com.ibm.SSL.ConfigURL
Specifies a file URL that points to the ssl.client.props file. Client application configuration of Secure Sockets Layer (SSL) requires access to this file as this file contains SSL configuration property definitions.
java.security.auth.login.config
Java client application programs using JAAS for authentication need to invoke with the JAAS configuration file specified and this can be achieved by specifying system property. The specified system property is used to pass the appropriate JAAS configuration file to the Java virtual machine.
com.ibm.CORBA.ConfigURL
In order for a standalone client application to access a secure enterprise bean application running on a remote server, this system property is required to be configured for message layer authentication of client with a Secure Sockets Layer (SSL) transport. This system property points to WebSphere Application Server's sas.client.props file.

The logic subsequently creates a login context using WSLogin login configuration with a callback handler that makes use of userid and password details passed in. A login is performed using this context object and an authenticated subject is obtained, assuming a successful authentication/authorization. This authenticated subject is then used to set the invocation context for the rest of thread to execution under. The logic sets up an EJB home reference pointing to the real JNDI name of
ejb/com/ibm/serviceregistry/7_5/ServiceRegistrySessionHome.

The Narrow method is used to get a reference to the implementation of the ServiceRegistrySessionHome object that corresponds to the passed-in remote stub object type of ejbHome. The ServiceRegistrySession reference is created by calling the create() method on the ServiceRegistrySessionHome object. Catch block logic detects the type of exception caught and prints the stack trace.

If successful, the getMySRSession(.,.) method returns a ServiceRegistrySession object to the caller.

The exerciseAPIs(.) method takes in a ServiceRegistrySession object parameter and systematically exercises each of WSRR's predefined, persisted query methods in turn.

Query methods can be categorized into:

  • Methods that deal with the Document Programming Model (WSDLDocument, XSDDocument, PolicyDocument, and XMLDocument)
  • Logical Object Programming Model (WSDL Programming Model, XSD Programming Model, and Policy Programming Model)
  • Base Objects (GenericObject, DataObject, BaseObject, LogicalObject, and QueryObject)
  • User-defined Metadata (Properties and Relationships)

You can also view query methods as follows:

  • Methods that require no parameters to pass in
  • Methods that require a String[] to be passed in with a value of metadata type
  • Methods that require a String[] to be passed in with a quoted metadata type and quoted value of metadata type separated by a comma
  • Methods that require list of quoted value of metadata type separated by a comma, followed by list of corresponding quoted metadata type separated by a comma

The sample code is set up to pass in possible and permitted combinations of parameters (alternate combinations in comments) when API method calls permit. The console output can be easily matched with the calls exercised for easy cross referencing, as shown in Figure 30 above.

By executing a saved All Entities WSRR query, you can compare and cross-reference console output with WSRR Web UI Filters categorization output, to confirm the client application results (as shown above in Figures 1, 2, 33, 34, and 35).

Executing the client application

You can execute the client application in IBM Integration Designer or in a Windows command window, as shown in Figures 31 and 37. To execute the client application in IBM Integration Designer, from the Java EE perspective, Select Run => Run configurations => Java application => WSRREJBQueryClient:

Figure 31. WSRREJBQueryClient development – IBM Integration Designer tool in Java EE Perspective
WSRREJBQueryClient development – IBM Integration Designer tool in Java EE Perspective
Figure 32. WSRREJBQueryClient development – Run Configurations – Main Tab
WSRREJBQueryClient development – Run Configurations – Main Tab

Figures 33 and 34 show the run configuration's Main and Classpath tabs, with appropriate configuration details specified:

Figure 33. WSRREJBQueryClient development – Run Configurations – Classpath Tab
WSRREJBQueryClient development – Run Configurations – Classpath Tab

Select Console view to confirm successful execution of the client application, as shown in Figure 34:

Figure 34. WSRREJBQueryClient development – Console View
WSRREJBQueryClient development – Console View

Click to see larger image

Figure 34. WSRREJBQueryClient development – Console View

WSRREJBQueryClient development – Console View

Output in Figures 34, 35, and 36 should match, indicating that client application has exercised the API correctly.

Figure 35. WSRREJBQueryClient development – Filtered Console Output
WSRREJBQueryClient development – Filtered Console Output
Figure 36. WSRREJBQueryClient development – Filtered Web UI View
WSRREJBQueryClient development – Filtered Web UI View

Click to see larger image

Figure 36. WSRREJBQueryClient development – Filtered Web UI View

WSRREJBQueryClient development – Filtered Web UI View

To execute the client application in a Windows command window, change directory to the appropriate location in the file system and execute the command script WSRREJBQueryClient.cmd, as shown in Figure 37. Verify the output generated by reviewing the redirected output file.

Figure 37. WSRREJBQueryClient development – program execution from command window
WSRREJBQueryClient development – program execution from command window

Conclusion

This article showed you how to develop, test, and execute a standalone EJB Java client application using IBM Integration Designer to invoke the WSRR V7.5.0.2 predefined persisted queries using the Java API. In addition, the article showed you how to populate WSRR with the required SOA artifacts for the client application to execute against, and how to execute the client application from a Windows command window.

Acknowledgements

The author gratefully acknowledges the help he received from Anna Maciejkowicz, a Support Specialist on the IBM WSRR Level-3 Support Team in Hursley, UK, and from Kailash Peri, a Client Technical Resolution Specialist on the WebSphere Message Broker and WSRR Level-3 Support Team in Research Triangle Park, NC, USA.


Download

DescriptionNameSize
Code sampleArticleExample.zip13 KB

Resources

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into WebSphere on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=WebSphere
ArticleID=809858
ArticleTitle=Developing a standalone EJB Java client application with WebSphere Service Registry and Repository
publish-date=04112012