File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
The moose likes Web Services and the fly likes Is DII the best way to go? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Web Services
Bookmark "Is DII the best way to go?" Watch "Is DII the best way to go?" New topic

Is DII the best way to go?

Doug Svacina

Joined: Nov 06, 2007
Posts: 1
We are trying to create a webservice that will be used by a few different applications across the company. Sounds easy enough, but the problem that we are going to run into is that we want to keep the webservice as seperate as possible from the applications. For example, if we have to make changes to the webservice, we don't want to have to redeploy each application with the new client jar file at the same time to accommodate those changes. Is there a way to do this?

I've been playing with Dynamic Invocation Interface and it seems to do what I need it to in the redeploying aspect, but it only handles simple datatypes, not custom objects. Is there any way around this? Does any one have any different ideas?

Thanks in advance,

Peer Reynders

Joined: Aug 19, 2005
Posts: 2933
Welcome to JavaRanch.

I don't see how DII solves your deployment problem.
Do you plan on developing an autonomously reasoning web service client interface?

You can change the service implementation all you want - the clients don't have to change as long as the interface and the established pre- and post conditions don't change. If you change the service contract your clients will have to change.

Theoretically there is some leeway if you design the XML Schema that your web service contract is based on with extension in mind. However in some cases you would have to make assumptions about how the clients operate - you'll only be able to sneak in a new optional element inside an existing XML document if the client doesn't keep a (obsolete) local copy of the schema for validation and if the XML (un)marshalling code will simply ignore unrecognized elements. In general it is not a good idea to make these kinds of assumptions.

Bottom line: If you don't want to affect existing clients then you cannot change the interfaces (web service contracts) that those clients are using.

However business needs change and new clients with new requirements emerge and the system needs to adapt. To begin with it is always a good idea to separate the service implementation from the web service interface. The service may consume and produce XML documents but it may not be necessary for it to know anything about SOAP.

Once new requirements result in a new interface design, modify the service to satisfy the new requirements and deploy a new web service interface at a new endpoint (and URL) so that new clients can access the new interface and its functionality. In order to relieve the service of the burden of maintaining multiple sets of document standards, insert a transformation stage between the old web service interface and the new service implementation. The transformation stage is basically an anticorruption layer for the service implementation. The transformation stage usually uses XSLT to transform old style request payloads to new style request payloads and new style response payloads to old style response payloads.

When an existing client wants to use the new features it has to be changed anyway - so it will have to start using the new web service interface.
I agree. Here's the link:
subject: Is DII the best way to go?
It's not a secret anymore!