Publishing, Consuming, Deploying and Testing Web Services

Transcription

1 Publishing, Consuming, Deploying and Testing Web Services Oracle JDeveloper 10g Preview Technologies used: Web Services - UML Java Class Diagram An Oracle JDeveloper Tutorial September 2003 Content Introduction Create the Java Class to be Published as a Web Service Publish the Person Java Class as a Web Service Consume and Test the Web Service in the Embedded OC4J Server Test the Web Service at the Network Packet Level Using the TCP Packet Monitor Introduction This how to describes the steps to visually develop a J2EE web service based on a Java class, using the UML Java Class diagrammer. You test the service by running it in the embedded OC4J application server and generate a client stub to call it, all directly from the Java Class diagram. The how to then moves on to describe how you can test your web services at the network packet level using TCP Packet Monitor to test your web service SOAP requests and responses. Create the Java Class to be Published as a Web Service Create a New Java Class Diagram Create a new Application Workspace (File -> New) Name the Application JavaWebService Select the Application Template Web Application [JSP, Struts, EJB] Click Edit Templates Select Data Model project under the Web Application [JSP, Struts, EJB] template Scroll down the available technologies list until you see Web Services Select it and move it to the Selected Technologies list This will make the web services technology available in your project technology scope. You can use this template at any time to add additional technologies to a project. Repeat for UML Click OK to close the dialog Click OK to create the application In the Application Navigator, select the project Model Context menu: New... General -> Diagram : Java Class Diagram Click OK to create a default empty Java class diagram The diagram modeler window is open and empty Create a Java Class Select the Component Palette of the Java diagram Select Java Class from the palette Move to the diagram and click to create a class in the empty diagram The default name is highlighted. Overtype this with Person to change the name of the new class

2 In the Application Navigator, note that Person.java has been generated. Figure above also shows the Person class with attribute and methods that you will add in the next few steps. Once generated, the modeled class and the generated Java code are synchronized and the modeled class and Java class cannot be unsynchronized. Any change you make in the model will be reflected in the generated code and vice-versa. Click in the first empty box in the class to add an attribute using in-place editing Overtype the highlighted attribute placeholder with: + name Press <enter> Note that the type of the attribute has defaulted to String Click in the next box to add a method. Overtype the placeholder method signature with the method listed below then press <enter> + sayhello(string p0):string The class shape will expand and present you with a placeholder signature for a second method Overtype the new method signature with the method below. + saygoodbye():string Click the edge of the class shape to select the class. Drag it to resize as required Double-click on the shape to open the Code Editor Add implementation code to the generated stub methods public String sayhello(string p0) name = p0; return "Hello, " + p0; public String saygoodbye() return "That's all Folks, Goodbye " + name; Context menu: Make Person.java Close the code editor to return to the class diagram. Alternatively select the class diagram from the Document Bar Add a Complex Type (JavaBean) Parameter to the Class In the Application Navigator double-click Model project node to open the Project Properties Select Technology Scope Move JavaBeans to the Selected Technologies and click OK On the Model node File -> New -> JavaBeans -> Bean Give the bean the name Address Select java.lang.object from the Extends list Click OK to create the bean Address.java opens in the Editor Select the Class tab from the bottom of the editor Select the Fields tab (at the bottom) Click Add to add the following fields (see below) town country Accept the other default properties of each field

3 In the Navigator select Model.jpr Context menu: Rebuild Model.jpr Add JavaBean to the Class Diagram Click the JavaClassDiagram1 tab at the top of the editor to bring it to the front Drag Address.java from the Application Navigator onto the class diagram A new UML shape for the Address class is added to the diagram Return to the Person class in the class diagram Add the following public methods + setaddress(string town, String country):void + convertaddress():void + getaddress():address Add the private variable m_address - m_address:address note that an association is automatically drawn between Person and Address as a result of this Double-click Person class again Amend the class to change the implementation code as follows: private Address m_address = new Address(); public void setaddress (String town, String country) m_address.settown(town); m_address.setcountry(country); public void convertaddress() m_address.settown("the town is " + m_address.gettown()); m_address.setcountry("the country is " + m_address.getcountry()); public Address getaddress() return m_address;

4 Publish the Person Java Class as a Web Service Select Person in the diagram Context menu: Generate -> Web Service. This launches the Web Services Publishing Wizard You can also invoke this wizard through the Object Gallery (File -> New) Step 1: Accept the default name and package Step 2: Click Select All to expose all the public methods in the class in the web service Step 3: Accept the defaults and Finish the wizard The web service MyPersonWS is created and displayed in the Class diagram In the Application Navigator, select MyPersonWS Note that a WSDL document and an interface IPerson.java have been created and are listed in the structure pane. The interface is used by the application server at runtime Double-click IMyPersonWS.wsdl to open it in a code editor The structure window now shows the structure of the WSDL file. XML Structure definitions porttype operation The porttype defines the collection of functions (the operations) that are accessible via the web service Double-click name=sayhello to open the WSDL document at this parameter in the code editor Browse the WSDL file either using the editor or the structure pane Close the WSDL file (do not make any changes to it!) Consume and Test the Web Service in the Embedded OC4J Server Stop any running embedded OC4J instance: Run -> Terminate -> Embedded OC4J Server Select MyPersonWS in the Java class diagram Context menu: Run Embedded Server This starts the embedded OC4J and 'deploys' the web service to it. When the deployment is finished you will see the following message in the log window. Select mypersonws in the Java Class diagram Context menu: Generate -> Sample Java Client This generates a sample Java client called EmbeddedMyPersonWSStub to connect to the web service running in the embedded OC4J server. It contains a main method for testing the call and response from the web service. The other menu option under Generate generates a client stub to call the web service from its deployed application server (taken from the WSDL file). You can also use this stub to test the deployed web service - by adding your own main method to it or instantiating it in your application

5 The stub EmbeddedMyPersonWSStub is added to the Java Class diagram and opened in the open code editor. Browse down past the main method and notice that the endpoint has defaulted to the local machine and the port that the embedded OC4J is using (normally 8988) Add the following lines of code in the main method under the commented out line //Add your own code here System.out.println(stub.sayHello("WS Developer")); stub.setaddress("reading","uk"); stub.convertaddress(); System.out.println(stub.getAddress().getTown()); System.out.println(stub.sayGoodbye()); In code editor, Context menu: Run EmbeddedMyPersonStub.java The reply from the web service is displayed in the log window (see below) Test the Web Service at the Network Packet Level Using the TCP Packet Monitor The TCP packet monitor allows you to monitor and test web services at the network packet level. The HTTP requests and responses are captured and output to the monitor. Once activated, the TCP Packet Monitor reroutes calls to a web service via an intermediate port. You can use the TCP Packet Monitor whether you are using a proxy server or not. Whichever is the case, the packet monitor will create appropriate 'dummy' ports. Menu Tools -> Preferences Select Web Browser/Proxy Note the port number of the HTTP Proxy Server Click Cancel to close Preferences dialog Menu View -> TCP Packet Monitor to invoke the TCP Packet Monitor Start the TCP Packet Monitor by clicking the green start icon (top left of monitor window) Menu Tools -> Preferences Select Web Browser/Proxy Note that the port number of the HTTP Proxy Server has changed Cancel the Preferences dialog By default the monitor appears in the bottom right of the IDE. Hold down the Control Key and drag the TCP monitor to the middle of the IDE. Expand it as shown in below

6 Select the EmbeddedMyPersonStub.java in the navigator Click the Run icon in the toolbar to run the stub Note that as well as the expected return from the web service in the log window there are 5 entries in the History tab of the monitor - one for each call to the web service in the stub. The calls to the web service are: System.out.println(stub.sayHello("WS Developer")); stub.setaddress("reading","uk"); stub.convertaddress(); System.out.println(stub.getAddress().getTown()); System.out.println(stub.sayGoodbye()); Highlight the first entry in the History tab of the TCP Packet Monitor and either double-click it or select the data tab Select the Switch Layout icon (5th from left) to display the request window above the response window Note that the top of the request window shows the http post to the embedded server (port 8988) Scroll to the bottom of the request window to show the call sayhello and the parameter being passed (See below): <SOAP-ENV:Body> <ns1:sayhello xmlns:ns1="mypersonws" SOAP- ENV:encodingStyle=" <p0 xsi:type="xsd:string">ws Developer</p0> </ns1:sayhello> </SOAP-ENV:Body> Move to the response window shows the String returned (See Figure 6) <SOAP-ENV:Body> <ns1:sayhelloresponse xmlns:ns1="mypersonws" SOAP- ENV:encodingStyle=" <return xsi:type="xsd:string">hello, WS Developer</return> </ns1:sayhelloresponse> </SOAP-ENV:Body>

7 In the request window change the p0 parameter value to My Name One powerful way to use the TCP Packet Monitor to test your web services is by changing parameter values using the TCP Packet Monitor and resending the request. This can be helpful when the SOAP packet is not returning the response you expected. If you have have a complicated client that would take time to re-write this is another way of quickly testing the expected parameters sent and received Click the icon Resend Request (left hand icon) Return to the History Tab. Highlight the new entry (the sixth entry in the window) and return to the Data Tab See the new parameter that was passed in the request window Scroll to the bottom of the response window to see the returned greeting Click the Stop icon (red) to stop the TCP Packet Monitor Close the TCP Packet Monitor window