1. No category

How to configure the Oracle Service Bus
to access a NonStop SOAP service
Technical white paper
Table of contents
Introduction ......................................................................................................................................... 2
Architecture overview ........................................................................................................................... 2
Oracle Service Bus configuration and testing prerequisites........................................................................ 3
Configuration overview..................................................................................................................... 5
Configuring a business service for the NonStop SOAP service ............................................................... 7
Configuring a proxy service for the NonStop SOAP business service .................................................... 14
Using the Web Services Explorer to access the NonStop SOAP service with the Service Bus ................... 21
Appendix ......................................................................................................................................... 28
Listing 1: SoapPW_EmpAdd.wsdl - WSDL file generated by SoapAdminCL .......................................... 28
Listing 2: the modified port section in the AddEmployee.wsdl WSDL resource ....................................... 31
Listing 3: AddEmployee.wsdl file exported from the Service Bus proxy service ....................................... 31
Introduction
Service-oriented architectures (SOAs) are implemented using multiple technology components, but
one, in particular, the enterprise service bus (ESB), is emerging as a significant central component in
large SOA implementations. ESBs can provide many SOA client programs with basic access to
existing enterprise services, but they can also add value to existing enterprise services in specific
ways. Features provided by ESBs include enhanced security (such as, authentication and encryption),
message brokering (multiple protocol interfaces, multiple messaging models, mapping between
protocols, and the like), routing (context and content based), logging and monitoring, and options for
message transformation.
Although HP NonStop TS/MP and Pathway applications can be exposed to external Web services
clients through the use of HP NonStop SOAP software, it may not be clear that these applications can
be accessed readily through an ESB. In fact, existing NonStop TS/MP or Pathway services can be
integrated easily into a SOA that is implemented with an ESB.
This paper describes the basic configuration and testing required to validate NonStop application
integration with one of the leading ESB implementations, the Oracle Service Bus.
NonStop TS/MP and Pathway applications can be accessed by external Web services clients through
the use of NonStop SOAP software. The NonStop SOAP product also includes a sample Pathway
application for adding, deleting, and querying employee records in a simple employee database.
Scripts and documentation are also provided to help with configuring and running the NonStop
SOAP services. These services provide external clients with access to the employee database services
using SOAP requests over HTTP.
This paper describes how to configure the Oracle Service Bus to access the NonStop SOAP sample
employee database application, how to test the configuration using the Service Bus Test Console,
and, finally, how to test the end-to-end configuration from a workstation client program.
Architecture overview
The ESB enables many client programs to access a range of application services. The architecture,
therefore, includes client programs, the ESB, and the application services programs. Although,
application services can also serve as clients for consuming other services, in this case, the client
program resides on a workstation running the Microsoft® Windows® XP operating system. The Oracle
Service Bus ESB is installed on a blade server running Windows® Server 2003, and the application
services are configured and running on an HP Integrity NonStop system running the HP NonStop
operating system Release Version Update (RVU) H06.07 (see figure 1).
The specific client is the Web Services Explorer, which is part of the Eclipse Web Tools Platform
(WTP) Project. Both Eclipse and the WTP are open-source projects, and the software can be
downloaded from the Internet. MyEclipse was used in the actual testing, but the standard Eclipse
product will work as well. A Web Services Description Language (WSDL) file with port bindings is all
that is needed by the Web Services Explorer to access a SOAP Web service.
2
Figure 1: Oracle Service Bus test architecture
The two major configuration tasks are to describe to the Service Bus how to access application
services and to define the services that the Service Bus will be made available to the ESB clients.
Business services are the Service Bus components that are defined and configured to interact with the
application services. Proxy services are the Service Bus components that are defined and configured
to expose Service Bus services to clients. Although the Service Bus services can be enhanced greatly
compared to the raw application services, it is also possible to simply configure a proxy service that
does nothing more than expose an existing Service Bus business service.
Finally, the employee database application services are implemented on the HP NonStop system in a
Pathway (NonStop TS/MP) server class called EMPSVR. The EMPSVR provides three employees
database services: an ―add employee‖ service, a ―delete employee‖ service, and an ―employee
information‖ service.
The installation of NonStop SOAP software introduced a SOAPSERVER serverclass into the HP iTP
WebServer environment. It also modified the iTP WebServer HTTP request routing, so that the HTTP
daemons will send all SOAP requests to SOAPSERVERs. SOAPSERVER parses a SOAP request,
translates it into a Pathsend service request, and then invokes the appropriate employee database
service by using a Pathsend to send the translated service request to the EMPSVR. It builds a
SOAP response from the EMPSVR reply and returns it to an HTTP daemon, which sends it back to
the requestor.
Oracle Service Bus configuration and testing prerequisites
The Oracle Service Bus documentation should be reviewed and copied to a conveniently accessible
location, so it can be easily referenced during installation and testing.
The Service Bus then needs to be installed correctly and started. If it has been previously stopped, the
QuickStart program can be run on the Service Bus server to start the program.
The NonStop SOAP User’s Manual and Readme files included with the product provide instructions
on how to configure NonStop SOAP services to access existing Pathway or NonStop TS/MP services.
The sample employee database application is assumed to be configured and running already.
3
The WSDL for the NonStop SOAP ―add employee‖ service is required to configure the Service Bus
business service. The WSDL files that describe NonStop SOAP services can be generated using the
NonStop SOAP SoapAdminCL tool. The NonStop SOAP User’s Manual provides instructions on how
to generate the WSDL files. The generated WSDL file for the ―add employee‖ service is shown in
Listing 1 in the appendix. The WSDL file for the NonStop SOAP service must then be transferred to
the server running the Service Bus, or the contents must be made available for a subsequent copy and
paste directly into the Service Bus WSDL editor.
At the end of the WSDL file, in the ―port‖ section, there is a SOAP ―address location‖ that must be
updated with the IP address of the iTP WebServer environment installed on the NonStop system. You
must add a routing field, ―nssoap,‖ to the address. The SoapAdminCL-generated WSDL file ―address
location‖ will look as follows:
<soap:address location="http://www.nssoap.com/SoapServer.pway"/>
The modified version (see Listing 2 in the appendix) for this example will look as follows:
<soap:address location="http://204.160.19.110/nssoap/SoapServer.pway"/>
If the SDL file, empsdl.xml, is modified to include the following three attributes (with appropriate
values) within the ―SDL‖ tag before the WSDL is generated, the WSDL generated by the
SoapAdminCL tool will include the correct address location and will not require modification:
Url="/nssoap/SoapServer.pway"
ExeName="SoapServer.pway"
ServerAddress="http://204.160.19.110/"
Finally, to begin the Service Bus configuration process, you must point your browser to the program’s
console and log on to the program’s console. The URL for the Service Bus console that is used for
configuration and testing, is simply the IP address and port from the Service Bus and WebLogic
Server installation with the text ―sbconsole‖ appended. Following is an example:
http://204.160.20.229:7021/sbconsole
To log on to the Service Bus console, enter the user ID and password that were established for the
underlying WebLogic Server. If no changes were made to the default configuration, the user ID and
the password are both ―weblogic‖ (with all lowercase letters).
After you log on to the console, a Service Bus dashboard will be displayed, as shown in figure 2.
4
Figure 2: Service Bus dashboard
Configuration overview
Sessions
Changes within the Service Bus configuration must be made within a session. This means that the first
action to take before making any changes is to create a new session. After all the desired
configuration changes have been made, you must activate the current session, in order for the
changes to actually take effect. After you select ―Activate,‖ a window will be displayed that provides
a text field for entering the description of the changes and a ―Submit‖ button that should be pressed
to complete the activation of the changes. If you don’t wish to deploy the changes, you can discard
the session. The ―Create,‖ ―Activate,‖ and ―Discard‖ options will be displayed in the upper left-hand
panel of the program console under the heading ―Change Center.‖ You must decide how many
changes you wish to include within a single session before committing the changes.
Major Service Bus configuration steps
The first part of the Service Bus configuration is to configure the NonStop SOAP service as a
―Business Service.‖ This configuration can then be tested and validated through the use of the Service
Bus Test Console. The second part of the configuration is to configure the Service Bus ―Proxy Service‖
for the business service that was just configured. The new proxy service can also be tested with the
Service Bus Test Console.
5
Figure 3: New project screen
The configuration steps are as follows:
1. Create a project with three folders: BusinessServices, ProxyServices, and WSDL
2. Create a WSDL resource in the WSDL folder
3. Create and configure a business service
4. Test the business service with the Service Bus Test Console
5. Create and configure a proxy service
6. Test the proxy service with the Service Bus Test Console
This document describes the Service Bus configuration steps in detail for the ―add employee‖ service
that is provided by the NonStop SOAP sample employee database Pathway application. The other
two services that are provided by the Pathway application are the ―delete employee‖ service and the
―employee information‖ query service. The same steps would be followed to configure and test the
Service Bus for accessing these additional services.
6
Figure 4: ―My Project‖ screen
Configuring a business service for the NonStop SOAP service
Create a project and add folders
Projects provide a means of managing and organizing related services. To create a new project, you
will use the Project Explorer. Select the Project Explorer by clicking on it in the navigation panel in the
lower left side of the console display. An input box labeled ―Enter New Project Name‖ should be
displayed in the large window panel. Enter ―My Project‖ as the new project name and then press the
―Add Project‖ button (see figure 3). (If you have been browsing the existing projects, you will first
need to select ―Projects‖ from the middle window panel on the left side of the console. It has one
subitem—default. You will then see the new project creation line under the heading ―Projects.‖) After
you have created a new project, select the project by clicking on its name. You can then enter folder
names and create the folders within the new project (see figure 4). As a convention, for SOAP
services that have WSDL specifications, create BusinessServices, ProxyServices, and WSDL folders.
You can now select ―Activate‖ from the upper left ―Change Center‖ panel and submit a description of
the changes.
7
Figure 5: WSDL resource screen
Create the WSDL resource for the business service
Within a session, select the WSDL folder under My Project. In the Resource section of the screen,
there is a ―Create Resource‖ line with a pull-down menu labeled ―Select Resource Type.‖ Click on the
down arrow to display the pull-down menu options. Under the heading ―Interface,‖ select ―WSDL.‖
From the WSDL resource screen, you can enter the WSDL resource name, a description, and paste
the WSDL into the WSDL window, as shown in figure 5.
In this document, the service for which Service Bus is configured is the ―add employee‖ service, one
of the three services provided by the NonStop SOAP sample employee database application.
Therefore, the WSDL resource is named ―AddEmployee.wsdl‖ and is obtained from the
SoapPW_EmpAdd.wsdl file in the NonStop SOAP employee database application pway-wsdl
directory. This WSDL must have the SOAP address location modified, as described earlier in this
document in the section titled ―Oracle Service Bus configuration and testing prerequisites.‖
The modified WSDL is shown in Listing 2 in the appendix.
If the WSDL file had been transferred to the Service Bus server by way of a file transfer, the browse
window could have been used to find and select the WSDL file for loading. In this case, the WSDL
was pasted into the WSDL text window, the address location was modified as previously noted, and
then the ―Save‖ button below the window was pressed. If there is a problem with the WSDL, the
program will display an error message, the WSDL can be edited, and then the ―Save‖ can be
attempted again. After saving the WSDL, you should activate the session.
8
Figure 6: WSDL resource selection window on top of business service configuration screen
Create and configure a business service
Within a session, select the ―BusinessServices‖ folder under My Project. In the Resource section of the
large window panel, there is a ―Create Resource‖ line with a pull-down menu labeled ―Select
Resource Type.‖ Click on the down arrow to display the pull-down menu options. Under the heading
―Service,‖ select ―Business Service.‖
The Service Bus will display the ―Create a Business Service – General Configuration‖ window.
The Service Name, the Service Description, and the Service Type are all entered from this screen.
The Service Name and the Service Description are text fields, but the Service Type provides several
options. Because the NonStop service is a WSDL-defined SOAP service, select the radio button
labeled ―WSDL Web Service.‖ Now press the ―Browse‖ button that is on the same line as the WSDL
radio button. A new window will pop up with a list of available WSDL resources (see figure 6).
Select the desired WSDL resource by clicking on its name, which, in this case, is
―AddEmployee.wsdl.‖ The pop-up window display will now show the ―Select a WSDL Definition‖
panel. In the window panel just below the heading ―Select WSDL Definitions,‖ there are two
headings (―Bindings‖ and ―Ports‖), each with an entry under it. Because the NonStop service is
explicitly accessed by a fixed URL, click on the entry under ―Ports,‖ which is ―portEmpAdd,‖ and then
press the ―Submit‖ button under the window (see figure 7). The pop-up window will be closed and the
two text fields across from the WSDL Web Service radio button will now be filled in.
9
Figure 7: Select the WSDL definitions
At the bottom of the large General Configuration window panel, there are three buttons: ―Next,‖
―Finish,‖ and ―Cancel.‖ Pressing ―Next‖ will display a window from which ―Transport Configuration‖
options can be modified. Pressing ―Next‖ again will display a window from which transport-specific
options can be modified. In this case, because HTTP is the transport, this window provides options for
modifying the HTTP Transport Configuration. Pressing ―Next‖ again will display the SOAP Binding
Configuration, which has an option to Enforce WS-I Compliance.
Pressing ―Next‖ again will display a summary of all the options. A ―Save‖ button will appear at the
bottom of the Summary window. Selecting ―Finish‖ on any of the previous screens will immediately
display the Summary window. The Summary window is shown in figure 8. Press the ―Save‖ button
below the summary information to complete the configuration of the business service.
The business service configuration session should now be activated.
10
Figure 8: Create a business service summary screen
11
Figure 9: My Project BusinessServices screen
Test the business service with the Service Bus Test Console
To test the newly created business service, the target SOAP Web service must be running and
available on the NonStop system. Because testing requires no change to the Service Bus
configuration, a session is not required to test the business service.
From the Project Explorer panel on the left side of the Service Bus console, select ―BusinessServices‖
under ―My Project.‖ Under the ―Resources‖ section in the large window panel, there will be one
resource entry with the name ―AddEmployee.‖ The resource type is business service, and there are
three icons displayed under the heading ―Actions.‖ The middle icon, which looks like a bug, can be
clicked to start the ―Business Service Testing‖ facility (see figure 9).
Click on the bug to display the ―Business Service Testing – AddEmployee‖ window as shown in
figure 10.
12
Figure 10: Business Service Testing—AddEmployee window request document
No SOAP header information needs to be entered for the ―AddEmployee‖ service. Several fields in
the SOAP body must be modified, however, to create a valid request. The request code must be set
to ―02‖ for ―add employee,‖ and a four-digit employee number must be entered. Of course, an
employee first name, last name, and middle initial also must be entered. The regnum and branchnum
values do not require modification. You can then press the ―Execute‖ button to invoke the
AddEmployee Business Service, which will send a SOAP request using HTTP to the ―EmpAddService‖
on the NonStop system.
After the response is received from the NonStop service, the Business Service Testing window will
display the original ―Request Document‖ XML in the first window panel, the ―Response Document‖
XML (this is partly a copy of what was sent for this service) in the second panel, and the ―Response
Metadata‖ XML in the third panel; you must scroll down the window to view the third panel
(see figure 11).
This test facility can be used to test any business service. The next configuration activity is to define a
proxy service, so that Service Bus clients can request a service from the program that is mapped to
one or more Service Bus business services.
13
Figure 11: Business Service Testing—AddEmployee window response panels
Configuring a proxy service for the NonStop SOAP business service
Proxy services overview
Proxy services are defined to allow external clients to access services that are implemented on the
Service Bus. The Service Bus documentation describes proxy services as being implemented locally.
It is important to know, however, that a local implementation could be as simple as establishing the
routing of proxy client requests directly to a business service. The responses from the business service
would then flow back the inverse route to the proxy service, which, in turn, would send them back to
the client.
Service Bus provides many features and options for the development and delivery of proxy services
that provide substantial business value beyond the simple invocation of one or more business services.
Service Bus provides the following screens to create and configure a Web services proxy service:
general configuration, transport configuration, HTTP configuration, and operation selection. Once the
proxy service has been created, the message flows for the proxy service can be created and edited.
Service Bus also provides an option for creating a simple proxy service from an existing business
service. That is the option used in the following example, and it simplifies the configuration of the
proxy service.
14
Figure 12: Create a proxy service screen
Create and configure a proxy service
First, a new session must be created and the Project Explorer must be selected. From the Project
Explorer panel under ―My Project,‖ select ―ProxyServices.‖ In the Resource section of the large
window panel, there is a ―Create Resource‖ line with a pull-down menu labeled ―Select Resource
Type.‖ Click on the down arrow to display the pull-down menu options and, under the heading
―Service,‖ select ―Proxy Service.‖ The ―Create a Proxy Service – General Configuration‖ screen will
be displayed (see figure 12).
The proxy service requires a name and service type. For this service, the name is ―EmployeeAdd.‖
Under ―Service Type,‖ select the radio button by ―Business Service‖ that appears under the heading
―Create From Existing Service.‖ Next, press the Browse button on the ―Business Service‖ line, and a
―Select Business Service‖ window will be displayed, as shown in figure 13.
This window lists all the available business services. Select the radio button on the line with the
business service ―AddEmployee,‖ which is the service that was defined previously for ―My Project,‖
and then press the ―Submit‖ button at the bottom of the window. The ―Create a Proxy Service‖ screen
will be displayed again, and the text box by ―Business Service‖ will now be filled.
15
Figure 13: Select a business service window
At the bottom of the large window panel, the buttons ―Next,‖ ―Finish,‖ and ―Cancel‖ will be
displayed. Pressing ―Next‖ will display a window from which ―Transport Configuration‖ options can
be modified. Pressing ―Next‖ again will display a window from which transport-specific options can
be modified. In this case, because HTTP is the transport, this window provides options for modifying
the HTTP Transport Configuration. Pressing ―Next‖ again will display the Operation Selection
Configuration, which has an option to Enforce WS-I Compliance and has a set of radio button options
for the ―Selection Algorithm,‖ with ―SOAP Body Type‖ selected. Pressing ―Next‖ again will display
the ―Create a Proxy Service – Summary‖ screen.
The ―Create a Proxy Service – Summary‖ screen provides a summary display of all the proxy service
configuration options, with a ―Save‖ button at the bottom of the Summary window. Selecting ―Finish‖
on any of the previous screens will immediately display the Summary window. The Summary window
is shown in figure 14. Press the ―Save‖ button below the summary information to complete the
configuration of the proxy service.
The proxy service configuration session should now be activated.
16
Figure 14: Create a proxy service summary screen
Test the proxy service with the Service Bus Test Console
To test the newly created proxy service, the target SOAP Web service that is accessed by the business
service must be running and available on the NonStop system. Because testing requires no change to
the Service Bus configuration, a session is not required to test the proxy service.
From the Project Explorer panel on the left side of the Service Bus console, select ―ProxyServices‖
under ―My Project.‖ Under the ―Resources‖ section in the large window panel, there will be one
resource entry with the name ―EmployeeAdd.‖ The resource type is proxy service, and there are four
icons displayed under the heading ―Actions.‖ The third icon, which looks like a bug, can be clicked
to invoke the ―Proxy Service Testing‖ facility (see figure 15).
17
Figure 15: My Project ProxyServices screen
Click on the bug to display the ―Proxy Service Testing – EmployeeAdd‖ window as shown in
figure 16.
18
Figure 16: Proxy Service Testing—EmployeeAdd request window
Testing the proxy service is done in the same way that the business service was tested. The SOAP
body in the request document must be edited with the appropriate entries. The request code for ―add
employee‖ is ―02.‖ A four-digit employee number, first name, last name, and middle initial must be
entered, and then the Execute button can be pressed to send the request.
After the response is received from the business service, the Proxy Service Testing window will display
the original ―Request Document‖ XML in the first window panel, the ―Response Document‖ XML (which
is partly a copy of what was sent for this service) in the second panel, and the ―Response Metadata‖
XML in the third panel; you must scroll up the window to view it (see figure 17).
If the ―Include Tracing‖ box was checked under ―Test Configuration‖ in the request window, a fourth
panel, which is labeled ―Invocation Trace,‖ will be included in the response window and will contain
detailed service tracing information.
19
Figure 17: Proxy Service Testing—EmployeeAdd response window
The Service Bus Test Console can be used to test and validate all proxy services before external clients
begin to use the proxy services. Those clients accessing WSDL-based proxy services will typically
require the WSDL for development and configuration. To address this requirement, Service Bus
provides a simple means of generating WSDL from a defined proxy service. In the case where the
proxy service was created from a business service that had been defined with WSDL, the WSDL
already exists for the interface definition. However, the port bindings will be for the external service,
not for the Service Bus proxy service. The WSDL generated from the proxy service will have the
correct binding and port information for accessing the proxy service on the Service Bus.
Generating WSDL for Service Bus proxy service clients
Select ProxyServices under ―My Project‖ in the Project Explorer navigation panel. The ProxyServices
screen will be displayed, as shown in figure 15. The available proxy services are listed under the
Resources heading. Identify the proxy service for which WSDL is to be generated and then locate the
fourth icon under ―Actions‖ on the line with the selected proxy service name. In this case, you want to
locate the ―EmployeeAdd‖ line. The fourth icon looks like a low wide letter U with a little arrow inside
that points to the upper right. If you just place the mouse cursor over the icon, it will display the action
name as ―Export WSDL.‖ Click on the ―Export WSDL‖ icon.
Service Bus provides the generated WSDL file inside of a jar file. When you click on the ―Export
WSDL‖ icon, a ―File Download‖ window will be displayed. The window shows the name of the file to
be downloaded, which, in this case, is ―EmployeeAdd_WSDL.jar.‖ It will give you three options:
―Open,‖ ―Save,‖ or ―Cancel.‖ Select ―Save.‖ A ―Save As‖ window will be displayed, which allows
you to select the location on your local computer to save the jar file that will be downloaded from the
Service Bus. The ―AddEmployee.wsdl‖ file can be extracted from the jar file using WinZip or another
appropriate utility. The ―AddEmployee.wsdl‖ file is shown in Listing 3 in the appendix.
20
Figure 18: MyEclipse Web Services Explorer screen
Using the Web Services Explorer to access the NonStop SOAP service
with the Service Bus
The Service Bus Test Console is valuable for testing both business services and proxy services. The
testing is done from the Service Bus system, however, and production client applications would
typically run on different systems. Consequently, it would be more appropriate to test the Service Bus
proxy service from an external client, similar to a production configuration.
The Eclipse Web Tools Platform Project provides a Web Services Explorer program for easy testing of
WSDL-defined services. The Web Services Explorer works with Eclipse and MyEclipse. MyEclipse and
Eclipse both run on Windows, Linux, and Mac OS X based workstations.
Some experience with the MyEclipse Integrated Development Environment (IDE) is assumed for the
following instructions.
First, create a new project in MyEclipse of the ―Web Service‖ type. Then add the generated
―AddEmployee.wsdl‖ file to the project. The Web Services Explorer can now be launched from the
default J2EE Development Perspective by clicking on the ―Launch Web Services Explorer‖ icon. The
Web Services Explorer screen will then be displayed, as shown in figure 18.
21
Figure 19: MyEclipse Web Services Explorer displaying Open WSDL Action
In the top right corner of the Web Services Explorer window, there are six dim toolbar icons. The one
by the star is the same icon that was clicked to start the Web Services Explorer. When the cursor is
placed over this icon, it will display ―WSDL Page.‖ Click on this icon. The Navigator panel on the left
side of the explorer will display ―WSDL Main‖ rather than ―UDDI Main,‖ as shown in figure 18. Click
on ―WSDL Main‖ in the Navigator panel, and the Actions panel will display the ―Open WSDL‖
action, as shown in figure 19.
In the Actions panel, click on the ―Browse…‖ button. A small window titled ―Web Browser‖ will be
displayed, as shown in figure 20.
22
Figure 20: MyEclipse Web Services Explorer with overlaid Web browser window
Three boxes must be filled in to point to the WSDL file that describes the Service Bus proxy
service that will be tested. The ―Category‖ box defaults to ―Workplace WSDL Documents,‖ which
is fine and does not need to be changed. The ―Workspace Projects‖ box should show the project
into which the WSDL was added, which, in this case, is ―My Project.‖ And, finally, the ―WSDL URL‖
box should point to the Service BusWSDL file, which, in this case, is ―platform:/resource/My
Project/WebServices/AddEmployee.wsdl.‖ When all the boxes are filled in correctly, click on ―Go.‖
The screen shown in figure 19 will be displayed again, only now the WSDL box in the Actions panel
will contain the following:
―platform:/resource/My Project/WebServices/AddEmployee.wsdl‖
Click on ―Go‖ under the WSDL URL text box, and the Actions panel will display the WSDL binding
details, as shown in figure 21.
23
Figure 21: MyEclipse Web Services Explorer displaying WSDL binding details
Now, in the Actions panel under Operations, the name of the service will be displayed as a clickable
name. Click on EmpAdd, and the Web Services Explorer will use the WSDL to create a data entry
form that can be used to create and submit an employee add service request, as shown in figure 22.
Fill in the appropriate values, as shown in figure 22, and then click on ―Go.‖ If the operation was
successful, the Status box at the bottom of the Actions panel will display an EmpAdd Response value
of 0 and a Reply Code of 2, followed by the employee information that was submitted in the request
(see figure 23).
The Status box will display the word ―Source‖ in the upper-right corner. If this word is clicked, the
Status box will change the word to ―Form‖ and display two scrolling windows below it. The first
window contains the ―SOAP Request Envelope:‖ and the second window contains the ―SOAP
Response Envelope:‖.
24
Figure 22: MyEclipse Web Services Explorer showing Invoke a WSDL operation for EmpAdd service
If there was an error in processing the request, the Status box will display the following text:
―There is nothing to be displayed in the form view. Please switch to the source view for the SOAP
request and response.‖
Click on the word ―Source‖ and expand the Status box to see the scrolling windows. The XML source
displayed in the ―SOAP Response Envelope‖ will provide more information about the problem. Figure
24 shows the type of response that can be received when an attempt is made to add the same
employee more than once. The error text ―Unable to write to employ file; error : 10‖ indicates that a
record with the same employee number already exists within the EMPLOY file.
25
Figure 23: MyEclipse Web Services Explorer screen showing Status from EmpAdd service invocation
26
Figure 24: MyEclipse Web Services Explorer status box showing SOAP envelopes
The steps that have been described for configuring and testing the ―add employee‖ service can be
repeated to configure and test the ―delete employee‖ service and the ―employee information‖ service.
27
Appendix
Listing 1: SoapPW_EmpAdd.wsdl - WSDL file generated by
SoapAdminCL
<?xml version="1.0" encoding="UTF-8"?>
<definitions name="EmpAdd-interface"
targetNamespace="urn:EmpAdd-interface"
xmlns:def="urn:EmpAdd-interface"
xmlns="http://schemas.xmlsoap.org/wsdl/"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:hdr="urn:compaq_nsk_oss_SoapHeader"
xmlns:tns="urn:cpq_tns_EmpAdd"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<types>
<xsd:schema
targetNamespace="urn:compaq_nsk_oss_SoapHeader"
xmlns="http://www.w3.org/2001/XMLSchema">
<xsd:element name="Session">
<xsd:complexType>
<xsd:attribute use="optional"
name="SessionID"
type="xsd:string" />
<xsd:attribute use="optional"
name="BeginNewTransaction"
type="xsd:string" />
<xsd:attribute use="optional"
name="CurrentTransactionCommand"
type="xsd:string" />
<xsd:attribute use="optional"
name="SessionCommand"
type="xsd:string" />
<xsd:attribute use="optional"
name="Subsession"
type="xsd:string" />
</xsd:complexType>
</xsd:element>
<xsd:element name="Encoding">
<xsd:complexType>
<xsd:attribute name="OutputEncoding" type="xsd:string"
use="required" />
</xsd:complexType>
</xsd:element>
</xsd:schema>
<xsd:schema
targetNamespace="urn:cpq_tns_EmpAdd"
xmlns="http://www.w3.org/2001/XMLSchema">
<xsd:complexType name="empname">
<xsd:sequence>
<xsd:element name="first" minOccurs="1" maxOccurs="1">
<xsd:simpleType>
<xsd:restriction base="xsd:string">
<xsd:maxLength value="20"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:element>
<xsd:element name="last" minOccurs="1" maxOccurs="1">
<xsd:simpleType>
<xsd:restriction base="xsd:string">
<xsd:maxLength value="30"/>
</xsd:restriction>
</xsd:simpleType>
28
</xsd:element>
<xsd:element name="middle" minOccurs="1" maxOccurs="1">
<xsd:simpleType>
<xsd:restriction base="xsd:string">
<xsd:maxLength value="1"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="employee_info">
<xsd:sequence>
<xsd:element name="employee_number" type="xsd:long" minOccurs="1"
maxOccurs="1"/>
<xsd:element name="empname" type="tns:empname" minOccurs="1"
maxOccurs="1"/>
<xsd:element name="regnum" type="xsd:long" minOccurs="1"
maxOccurs="1"/>
<xsd:element name="branchnum" type="xsd:long" minOccurs="1"
maxOccurs="1"/>
</xsd:sequence>
</xsd:complexType>
<xsd:element name="EmpAddResponse0" type="tns:EmpAddResponse0"/>
<xsd:complexType name="EmpAddResponse0">
<xsd:sequence>
<xsd:element name="reply_code" type="xsd:long" minOccurs="1"
maxOccurs="1"/>
<xsd:element name="employee_info" type="tns:employee_info"
minOccurs="1" maxOccurs="1"/>
</xsd:sequence>
</xsd:complexType>
<xsd:element name="EmpAddResponse1" type="tns:EmpAddResponse1"/>
<xsd:complexType name="EmpAddResponse1">
<xsd:sequence>
<xsd:element name="reply_code" type="xsd:long" minOccurs="1"
maxOccurs="1"/>
<xsd:element name="error_text" minOccurs="1" maxOccurs="1">
<xsd:simpleType>
<xsd:restriction base="xsd:string">
<xsd:maxLength value="60"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
<xsd:element name="EmpAdd" type="tns:EmpAdd"/>
<xsd:complexType name="EmpAdd">
<xsd:sequence>
<xsd:element name="request_code" type="xsd:long" minOccurs="1"
maxOccurs="1"/>
<xsd:element name="employee_info" type="tns:employee_info"
minOccurs="1" maxOccurs="1"/>
</xsd:sequence>
</xsd:complexType>
</xsd:schema>
</types>
<message name="outEmpAddResponse0">
<part name="EmpAddResponse0"
element="tns:EmpAddResponse0"/>
</message>
29
<message name="outEmpAddResponse1">
<part name="EmpAddResponse1"
element="tns:EmpAddResponse1"/>
</message>
<message name="inEmpAdd">
<part name="EmpAdd"
element="tns:EmpAdd"/>
</message>
<message name="nss_SoapSessionHeader">
<part name="Session"
element="hdr:Session"
/>
</message>
<message name="nss_SoapEncodingHeader">
<part name="Encoding"
element="hdr:Encoding"
/>
</message>
<portType
name="portEmpAdd">
<operation
name="EmpAdd">
<input
name="inEmpAdd"
message="def:inEmpAdd"/>
<output
name="outEmpAddResponse0"
message="def:outEmpAddResponse0"/>
<fault
name="outEmpAddResponse1"
message="def:outEmpAddResponse1"/>
</operation>
</portType>
<binding
name="EmpAddBinding"
type="def:portEmpAdd">
<soap:binding style="document"
transport="http://schemas.xmlsoap.org/soap/http"/>
<operation
name="EmpAdd">
<soap:operation
soapAction="EmpAdd"/>
<input name="inEmpAdd">
<soap:body
namespace="urn:cpq_tns_EmpAdd"
use="literal"/>
<soap:header
wsdl:required="false"
message="def:nss_SoapSessionHeader"
part="Session"
use="literal" />
<soap:header
wsdl:required="false"
message="def:nss_SoapEncodingHeader"
part="Encoding"
use="literal" />
</input>
30
<output name="outEmpAddResponse0">
<soap:body
namespace="urn:cpq_tns_EmpAdd"
use="literal"/>
<soap:header
wsdl:required="false"
message="def:nss_SoapSessionHeader"
part="Session"
use="literal" />
</output>
<fault name="outEmpAddResponse1">
<soap:fault name="outEmpAddResponse1"
namespace="urn:cpq_tns_EmpAdd"
use="literal"/>
</fault>
</operation>
</binding>
<service name="EmpAddService">
<port name="portEmpAdd"
binding="def:EmpAddBinding">
<soap:address location="http://www.nssoap.com/SoapServer.pway"/>
</port>
</service>
</definitions>
Listing 2: the modified port section in the AddEmployee.wsdl
WSDL resource
<port name="portEmpAdd"
binding="def:EmpAddBinding">
<soap:address
location="http://204.160.19.110/nssoap/SoapServer.pway"/>
</port>
Listing 3: AddEmployee.wsdl file exported from the Service Bus
proxy service
<?xml version="1.0" encoding="UTF-8"?>
<definitions name="EmpAdd-interface" targetNamespace="urn:EmpAddinterface" xmlns="http://schemas.xmlsoap.org/wsdl/"
xmlns:s0="urn:cpq_tns_EmpAdd" xmlns:s1="urn:compaq_nsk_oss_SoapHeader"
xmlns:s2="urn:EmpAdd-interface"
xmlns:s3="http://schemas.xmlsoap.org/wsdl/soap/">
<types>
<xsd:schema targetNamespace="urn:compaq_nsk_oss_SoapHeader"
xmlns="http://www.w3.org/2001/XMLSchema" xmlns:def="urn:EmpAddinterface" xmlns:hdr="urn:compaq_nsk_oss_SoapHeader"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:tns="urn:cpq_tns_EmpAdd"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<xsd:element name="Session">
<xsd:complexType>
<xsd:attribute name="SessionID" type="xsd:string"
use="optional"/>
<xsd:attribute name="BeginNewTransaction" type="xsd:string"
use="optional"/>
31
<xsd:attribute name="CurrentTransactionCommand"
type="xsd:string" use="optional"/>
<xsd:attribute name="SessionCommand" type="xsd:string"
use="optional"/>
<xsd:attribute name="Subsession" type="xsd:string"
use="optional"/>
</xsd:complexType>
</xsd:element>
<xsd:element name="Encoding">
<xsd:complexType>
<xsd:attribute name="OutputEncoding" type="xsd:string"
use="required"/>
</xsd:complexType>
</xsd:element>
</xsd:schema>
<xsd:schema targetNamespace="urn:cpq_tns_EmpAdd"
xmlns="http://www.w3.org/2001/XMLSchema" xmlns:def="urn:EmpAddinterface" xmlns:hdr="urn:compaq_nsk_oss_SoapHeader"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:tns="urn:cpq_tns_EmpAdd"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<xsd:complexType name="empname">
<xsd:sequence>
<xsd:element maxOccurs="1" minOccurs="1" name="first">
<xsd:simpleType>
<xsd:restriction base="xsd:string">
<xsd:maxLength value="20"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:element>
<xsd:element maxOccurs="1" minOccurs="1" name="last">
<xsd:simpleType>
<xsd:restriction base="xsd:string">
<xsd:maxLength value="30"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:element>
<xsd:element maxOccurs="1" minOccurs="1" name="middle">
<xsd:simpleType>
<xsd:restriction base="xsd:string">
<xsd:maxLength value="1"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="employee_info">
<xsd:sequence>
<xsd:element maxOccurs="1 " minOccurs="1"
name="employee_number" type="xsd:long"/>
<xsd:element maxOccurs="1" minOccurs="1" name="empname"
type="tns:empname"/>
<xsd:element maxOccurs="1" minOccurs="1" name="regnum"
type="xsd:long"/>
32
<xsd:element maxOccurs="1" minOccurs="1" name="branchnum"
type="xsd:long"/>
</xsd:sequence>
</xsd:complexType>
<xsd:element name="EmpAddResponse0">
<xsd:complexType>
<xsd:sequence>
<xsd:element maxOccurs="1" minOccurs="1" name="reply_code"
type="xsd:long"/>
<xsd:element maxOccurs="1" minOccurs="1"
name="employee_info" type="tns:employee_info"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="EmpAddResponse1">
<xsd:complexType>
<xsd:sequence>
<xsd:element maxOccurs="1" minOccurs="1" name="reply_code"
type="xsd:long"/>
<xsd:element maxOccurs="1" minOccurs="1" name="error_text">
<xsd:simpleType>
<xsd:restriction base="xsd:string">
<xsd:maxLength value="60"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="EmpAdd">
<xsd:complexType>
<xsd:sequence>
<xsd:element maxOccurs="1" minOccurs="1" name="request_code"
type="xsd:long"/>
<xsd:element maxOccurs="1" minOccurs="1"
name="employee_info" type="tns:employee_info"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:schema>
</types>
<message name="outEmpAddResponse0">
<part element="s0:EmpAddResponse0" name="EmpAddResponse0"/>
</message>
<message name="outEmpAddResponse1">
<part element="s0:EmpAddResponse1" name="EmpAddResponse1"/>
</message>
<message name="inEmpAdd">
<part element="s0:EmpAdd" name="EmpAdd"/>
</message>
<message name="nss_SoapSessionHeader">
<part element="s1:Session" name="Session"/>
</message>
<message name="nss_SoapEncodingHeader">
<part element="s1:Encoding" name="Encoding"/>
33
</message>
<portType name="portEmpAdd">
<operation name="EmpAdd">
<input message="s2:inEmpAdd"/>
<output message="s2:outEmpAddResponse0"/>
<fault message="s2:outEmpAddResponse1" name="outEmpAddResponse1"/>
</operation>
</portType>
<binding name="EmpAddBinding" type="s2:portEmpAdd">
<s3:binding style="document"
transport="http://schemas.xmlsoap.org/soap/http"/>
<operation name="EmpAdd">
<s3:operation soapAction="EmpAdd"/>
<input>
<s3:body namespace="urn:cpq_tns_EmpAdd" use="literal"/>
<s3:header message="s2:nss_SoapSessionHeader" part="Session"
use="literal"/>
<s3:header message="s2:nss_SoapEncodingHeader" part="Encoding"
use="literal"/>
</input>
<output>
<s3:body namespace="urn:cpq_tns_EmpAdd" use="literal"/>
<s3:header message="s2:nss_SoapSessionHeader" part="Session"
use="literal"/>
</output>
<fault name="outEmpAddResponse1">
<s3:fault name="outEmpAddResponse1"
namespace="urn:cpq_tns_EmpAdd" use="literal"/>
</fault>
</operation>
</binding>
<service name="EmpAddService">
<port binding="s2:EmpAddBinding" name="portEmpAdd">
<s3:address location="http://BMC005.atc-hp.com:7021/EmployeeAdd"/>
</port>
</service>
</definitions>
To learn more about Oracle Service Bus, visit www.oracle.com/us/technologies/soa/service-bus066459.html, and to learn more about HP NonStop, visit www.hp.com/go/nonstop.
© Copyright 2007, 2011 Hewlett-Packard Development Company, L.P. The information contained herein is
subject to change without notice. The only warranties for HP products and services are set forth in the express
warranty statements accompanying such products and services. Nothing herein should be construed as
constituting an additional warranty. HP shall not be liable for technical or editorial errors or omissions
contained herein.
Microsoft, Windows, and Windows XP are U.S. registered trademarks of Microsoft Corporation. Oracle is a
registered trademark of Oracle and/or its affiliates.
4AA1-1038ENW, Created March 2007; Updated April 2011, Rev. 1