Introduction

WebSphere Process Server (hereafter called Process Server) and WebSphere Adapter (hereafter called Adapter) are two key products for building service-oriented architecture (SOA) business integration solutions. They can help you integrate and optimize the existing applications and business processes more effectively.

Back to top

WebSphere Process Server

WebSphere Process Server is the next-generation business process server that supports all style of integration based on SOA and open standards. It deploys and executes processes that orchestrate services (people, information, systems, and trading partners) within your service-oriented architecture (SOA). Process Server is frequently used as the underpinning of the business integration solutions. Figure 1 shows an overview of WebSphere Process Server.

Back to top

WebSphere Adapter

WebSphere Adapters implement the Java™ Connector Architecture (JCA) and Enterprise MetaData Discovery specifications to provide a simple and quick integration experience with graphical discovery tools without resorting to writing code. It delivers generic technology and business application adapters with wizards that quickly and easily service enable legacy applications, ERP, HR, CRM, and supply chain systems.

WebSphere Adapters build up the communication bridge between the enterprise applications (like SAP, Siebel®, Oracle® e-Business Suite, and so on) and WebSphere platform, as shown in Figure 2. It also enables the WebSphere platform to access external data sources through various technologies, such as JDBC, E-mail, and FTP.

Figure 3 shows the architecture of a typical business integration solution by using Process Server and Adapter.

Back to top

Java Management Extensions

Java Management Extensions (JMX) technology provides a framework for managing and monitoring distributed, Web-based, modular solutions. You can access and manage the various resources (such as applications, devices, or services) by using the Java objects called managed beans (MBeans).

The JMX architecture is structured into three layers:

• Instrumentation layer: Dictates how resources can be wrapped within special Java beans, called MBeans. MBeans expose their management interface through a JMX agent for remote management and monitoring.
• Agent layer: Consists of the MBean server and agents, which provide a management infrastructure. The services that are implemented include:
  • Monitoring
  • Event notification
  • Timers
• Management layer: Defines how external management applications can interact with the underlying layers in terms of protocols, APIs, and so on.

Figure 4 shows the three-level architecture of JMX.

Back to top

Wsadmin scripting tool

The WebSphere administrative scripting tool (wsadmin) for WebSphere Application Server provides a useful interface to manage the WebSphere configuration and the resources running in the server. It supports a non-graphical alternative way to communicate with the MBeans that run in WebSphere Application Server. Figure 5 illustrates the mechanism of the tool in WebSphere Application Server.

The wsadmin tool supports two scripting languages: Jacl and Jython. There are five objects available for the wsadmin scripting tool:

• AdminControl: Runs operational commands.
• AdminConfig: Runs configurational commands to create or modify WebSphere Application Server configurational elements.
• AdminApp: Administers applications.
• AdminTask: Runs administrative commands.
• Help: Obtains general help.

The wsadmin scripting tool uses the above objects to communicate with the MBeans that run in WebSphere Application Server processes.

Back to top

Managing WebSphere Adapter agilely through wsadmin scripting

In general, you can manage the WebSphere Adapter from the administrative console of WebSphere Process Server. For example, install or uninstall the Adapter RAR, create the Connection Factory or Activation Spec for the specified Adapter, and so on. Figure 6 shows the wizard for installing the Adapter RAR in the administrative console of WebSphere Process Server.

The above approach works well for most cases, but sometimes it is not efficient. For example, during the testing phase, you need to install and uninstall the Adapter frequently. It is better if you implement this task with wsadmin scripting, and then save the script commands into one batch file. Thus, whenever you need to install or uninstall the Adapter, you just execute the wsadmin scripts with the batch file. Using wsadmin scripting frees you from routine tasks and improves the overall performance.

The following sections will use some samples to demonstrate how to manage the Adapter agilely through wsadmin scripting. Similarly, you can use wsadmin scripting to access and manage other resources that run in Process Server and implement any tasks you want.

You can download the wsadmin scripts for the samples that are described in this article.

Sample 1: Install and uninstall Resource Adapter

In this sample, we will introduce how to install the Adapter to Process Server and how to uninstall the Adapter from the Process Server by using wsadmin scripting.

To install the Adapter, use the “getid” command of “AdminConfig” to verify if the Adapter has been installed to the server or not. If not, invoke the “installResourceAdapter” command of AdminConfig to install the Adapter to the target server or node from the specified location. Otherwise, ignore it. In the end, you will invoke the “save” command of AdminConfig to save the changes. Refer to the following scripts in Listing 1 for details.

#--------------------------------------------------------------
#  raname – the name of Resource Adapter
#  filePath – the location of Resource Adapter RAR file.
#  nodeName – node name
#--------------------------------------------------------------

set raname "IBM WebSphere Adapter for JDBC" 
set filePath "e:/CWYBC_JDBC.rar"
set nodeName "nlNode01"
set ra [$AdminConfig getid /Node:$nodeName/J2CResourceAdapter:
 $raname/]

if {[llength $ra] > 0} {
     # Already installed on node (do nothing and continue)
     puts "$raname has already existed on $nodeName."
} else {
     # Prepare to install on node
     set options [list -rar.name $raname ]
     set raFilePath $filePath
     
     # MSG_INSTALLING_RESOURCE_ADAPTER
     puts "installing the Resource Adapter '$raname' ..."
     
     # Attempt to install resource adapter          
     if {[catch {set ra [$AdminConfig installResourceAdapter 
$raFilePath $nodeName $options]} result ]} {
         # Report error and exit
         puts "failed to install Resource Adapter due to $result"
         exit
     }
     # MSG_INSTALLING_RESOURCE_ADAPTER
     puts "installed Resource Adapter '$raname' successfully."
     
     # Save the changes.
     $AdminConfig save
}

To execute the above scripts, you can save it to one batch file named install_ra.jacl, and then execute it with the wsadmin tool. You need to modify the rename, filename, and nodeName variables according to their actual environment settings.

<WPS_HOME>\bin\wsadmin –f e:/install_ra.jacl –username admin –password admin

If the above command in Listing 2 is executed successfully, the following messages will be printed to the command console, as shown in Figure 7.

To uninstall the Adapter, the tasks are similar to installing the Adapter. You can implement it by utilizing the “uninstallResourceAdapter” command of AdminConfig, as shown in Listing 3.

#--------------------------------------------------------------
#  raname – the name of Resource Adapter
#  nodeName – node name
#--------------------------------------------------------------

set raname "IBM WebSphere Adapter for JDBC"
set nodeName "nlNode01"
set ra [$AdminConfig getid /Node:$nodeName/J2CResourceAdapter:
 $raname/]

if {[llength $ra] > 0} {
      # Already installed on node 
puts "$raname has already existed on $nodeName."
set options [list -force ]
if {[catch {$AdminConfig uninstallResourceAdapter $ra $options} 
 result ]} {
         # Report error and exit
         puts "failed to uninstall Resource Adapter due to $result"
         exit
      }
puts "$raname Resource Adapter has been uninstalled successfully."
      # Save the changes.
      $AdminConfig save

} else {
   puts "Error: ${raname} does not exist on ${nodeName}."
   exit
}

Sample 2: Create Connection Factory and Activation Spec

In this sample, we will introduce how to create connection factory and activation spec for the specified Adapter by using wsadmin scripting.

The connection factory of WebSphere Adapter stores the related properties for establishing the connections to the target Enterprise Information System (EIS), and it is required for the Adapter outbound processing. Meanwhile, the activation spec of WebSphere Adapter stores the related properties for fetching event data from the target EIS, and it is required for the Adapter inbound processing.

WebSphere Adapters support two work modes: embedded and standalone. For the embedded work mode, the connection factory and activation spec will be created automatically when the Adapter application is deployed to the server. For the standalone work mode, you need to create the connection factory and activation spec manually after the Adapter is installed to the target server.

To create the connection factory for the specified Adapter, get the Adapter ID by invoking the "getid" command of AdminConfig, and then invoke the "createJ2CConnectionFactory" command of AdminTask to create one connection factory instance, as shown in Listing 4.

#--------------------------------------------------------------
#  rename – the name of Resource Adapter
#  nodeName – the node name
#  cfName – the name of the Connection Factory
#  cfJndiName – the JNDI name of the Connection Factory
#  cfInterface – the name of the Connection Factory class
#--------------------------------------------------------------

set raname "IBM WebSphere Adapter for JDBC"
set nodeName " nlNode01"
set cfName  "test_cf"
set cfJndiName "eis/$cfName"
set cfInterface "javax.resource.cci.ConnectionFactory"

set ra [$AdminConfig getid /Node:$nodeName/J2CResourceAdapter:
 $raname/]

# set the parameter list
set params [list -name $cfName -jndiName $cfJndiName 
-connectionFactoryInterface $cfInterface]

# invoke createJ2CConnectionFactory to create the connection 
 factory
if {[catch { set cfList [$AdminTask createJ2CConnectionFactory 
 $ra $params]} result ]} {
      # Report error and exit
      puts "failed to create connection factory due to $result"
      exit
}

puts "created connection factory successfully."

# Save the changes.
$AdminConfig save

To create the activation spec for the specified Adapter, get the Adapter ID by invoking the "getid" command of AdminConfig, and then invoke the "createJ2CActivationSpec" command of AdminTask to create one activation spec instance, as shown in Listing 5.

#--------------------------------------------------------------
#  messageListenType - the name of message listener type
#  specName – the name of Activation Spec
#  specJndiName – the JNDI name of the Activation Spec
#  raname – the name of Resource Adapter
#  nodeName – node name
#--------------------------------------------------------------

set messageListenType  "com.ibm.j2ca.base.ExtendedInboundListener"
set specName     "test_as"
set specJndiName "eis/$specName"
set raname "IBM WebSphere Adapter for JDBC"
set nodeName "nlNode01"

set ra [$AdminConfig getid /Node:$nodeName/J2CResourceAdapter:$raname/]

# Attempt to create activation spec 
puts "creating activation spec :$specName ..."     

# Attempt to create activation spec
set params [list -name $specName -jndiName $specJndiName -messageListenerType 
 $messageListenType]
if {[catch { set specList [$AdminTask createJ2CActivationSpec $ra $params]} result ]} {
         # Report error and exit
         puts "failed to create activation spec due to $result"
         exit
}

puts "created activation spec successfully."

# Save the changes.
$AdminConfig save

Sample 3: Pause and resume the J2CMessageEndpoint

In this sample, we will introduce how to pause and resume the message endpoint by using wsadmin scripting.

During the inbound processing of WebSphere Adapter, the Adapter will poll the events from the target EIS, and then deliver the fetched data to the endpoint that subscribes the events. If the target endpoint is paused, the Adapter inbound processing is stopped. Also, the Adapter inbound processing is restarted once the target endpoint is resumed.

To pause the specified endpoint, first locate the corresponding “J2CMessageEndpoint” MBean with the specified name, and then invoke the “pause” command against the MBean through AdminControl to pause it, as shown in Listing 6.

#--------------------------------------------------------------
#  pauseJ2CMessageEndpoint – the process of pausing the 
J2CMessageEndpoint in Process Server
#  endpointName - the name of J2CMessageEndpoint
#  myCellName - cell name
#  myNodeName - node name
#  myServerName - server name
#--------------------------------------------------------------

proc pauseJ2CMessageEndpoint { endpointName myCellName myNodeName 
 myServerName } {
# get the MBean of J2CMessageEndpoint.
set J2CMessageEndpoint [$AdminControl queryNames cell=$myCellName,node=$myNodeName,
 type=J2CMessageEndpoint,process=$myServerName,* ]
puts "Check status of J2CMessageEndpoint. 1 = activated, 2 = 
 deactivated, 3 = stopped"
puts "J2CMessageEndpoint: $J2CMessageEndpoint"
foreach endpoint $J2CMessageEndpoint {
	if {([string first $endpointName $endpoint] >= 0) } {
	 puts [$AdminControl invoke $endpoint getActivationProperties] 
	 puts [$AdminControl invoke $endpoint getStatus]
	 puts "pausing the J2CMessageEndpoint ..."
	 puts [$AdminControl invoke $endpoint pause]
	 puts "completed" 
	}
}
}

To resume the specified endpoint, invoke the “resume” command against the corresponding “J2CMessageEndpoint” MBean through AdminControl, as shown in Listing 7.

#--------------------------------------------------------------
#  resumeJ2CMessageEndpoint - the process of resuming the 
J2CMessageEndpoint in Process Server
#  endpointName – the name of J2CMessageEndpoint
#  myCellName - cell name
#  myNodeName - node name
#  myServerName - server name
#--------------------------------------------------------------

proc resumeJ2CMessageEndpoint { endpointName myCellName 
 myNodeName 
 myServerName } {
# get the MBean of J2CMessageEndpoint.
set J2CMessageEndpoint [$AdminControl queryNames cell=$myCellName,node=$myNodeName,
 type=J2CMessageEndpoint,process=$myServerName,* ]
puts "Check status of J2CMessageEndpoints. 1 = activated, 2 
 = deactivated, 3 = stopped"
puts "J2CMessageEndpoint: $J2CMessageEndpoint"
foreach endpoint $J2CMessageEndpoint {
	if {([string first $endpointName $endpoint] >= 0) } {
	 puts [$AdminControl invoke $endpoint getActivationProperties] 
	 puts [$AdminControl invoke $endpoint getStatus]
	 puts "resuming the J2CMessageEndpoint ..."
	 puts [$AdminControl invoke $endpoint resume]
	 puts "completed" 
	}
}
}

Back to top

Conclusion

This article described some samples that can effectively manage WebSphere Adapters in WebSphere Process Server through the wsadmin scripting tool. Using the tool appropriately frees you from routine tasks and improves the overall efficiency of building an SOA business integration solution.

Back to top

Download

Information about download methods

Resources

• WebSphere Adapter Information Center
  
  
• Jacl: A Tcl Implementation in Java
  
  
• WebSphere Process Server: IBM's new foundation for SOA
  
  
• WebSphere Application Server v6.1 Information Center: Administrative scripting (wsadmin)
  
  
• IBM Redbook: WebSphere Application Server v6.1: System Management and Configuration
  
  

About the authors

Chang Liang Xing is a Staff Software Engineer in IBM China Software Development Lab, Beijing. He has many years of experience in WebSphere Adapter development, SOA, agile development, and other related technologies. He is a co-author of one IBM Redbook.

Jin Song Yuan is a Software Engineer in IBM China Software Development Lab, Beijing. He has many years of experience in WebSphere Adapter development.

Comments

Back to top

Trademarks  |  My developerWorks terms and conditions

Table of contents

• Introduction
• WebSphere Process Server
• WebSphere Adapter
• Java Management Extensions
• Wsadmin scripting tool
• Managing WebSphere Adapter agilely through wsadmin scripting
• Conclusion
• Download
• Resources
• About the authors
• Comments

Next steps from IBM

Rational Tester for SOA Quality is an automated web services testing and SOA testing tool that supports Web services SOAP, HTTP(S), JMS, WS-Security, UDDI, and RESTful standards.

---

• Try: The no-charge Rational Service Tester for SOA Quality helps quality assurance professionals validate web service based SOA application..
• Article: See the whats new with Rational Service Tester for SOA Quality, and its Generic Service Client, which provides a single client to interact with any SOA service type.
• Tutorial: Get hands-on experience with this Transport for SOAP feature tutorial using Rational Tester for SOA Quality.
• Buy: Rational Service Tester for SOA Quality

My developerWorks community

Dig deeper into WebSphere on developerWorks

Rate a product. Write a review.

Write a review for Rational products today!

Special offers