Network Deployment (Distributed operating systems), v8.0 > Scripting the application serving environment (wsadmin) > Welcome to scripting for web services > Configure web services applications using wsadmin.sh
Configure the scope of a web service port using wsadmin.sh
When a web service application is deployed into WebSphere Application Server, an instance is created for each application or module. The instance contains deployment information for the web module or EJB module, including implementation scope, client bindings and deployment descriptor information. There are three levels of scope that can be set: application, session and request. If we have not deployed the EAR file yet, have it ready or already deployed to the application server. The primary purpose of this task is to enable the configuration of the web service port scope. The scope originally specified when the JavaBeans object is enabled as a web service during the development process can be changed with the WebServicesServerBindPort command. The scope attribute does not apply to web services that use Java Message Service (JMS) transport or to enterprise beans.
Web Services for Java 2 platform Enterprise Edition (J2EE) specifies that web services implementations must be stateless. Therefore, to maintain specification compliance, the scope can remain at the application level because the state relevant to the individual sessions level or the requests level is not supposed to be maintained in the implementation. If you want to deviate from the specification and want to access a different JavaBeans instance, because you are looking for information that is located in another JavaBeans, the scope settings need to change.
The setting that you configure for the scope determines how frequently a new instance of a service implementation class is created for the web service ports in a module. The application scope causes the same instance of the implementation to be used for all requests on the application. The session scope causes the same instance to be used for all requests in each session. The request scope causes a new instance to be used for every request. For example, with the scope set to application, every message that comes to the server accesses the same Java bean instance.
To change the scope setting through wsadmin.sh:
Procedure
- Launch a scripting command.
To learn more, see the starting the wsadmin scripting client information.
- Configure the scope of the web service port.
To use the existing listener port instead of using or creating a new activation specification, determine whether the EJB JAR version is lower than 2.1. The system automatically creates and uses an activation specification when you specify the -usedefaultbindings option to deploy an application. If an activation specification exists, the system ignores the listener port, and instead uses the activation specification.
To deploy an application with an EJB JAR version greater than or equal to 2.1 using the defined listener ports instead of a new activation specification, set the com.ibm.websphere.management.application.dfltbndng.mdb.preferexisting system property to true in the wsadmin.properties file in the properties directory of the profile of interest.
Use the install, installInteractive, edit, or editInteractive options to configure the scope of the web service port, as the following syntax demonstrates:
$AdminApp install app_name {-usedefaultbindings -deployejb -WebServicesServerBindPort {{ <module_name> <Web_service> <port> <scope_setting>}...}The previous example indicates that the scope of multiple ports can be changed using one WebServicesServerBindPort command, where:
- app_name is the application name, for example WebServicesSample.ear
- module_name is the module name, for example AddressBookW2JE.jar
- Web_service is the name of the web service, for example AddressBookW2JE service/WSLoggerService2
- port is the name of the port, for example AddressBook
- scope_setting is the level of setting for scope, for example Session
Results
The scope for a web service port is configured.
Example
The following example of the presents the application, module, web service, port and scope as it is written in the command line:$AdminApp install WebServicesSamples.ear {-usedefaultbindings -deployejb -deployws -WebServicesServerBindPort {{AddressBookJ2WB.war AddressBookService AddressBook request} {AddressBookW2JB.war AddressBookService AddressBook application}}}
What to do next
Now you can finish any other configurations, start or restart the application, and verify expected behavior of the web service.
Web services client port information
Web services client bindings
Start the wsadmin scripting client using wsadmin.sh
Configure web service client-preferred port mappings using wsadmin.sh
Configure web service client port information using wsadmin.sh
Related
Options for the AdminApp object install, installInteractive, edit, editInteractive, update, and updateInteractive commands using wsadmin.sh