I my last post i looked at the SOAP on he wire between the WSRP4J producer and proxy portlet. After that I wanted to try it out for my self by writing a simple consumer (client) using axis2. I should be very simple since the standard contains the webservice interface (WSDL) which i nicely decomposed into seperate files for:
the service definitions are like
<?xml version="1.0" encoding="UTF-8"?>
<wsdl:definitions targetNamespace="urn:oasis:names:tc:wsrp:v1:wsdl"
xmlns:bind="urn:oasis:names:tc:wsrp:v1:bind"
xmlns="http://schemas.xmlsoap.org/wsdl/"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/">
<import namespace="urn:oasis:names:tc:wsrp:v1:bind"
location="wsrp_v1_bindings.wsdl"/>
<wsdl:service name="WSRPService">
<wsdl:port binding="bind:WSRP_v1_Markup_Binding_SOAP" name="WSRPBaseService">
<soap:address location="http://my.service:8080/WSRPService"/>
</wsdl:port>
<wsdl:port binding="bind:WSRP_v1_ServiceDescription_Binding_SOAP" name="WSRPServiceDescriptionService">
<soap:address location="http://my.service:8080/WSRPService"/>
</wsdl:port>
<wsdl:port binding="bind:WSRP_v1_Registration_Binding_SOAP" name="WSRPRegistrationService">
<soap:address location="http://my.service:8080/WSRPService"/>
</wsdl:port>
<wsdl:port binding="bind:WSRP_v1_PortletManagement_Binding_SOAP" name="WSRPPortletManagementService">
<soap:address location="http://my.service:8080/WSRPService"/>
</wsdl:port>
</wsdl:service>
</wsdl:definitions>
I first first tried to change the endpoints and run i through the Axis2 Codegen, but I only generates the Markup Binding, that is the others are generated by the can't overwrite it. I've therefore changed it to:
<?xml version="1.0" encoding="UTF-8"?>
<wsdl:definitions
targetNamespace="urn:oasis:names:tc:wsrp:v1:wsdl"
xmlns:bind="urn:oasis:names:tc:wsrp:v1:bind"
xmlns="http://schemas.xmlsoap.org/wsdl/"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/">
<import
namespace="urn:oasis:names:tc:wsrp:v1:bind"
location="wsrp_v1_bindings.wsdl" />
<wsdl:service name="WSRPBaseService">
<wsdl:port
binding="bind:WSRP_v1_Markup_Binding_SOAP"
name="WSRPBaseService">
<soap:address location="http://localhost:8080/wsrp4j-producer/services/WSRPBaseService" />
</wsdl:port>
</wsdl:service>
<wsdl:service name="WSRPServiceDescriptionService">
<wsdl:port
binding="bind:WSRP_v1_ServiceDescription_Binding_SOAP"
name="WSRPServiceDescriptionService">
<soap:address location="http://localhost:8080/wsrp4j-producer/services/WSRPServiceDescriptionService" />
</wsdl:port>
</wsdl:service>
<wsdl:service name="WSRPRegistrationService">
<wsdl:port
binding="bind:WSRP_v1_Registration_Binding_SOAP"
name="WSRPRegistrationService">
<soap:address location="http://localhost:8080/wsrp4j-producer/services/WSRPRegistrationService" />
</wsdl:port>
</wsdl:service>
<wsdl:service name="WSRPPortletManagementService">
<wsdl:port
binding="bind:WSRP_v1_PortletManagement_Binding_SOAP"
name="WSRPPortletManagementService">
<soap:address location="http://localhost:8080/wsrp4j-producer/services/WSRPPortletManagementService" />
</wsdl:port>
</wsdl:service>
</wsdl:definitions>
So I've changed the ports to each have their own service (and runs Codegen four times, for each service name (@name). This works allright for me except that's I using four services instead of one, which does take an extra effort for ex. session handling that could have been clean out of the Axis2 box (dist).
This is an example of the flexibility of WSDL, that seemingly the same can be done i several ways, even though I'm not sure what the semantic differences are.
The W3C Note for WSDL 1.1 says the following about services:
A service groups a set of related ports together, and that ports within a service have the following relationship:
- None of the ports communicate with each other (e.g. the output of one port is not the input of another).
- If a service has several ports that share a port type, but employ different bindings or addresses, the ports are alternatives. Each port provides semantically equivalent behavior (within the transport and message format limitations imposed by each binding). This allows a consumer of a WSDL document to choose particular port(s) to communicate with based on some criteria (protocol, distance, etc.).
- By examining it's ports, we can determine a service's port types. This allows a consumer of a WSDL document to determine if it wishes to communicate to a particular service based whether or not it supports several port types. This is useful if there is some implied relationship between the operations of the port types, and that the entire set of port types must be present in order to accomplish a particular task.
Maybe the last bullet does imply that what I'm doing is not what should be done if I exposed it, but since I'm only consuming at therefore use to generate my stubs it doesn't really matter.
1 comments :
In your first services.wsdl you have specified multiple ports with multiple port types. Here you basically talking about four services. So I belive your latter change is more meaningfull.
I recently added the multiport and multiservice support to axis2 (please try with an nightly build). In there it generates the code for multiple ports only if they refer to same port type.
Post a Comment