WS-I Attachments Sample Application 1.0

1.0 Introduction 2.0 Directory Structure 3.0 Pre-Requisites 3.1 Container 3.2 Database 3.3 Registry 4.0 Invoking the service 4.1 Retailer 4.2 Configurator 4.3 Catalog 5.0 Building from the source 6.0 Configuring Logging 7.0 Troubleshooting 8.0 References 1.0 Introduction The Web Services Interoperability Organization (WS-I) [1] is committed to promoting interoperability among Web Services based on common, industry-accepted definitions and related XML standards. Towards this end, WS-I produces deliverables intended to assist developers in creating and deploying interoperable Web Services. WS-I Sample Application, one of the deliverables from WS-I, demonstrates the practical application of Web Services technologies to solve real business needs. WS-I Sample Application is a sample Supply Chain Management application. Its use case design is defined in Supply Chain Management Use Case Model [2] and Use Cases for Attachments Sample Applications 1.0 [3] . Technical design and implementation details of this sample application are documented in Supply Chain Management Architecture document [4] and Technical Architecture for Attachments Sample Applications 1.0 [5]. The following illustration shows the various components of the Sample Application. The application being modeled is that of a Retailer offering consumer electronic goods to Consumers; a typical B2C model. To fulfill orders, the Retailer has to manage stock levels in Warehouses (WarehouseA, WarehouseB, and WarehouseC). When an item in stock falls below a certain threshold, the Retailer must restock the item from the relevant Manufacturer’s (ManufacturerA, ManufacturerB, and ManufacturerC) inventory; a typical B2B model. In order to fulfill a Retailer’s request, a Manufacturer may have to execute a production run to build the finished goods. Each use case includes a logging call to a logging facility in order to monitor the activities of the services. Retailer can also out-source the cataloging capabilities to a Catalog service that provides operations to access the catalog of products. The Catalog enables a consumer to browse it’s contents and retrieve additional information about individual items. The consumer can then order the products from the Catalog which can then be packaged into an order and sent to a Retailer. Retailer, Logging, WarehouseA, WarehouseB, WarehouseC, ManufacturerA, ManufacturerB, and ManufacturerC are published as Web Services by WS-I member companies participating in WS-I Sample Applications Working Group. Optionally, there is a Configurator Web Service that lists all of the implementations registered in the UDDI registry for each of the Web Services in the sample application. The 1 Retailer, 1 Logging Facility, 3 Warehouses, 3 Manufacturers, and 1 Configurator Web Service are designed and implemented as part of WS-I Supply Chain Management Sample Applications 1.0 FCS. 1 Catalog Web Service is designed and implemented as part of WS-I Attachments Sample Applications 1.0. It demonstrates application of Basic Profile 1.1 [6], Simple SOAP Binding Profile 1.0 [7], and Attachments Profile 1.0 [8] to a real-life scenario. This document explains the Sun’s implementation of WS-I Sample Supply Chain Management Application 1.0 FCS and WS-I Attachments Sample Applications 1.0 EA3. 2.0 Directory Structure This section explains the directory structure of the wsi-sampleapp directory bundled with Java Web Services Developer Pack 1.5 (Java WSDP): bin Scripts to invoke the retailer, configurator and catalog clients docs index.html, this file etc/config Configuration files required by the JAX-RPC tools etc/wsdl WSDL descriptions for the Web Services lib Client jar file src Source code wsi-server.war WAR file with all the Web Service endpoints logs Generated results and SOAP request and response message files 3.0 Pre-Requisites Before any of the sample app Web Services can be invoked, you need to download the Java WSDP from java.sun.com/webservices/downloads/webservicespack.html and configure the web container and database of your choice as described below. Java WSDP supports three containers, which you can download from java.sun.com/webservices/containers.html. 3.1 Web Container Configuration This section explains how to set up your chosen web container. 3.1.1 Sun Java System Application Server 8.0 Platform Edition (recommended) Start the Application Server. If HTTP proxy host and port are not configured during Sun Java System Application Server or Java WSDP installation, configure the http.proxyHost and http.proxyPort properties for the container by giving the following command: asadmin create-jvm-options –user –password -Dhttp.proxyHost=:-Dhttp.proxyPort= If the Application Server is not running on the standard host and port (typically “localhost:8080”), then you need to specify –host and –port options. Alternatively, you can use the Admin Console and select JVM Settings, JVM Options to view and change these properties. 3.1.2 Sun Java System Web Server 6.1 If HTTP proxy host and port are not configured during Sun Java System Web Server or Java WSDP installation, configure the http.proxyHost and http.proxyPort properties for the container. Using the Admin server GUI (usually port 8888): Select the Manage function on the appropriate virtual server. On the administration page for the virtual server, click on the “Java” tab. Select the “JVM Options” from the left panel. Specify -Dhttp.proxyHost= in the first empty text box next to “Add” and click on OK twice. Specify -Dhttp.proxyPort= in the first empty text box next to “Add” and click on OK twice. Specify -Djava.awt.headless=true in the first empty box next to “Add” and click on OK twice. This will enable the headless operation for AWT images involved in the Catalog Web Service. Click on “Apply” on the top-right corner of the administration page for the changes to take effect. 3.1.3 Tomcat for Java WSDP If HTTP proxy host and port are not configured during Tomcat or Java WSDP installation, configure the http.proxyHost and http.proxyPort properties for the container Add http.proxyHost= on a new line to TOMCAT_HOME/conf/jwsdp.properties. Add http.proxyPort= on a new line to TOMCAT_HOME/conf/jwsdp.properties. If Tomcat container is running, stop it. In your conf/server.xml, set the unpackWARs attribute to true in the Engine element within the Host element whose host attribute is localhost. This is a container-wide setting and will impact other applications deployed in this container as well. Enabling this setting explodes the content of the war file in TOMCAT_HOME/webapps directory by the war file name. To redeploy an app, the exploded directory needs to be removed from TOMCAT_HOME/webapps directory before starting the Tomcat container. 3.2 Database configuration This section explains how to set up your chosen database. The Pointbase database that comes bundled with Sun Java System Application Server 8.0 Platform Edition is recommended. However, you may want to use the MySQL database for Sun Java System Web Server 6.1 or Tomcat. The JWSDP_HOME/wsi-sampleapp/wsi-server.war is configured to be used with the Pointbase database server. The steps to reconfigure the WAR file for MySQL database are given in section 3.2.2 below. 3.2.1 Pointbase database A functional version of pointbase is available in AS_HOME/pointbase directory, where AS_HOME is the installation directory of Sun Java System Application Server 8.0 Platform Edition (SJSAS 8.0PE). This version of pointbase can be used under the licensing terms of SJSAS 8.0 PE. To set up this version of Pointbase for use with the WS-I sample application: Start the Pointbase database server Go to AS_HOME/pointbase/tools/serveroption directory and invoke the startserver.[sh | bat] script. Make sure that the database server is listening on port 9092. The port number is displayed when the script is invoked. Otherwise you can change the port number by modifying the script to add /port:9092 after com.pointbase.net.netServer. Create a database Go to AS_HOME/pointbase/tools/serveroption directory and invoke the startconsole.[sh | bat] script. If “Connect to Database” window opens up, select “Create New Database”. If “Connect to Database” window does not open up, then select DBA menu item from the main menu, select Create and then select New Database. Take the defaults for Driver, User and Password options. Change the URL to jdbc:pointbase:server://localhost/wsi Hit OK. You should see “Creating new Database …” message in the bottom pane. Click on File – Exit to leave the database connection window. Copy the jar file containing the JDBC driver to the container (pbclient.jar). For the Sun Java System Application Server container: Copy the jar file from AS_HOME/pointbase/lib to AS_HOME/domains/domain1/lib/ext directory, if domain1 is the chosen domain. For the Sun Java System Web Server 6.1 container: Edit the server.xml for the instance chosen during Java WSDP installation. Typically this file will be in the https-/config directory, where is the name of your server on which Sun Java System Web Server 6.1 is installed (or “localhost”). Search for classpathsuffix attribute. Add the absolute path of the jar file at the end of the value of classpathsuffix attribute. For the Tomcat container: Copy the jar file to TOMCAT_HOME/common/lib. If the WS-I sample application has been configured for the MySQL database earlier and now needs to be configured with the Pointbase database, you need to repackage the war file and redeploy the wsi web application as follows: Go to JWSDP_HOME/wsi-sampleapp/src directory and invoke the change-database target as follows ant change-database If your container is the Web Server, first undeploy the wsi-server.war cd WS_HOME/bin/https/bin wdeploy delete -u /wsi-server -i localhost -v https-localhost hard Invoke the deploy.wsi-sampleapp.webapps target on the integration script for your container. JWSDP_HOME/jwsdp-shared/bin/jwsdponsjsas.[sh | bat] for Sun Java System Application Server JWSDP_HOME/jwsdp-shared/bin/jwsdponsjsws.[sh | bat] for Sun Java System Web Server JWSDP_HOME/jwsdp-shared/bin/jwsdpontomcat.[sh | bat] for Tomcat For instance, for Sun Java System Application Server installed in /opt/SUNWappserver directory, from the JWSDP_HOME/jwsdp-shared/bin/ directory this script is invoked as: jwsdponsjsas.sh /opt/SUNWappserver deploy.wsi-sampleapp.webapps If your container is the Web Server, then reconfigure the server to load the deployed sample application cd WS_HOME/https-localhost reconfig 3.2.2 MySQL database MySQL database may be used when Sun Java System Web Server 6.1 or Tomcat is the chosen container. MySQL can be downloaded from http://www.mysql.com/downloads. A standard MySQL installation using the binary distribution is recommended. To set up MySQL for use with the WS-I sample application: Start the MySQL database server On a Unix-like platform Go to MYSQL_HOME directory and invoke the /bin/mysqld_safe script, where MYSQL_HOME is the installation directory of MySQL database. As per MySQL documentation, mysqld_safe is the recommended way to start a mysqld server on Unix and NetWare. Refer to The mysqld_safe Server Startup Script for more details. Note: This script needs to be invoked from MYSQL_HOME and specifying the path as ./bin/mysqld_safe. Make sure that the database server is listening on port 3306. The port number can be found by invoking the ./bin/mysqladmin variables command from MYSQL_HOME directory and looking for the value of port variable. Otherwise you can change the port number by invoking the script as ./bin/mysqld_safe –port=3306 On a windows platform Go to MYSQL_HOME/bin directory and invoke the command mysqld –console. Refer to Installing MYSQL on Windows for more details. Make sure that the database server is listening on port 3306. The port number can be found by invoking the mysqladmin variables command from MYSQL_HOME/bin directory and looking for the value of port variable. Otherwise you can change the port number by specifying port=3306 on a new line in %WINDIR%/my.ini. Create a database On a Unix-line platform Go to MYSQL_HOME directory and invoke the ./bin/mysql script. This script needs to be invoked from MYSQL_HOME and specifying a user name with database creation privilege as ./bin/mysql –user=root. root is a default user with database creation privilege, you may choose an alternate user with similar privilege. If you happen to choose an alternate user, you need to modify JWSDP_HOME/wsi-sampleapp/etc/mysql.db.props file with the correct values for user and password fields. This gives a mysql prompt. At the mysql prompt, enter create database wsi; command and hit Enter Type quit; on the mysql prompt to quit the script On a Windows platform Go to MYSQL_HOME/bin directory and invoke mysql script specifying a user name with database creation privilege as ./bin/mysql –user=root. root is a default user with database creation privilege, you may choose an alternate user with similar privilege. If you happen to choose an alternate user, you need to modify JWSDP_HOME/wsi-sampleapp/etc/mysql.db.props file with the correct values for user and password fields. This gives a mysql prompt. At the mysql prompt, enter create database wsi; command and hit Enter Type quit; on the mysql prompt to quit the script Download the JDBC driver (Connector/J) jar file for MySQL from http://www.mysql.com/downloads/api-jdbc.html. The jar file is typically available in the root of the installation directory of Connector/J. For Sun Java Systems Application Server 8.0 container: Copy the jar file in AS_HOME/domains/domain1/lib/ext directory, if domain1 is the chosen domain. For Sun Java System Web Server 6.1 container Edit the server.xml for the instance chosen during Java WSDP installation. Typically this file will be in https-/config directory where is the name of your server on which Sun Java System Web Server 6.1 is installed (or “localhost”). Search for classpathsuffix attribute. Add the absolute path of the jar file at the end of the value of classpathsuffix attribute. For Tomcat container: Copy the jar file to TOMCAT_HOME/common/lib. Go to the JWSDP_HOME/wsi-sampleapp/src directory and invoke the change-database target as follows ant change-database -Ddatabase=mysql If your container is the Web Server, first undeploy the wsi-server.war. For example: cd WS_HOME/bin/https/bin wdeploy delete -u /wsi-server -i localhost -v https-localhost hard Invoke the deploy.wsi-sampleapp.webapps target on the integration script for your container. JWSDP_HOME/jwsdp-shared/bin/jwsdponsjsas.[sh | bat] for Sun Java System Application Server JWSDP_HOME/jwsdp-shared/bin/jwsdponsjsws.[sh | bat] for Sun Java System Web Server JWSDP_HOME/jwsdp-shared/bin/jwsdpontomcat.[sh | bat] for Tomcat For instance, for Sun Java System Web Server installed in /opt/SUNWwebserver directory, from the JWSDP_HOME/jwsdp-shared/bin/ directory this script is invoked as: jwsdponsjsws.sh /opt/SUNWwebserver deploy.wsi-sampleapp.webapps If your container is the Web Server, then reconfigure the server to load the deployed sample application cd WS_HOME/https-localhost reconfig 3.3 Registry The WS-I sample application has been configured to use the IBM’s public UDDI Business Registry for querying the list of WS-I Sample Application endpoints implemented by all the vendors that have a peer-to-peer relationship with WS-I business entity. If you want to use Microsoft’s public UDDI Business Registry instead, you need to repackage the war file and redeploy the wsi web application as follows: Go to the JWSDP_HOME/wsi-sampleapp/src directory and invoke the change-registry target as follows ant change-registry -Dregistry.server=microsoft If the WS-I sample application has been configured for the Microsoft registry earlier and now needs to be configured with the IBM registry, you need to invoke the change-registry target as follows ant change-registry -Dregistry.server=ibm If the sample application is packaged to use Microsoft’s public UDDI Business Registry, you may have to update the security certificates required by the Microsoft’s registry. Information on how to obtain and install these certificates for a stand-alone client in your JRE is available in the JAXR release notes. If your container is the Web Server, first undeploy the wsi-server.war. For example: cd WS_HOME/bin/https/bin wdeploy delete -u /wsi-server -i localhost -v https-localhost hard Invoke the deploy.wsi-sampleapp.webapps target on the integration script for your container. JWSDP_HOME/jwsdp-shared/bin/jwsdponsjsas.[sh | bat] for Sun Java System Application Server JWSDP_HOME/jwsdp-shared/bin/jwsdponsjsws.[sh | bat] for Sun Java System Web Server JWSDP_HOME/jwsdp-shared/bin/jwsdpontomcat.[sh | bat] for Tomcat For instance, for Sun Java System Web Server installed in /opt/SUNWwebserver directory, from the JWSDP_HOME/jwsdp-shared/bin/ directory this script is invoked as: jwsdponsjsws.sh /opt/SUNWwebserver deploy.wsi-sampleapp.webapps If your container is the Web Server, then reconfigure the server to load the deployed sample application cd WS_HOME/https-localhost reconfig 4.0 Invoking the Services Make sure that the container and the database server configured above are running before invoking any of the services. The chosen database server will be running if you have performed Step 1 in section 3.2.1 or 3.2.2. 4.1 Invoking the Retailer client The Retailer client acts as a consumer of the electronics good and places pre-defined orders (defined in etc/retailer-config.xml) to the Retailer Web Service. The Retailer Web Service then invokes the warehouse and manufacturer Web Services to fulfill the supply chain model defined in section 1.0 above. The orders are defined such that the various combinations of retailer, warehouse and manufacturer are invoked. The set of endpoints is defined in etc/endpoints.props and the combination of endpoints is defined in etc/vendor-config.xml. To invoke the Retailer client: Go to the JWSDP_HOME/wsi-sampleapp directory. Make sure etc/endpoints.props has the correct host and port information (by default localhost:8080). Invoke JWSDP_HOME/wsi-sampleapp/bin/run-retailer.[sh | bat] to invoke the client. This invokes the getCatalog function from the RetailerService and places the various pre-defined orders to the Retailer Web Service. You can view the log entries documenting this activity in JWSDP_HOME/wsi-sampleapp/logs/retailer-results.html. You’ll notice some orders are not satisfied due to insufficient stock; this is intentional. 4.2 Invoking the Configurator client The Configurator client queries a public UDDI Business Registry for the WS-I sample application endpoints implemented by all the vendors which have a peer-to-peer relationship with WS-I business entity and displays them. The WS-I sample application has been configured to use the IBM’s public UDDI Business Registry for querying this list of endpoints. Refer to section 3.3 if you want to use Microsoft’s public UDDI Business Registry instead. To invoke the Configurator (query) client: If not already done, set the http.proxyHost and http.proxyPort properties for your container so it can talk to a UDDI Business Registry outside the firewall. Refer to section 3.1 for container specific configuration. Run JWSDP_HOME/wsi-sampleapp/bin/run-query.[sh | bat]. You can view log entries documenting the query activity in JWSDP_HOME/wsi-sampleapp/logs/query-results.html. You should see entries for vendors such as BEA, Corillian, IBM, Microsoft, Novell, Oracle, Quovadx, SAP, and Sun. The default behavior of run-query.[sh | bat] is to contact the IBM’s public UDDI business registry and generate the endpoints information dynamically. However the Configurator Web Service also maintains all endpoints information in a local cache accessible by specifying the following argument when invoking the script -Dconfigurator.refresh=false Specifying this option will not invoke the public UDDI business registry and instead provides you with endpoints information from the local cache. This cache is also updated every time the UDDI registry is contacted for the list of endpoints. The run-query.[sh | bat] script uses the default Configurator Web Service bundled with Java WSDP. If you need to use another Configurator Web Service, configure server-side logging to at least the CONFIG logging level and run the query script with configurator.refresh=true, which is the default when you invoke the run-query.[sh | bat] script without any arguments. Search server-side logs (server.log on Sun Java System Application Server, errors log on Sun Java System Web Server, launcher.server.log on Tomcat) for CONFIG entries containing the text ” Configurator” and you should see the endpoint address displayed between curly braces. For example: Oracle WS-I Configurator {http://ws-i.oracle.com/ws-i/supplychain/services/Configurator} Add the text between curly braces in etc/endpoints.props in the following format. vendor.configurator=http://ws-i.oracle.com/ws-i/supplychain/services/Configurator where vendor is the name of the vendor and the text between curly braces is copied after the = symbol. To use this Configurator Web Service, invoke the run-query.[sh | bat] with the following argument -Dconfigurator.endpoint= where is replaced by the value of vendor specified in the etc/endpoints.props. Refer to section 6.0 for details on how to configure logging. If both -Dconfigurator.endpoint and -Dconfigurator.refresh options are specified, then endpoints information is retrieved in the following manner: configurator.refresh configurator.endpoint How endpoints are generated true Not specified Configurator Web Service talks to the UDDI registry false Not specified Local cache from the Configurator Web Service true Specified Remote endpoint talks to the UDDI registry false Specified Local cache from the remote endpoint 4.3 Invoking the Catalog client The Catalog client queries the Catalog Web Service which simulates an out-sourced cataloging capability that is used by the Retailer Web Service. It provides operations to access the catalog of products. The Catalog enables a consumer to browse its contents and retrieve additional information about individual items. In a larger context, the products that the consumer orders from the Catalog can be packaged into an order and sent to a Retailer. The set of Catalog endpoints are defined in etc/endpoints.props. To invoke the Catalog client: Make sure etc/endpoints.props has the correct host and port information (typically localhost:8080). Run JWSDP_HOME/wsi-sampleapp/bin/run-catalog.[sh | bat]. This will invoke the getCatalogWithImages and getProductDetails function from the Catalog Web Service. getCatalogWithImages return attachment references of thumbnail images for each product in the catalog. getProductDetails provides additional details about each product, a larger product image, and a product spec sheet. The spec sheet and picture are conveyed as SOAP attachments. The default behavior of run-catalog.[sh | bat] is to invoke getCatalogWithImages and getProductDetails for each product in the Catalog. If you need to invoke only getCatalogWithImages, specify the following argument when invoking the script -Dcatalog.level=thumbnail If you need to invoke only getProductDetails, specify the following argument when invoking the script -Dcatalog.level=details run-catalog.[sh | bat] uses the default Catalog Web Service bundled with Java WSDP. To use another Catalog Web Service, add the endpoint in etc/endpoints.props in the form vendor.catalog=ENDPOINT_ADDRESS where ENDPOINT_ADDRESS specifies the location of the new Catalog Web Service and “vendor” can be replaced by the name of the Web Service provider. Then the new Catalog Web Service can be used by specifying the following argument when invoking the script -Dcatalog.endpoint=vendor where vendor needs to match the “vendor” string specified in JWSDP_HOME/wsi-sampleapp/etc/endpoints.props. 5.0 Building from the source If HTTP proxy host and port are not configured during Java WSDP installation, configure the http.proxyHost and http.proxyPort properties in JWSDP_HOME/conf/jwsdp.properties before building from the source. You should use the ant bundled with Java WSDP because it has the required libraries in the classpath. Client Go to src directory and invoke ant client command. This will overwrite the existing wsi-client.jar in JWSDP_HOME/wsi-sampleapp/lib directory. Follow the instructions in 4.0 to run the client. Server Go to src directory and invoke ant server command. This will overwrite the existing wsi-server.war in JWSDP_HOME/wsi-sampleapp directory. Note: By default, the Pointbase database configuration file is bundled in the WAR file. If MySQL database configuration file needs to be bundled instead, add -Ddatabase=mysql property when invoking the ant target. If your container is the Web Server, first undeploy the wsi-server.war. For example: cd WS_HOME/bin/https/bin wdeploy delete -u /wsi-server -i localhost -v https-localhost hard Invoke deploy.wsi-sampleapp.webapps target on the integration script for your container. JWSDP_HOME/jwsdp-shared/bin/jwsdponsjsas.[sh | bat] for Sun Java System Application Server JWSDP_HOME/jwsdp-shared/bin/jwsdponsjsws.[sh | bat] for Sun Java System Web Server JWSDP_HOME/jwsdp-shared/bin/jwsdpontomcat.[sh | bat] for Tomcat For instance, for Tomcat for Java WSDP installed in /opt/tomcat-jwsdp directory, from the JWSDP_HOME/jwsdp-shared/bin/ directory, this script is invoked as: jwsdpontomcat.sh /opt/tomcat-jwsdp deploy.wsi-sampleapp.webapps If your container is the Web Server, then reconfigure the server to load the deployed sample application cd WS_HOME/https-localhost reconfig 6.0 Configuring Logging The Java WSDP supports the Java Logging API [9]. By default, the WS-I sample application in the Java WSDP has its logging level set to “INFO”. The following levels are available, in ascending order of granularity and are used in the application as shown below. Logging Level Usage SEVERE Server-side or client-side exception WARNING Non-blocking error conditions INFO (default) Basic flow of application CONFIG Logging entries from the LoggingFacility FINE SOAP request and response messages FINER Entry and exit points of primary methods FINEST Display intermediate steps from the primary methods, if any To change the default logging level (INFO) on server-side and client-side to a different level: Edit JAVA_HOME/jre/lib/logging.properties file. Add the following on a new line com.sun.wsi.scm.level=LEVEL where LEVEL is one of the seven logging levels mentioned above. Set the default logging level and logging level for ConsoleHandler to the new level as .level=LEVEL java.util.logging.ConsoleHandler.level=LEVEL Note: You may need to either edit or add these lines depending upon your specific logging.properties file. Restart the container and re-run the client. For Sun Java System Web Server Edit the https-localhost/config/server.xml. Change the level attribute of LOG element to FINE, FINER or FINEST to see more detailed log entries on the server side. 7.0 Troubleshooting Check that all the container- and database-specific pre-requisites are met. Check all the endpoints are configured in etc/endpoints.props file. The default endpoints are configured for host “localhost” and port “8080”. If your application is deployed at a different host and/or port, then ensure that these are reflected correctly in the etc/endpoints.props file. Make sure the database server is started and database is created before run-retailer script is invoked. If the database is started or created after the script is invoked, you need to restart the container. Make sure the database is running on the correct host and port and the appropriate database has already been created. Refer to section 3.2 for more details. Database related properties are stored in JWSDP_HOME/wsi-sampleapp/etc/[mysql | pointbase].props. If you need to modify any of the database configuration properties, edit the .props file specific to your database and invoke ant change-database -Ddatabase=[pointbase | mysql] target from the JWSDP_HOME/wsi-sampleapp/src directory. And then invoke the deploy.wsi-sampleapp.webapps target on the integration script for your container. Note: for Web Sever you should undeploy the wsi-server.war first using the command: wdeploy delete -u /wsi-server -i localhost -v https-localhost deploy the application and then reconfigure the server to load the deployed sample application using the command: cd WS_HOME/https-localhost reconfig If any of the sample app endpoints are outside a firewall, you need to specify http.proxyHost and http.proxyPort properties in JWSDP_HOME/conf/jwsdp.properties to specify the system on your network through which you access the Internet. You can specify sample app endpoints from other vendors in the etc/endpoints.props file and create different configurations, comprising of endpoints from different vendors, in etc/vendor-config.xml. Each of these configurations will be used to place the orders specified in etc/retailer-config.xml. However if your endpoints are deployed inside a firewall, then only Retailer Web Service hosted within the firewall can be mixed with the other endpoints installed outside the firewall. To view the SOAP request and response messages, turn the logging level to FINE and restart the container. Refer to section 6.0 on how to configure logging. SOAP request and response messages are available for Retailer, Logging, Configurator and Catalog clients as given below: Retailer client SOAP request and response messages are available in the logs/retailer-soap-messages.txt. Logging client SOAP request and response messages are available in the logs/logging-soap-messages.txt. This log is created when you run the run-retailer.[sh | bat] script. Configurator client SOAP request and response messages are available in the logs/configurator-soap-messages.txt. Catalog client SOAP request and response messages are available in the logs/catalog-soap-messages.txt. These messages can be viewed in a text editor such as vi on Unix or Wordpad on Windows. They contain base-64 encoding which cannot be handled by some text processing tools. Server-side log messages are available in the corresponding logs directory of your container. If your container is Tomcat, you invoked run-query script and a java.lang.NullPointerException with the stack trace as given below is received on the client side: java.util.logging.ErrorManager: 5 java.lang.NullPointerException at java.util.PropertyResourceBundle.handleGetObject(PropertyResourceBundle.java:103) Then it’s likely that unpackWARs attribute is not set correctly in the Tomcat configuration files. Refer to section 3.1.3 to set the attribute correctly. 8.0 References WS-I Supply Chain Management Sample Application 1.0 Use Case Model Use Cases for Attachments Sample Applications 1.0 (not publicly available yet) Supply Chain Management Sample Application 1.0 Architecture Technical Architecture for Attachments Sample Applications 1.0 (not publicly available yet) Basic Profile 1.1 Simple SOAP Binding Profile 1.0 Attachments Profile 1.0 Java Logging APIs

About eagle081183

Passionate, Loyal
This entry was posted in Problem solving, Software architecture. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s