 |
WSRP v2 implementation Architectural Note :
The following section address the architectural changes in the OpenPortal? WSRP Project w.r.t to version 2.0 implementation. These changes are added to support the version 2 implemention over the existing v1 implementation.
A. Problem Statement :
The WSRP version 2.0 Protocol is not over the wire backward compatible with version 1.0 protocol, even though the v2 is a logical extension to the v1 specification. The WSRP v2 specification addresses backward compatibility by exporting a v1 service in addition to the v2 service. The v1 consumer is expected to use the v1 service while the v2 consumer would use the v2 service, however the WSRP specification optionally provides support where a WSRP resource ( like registration handle, portlet handle) may be supported across these services provided a WSRP producer implements this.
To to put this in simple words, a v1 consumer may have created a registration or a portlet, the producer may optionally allow a v2 consumer to use the same registration and portlet, by allowing this, it has facilitated migration of data from v1 consumer to a v2 consumer. ( somewhat similar to data migration on moving from v1 to v2 ).
This design note address the following issues
- Design changes to support both v1 and v2 version WSRP Protocol on the Producer and the Consumer end.
B. WSRP Producer Design note :
The WSRP Producer implementation in OpenPortal? WSRP project exports a WSDL that has both v1 and v2 service defined in the same WSDL. The Producer implementation will allow a v1 consumer to upgrade to a v2 consumer as explained above apart from supporting both v1 and v2 version of the specification
The v2 port type implementations are added to the existing v1 port type implementations, This means that the WSRP implementation installs or configures the JAX-WS to have the following port types.
- version 1.0
- V1_Registration_PortType
- V1_ServiceDescription_PortType
- V1_Markup_PortType
- V1_PortletManagement_PortType
- version 2.0
- V2_Registration_PortType
- V2_ServiceDescription_PortType
- V2_Markup_PortType
- V2_PortletManagement_PortType
The V1 Port types are used by V1 Consumer, while the V2 Port types are used by V2 Consumer.
Apart from the addition of the above port-types, the following optimization is done at the producer end to maintain a single code base for supporting both v1 and v2 implementations rather than having 2 separate implementations.
1. Added a utility class called WSRPStubVersionConvertor?.java -- This converts v1 schema objects to v2 and vice versa
2. All the implementation classes at the WSRP Producer end are migrated to use v2 schema generated classes
3. When a v1 request is received the v1 port-type implementation uses the stub convertor to convert v1 classes to v2.
4. It then invokes the implementation classes.
5. Does the vice-versa for the response that goes out (i.e convert v2 response to v1 and send it to the consumer )
The following sequence diagram shows the implementation for registration port type at the producer end.
C. WSRP Consumer Design note :
The WSRP Consumer is a implementation of the container API, Now since there are 2 version of the WSRP Protocol which use different datatypes the WSRP Consumer provides two implementation of the Container namely
- WSRPV1Container?
- WSRPV2Container?
Apart from the above container implementations the WSRP also provides a additional container called the WSRPContainer.
WSRPContainer :
The WSRPContainer is a composite container , The WSRP Container abstracts the clients (portal or driver) of WSRP from having to know that there exists 2 container implementation and they need to delegate calls to these respective containers based on the protocol version.
The WSRP Container contains references to V1 and V2 Container implementations, It automatically delegates requests to either of the container by checking the WSRP Protocol version. This also means that there is no code change required from the existing clients of WSRP to migrate or use the WSRP v2 and WSRP v1 implementations.
The following diagram shows the architectural change in the WSRP Consumer implementation.
Note : The WSRPContainer has references to 2 Container implementation namely v1 and v2.
D. Open Issues :
The WSRP v1 schema and the v2 schema's use the same name for the data types it defines. These datatypes belong to 2 different namespaces to avoid name collision. However there is a issue with JAXWS compiler that prevents us from using custom bindings to generate classes of type say -- All v1 classes are prefixed with the string "V1" and all v1 classes are prefixed with the string "V2".
We have created the following CR on JAX-WS Project, Need to follow with JAXB team on usage of episode option to fix this issue if possible. Here is the link to the CR 468 - wsimport jax-ws customization with multiple wsdl's
Right now because of this issue the generate code has 2 classes with same name in different packages, Say for eg:
- com.sun.portal.wsrp.common.stubs.NamedStrings,java and
- com.sun.portal.wsrp.common.stubs.v2.NamedStrings,java
Any implementation code that refers to both the above classes need to refer them using the complete package name.
This is a known issue we are working with the JAX-WS and JAXB team to resolve this asap.
-- Main.t_rajesh - 10 Dec 2007
|