This topic provides information you may need for versioning web services created in WebLogic Workshop in such a way that they will continue to support clients without disruption.
There are two areas to consider in regard to versioning a web service:
You can add new operations to the public interface of a web service, but you cannot change or remove existing operations without potentially disrupting clients that rely on the web service. By adding new operations and making them known to clients, you can gradually shift clients over to a new set of operations, but you should leave the original operations intact for backward compatibility.
WebLogic Workshop uses Java serialization to persist the state associated with web service requests and conversations. For this reason, the primary requirement for supporting versioned implementations is maintaining backward serialization compatibility. Specifically, it must be possible to load state into the current version of a class that was stored using any prior versions of that class. Compatible changes are described in the Java Serialization Specification and include (but are not limited to):
Types of changes that are not version compatible include (but are not limited to):
You should avoid making these kinds of changes if you want to maintain backward compatibility.
This model is known as "hot fix" versioning because while there can be multiple prior versions of an implementation, there can only be one current version of an implementation. Deploying an updated version of a class creates the new current version. At that point, all conversational instances that receive requests for that service will use the current version, regardless of which version was used to process any prior requests.
Web services created in WebLogic Workshop include a default field, serialVersionUID, for tracking binary compatiblity between web service versions. This value remains constant as long as subsequent revisions of the web service maintain binary compatibility. This value is used by the Java virtual machine, and you should not modify it. Should WebLogic Workshop detect that a class does not have a serialVersionUID field but is being serialized as part of a request to a web service or conversation state, WebLogic Workshop generates a warning message.
None.