Interoperability

[Bouche Paul <Pa...@student.hpi.uni-potsdam.de>]

I have been reading the recent discussions about interoperability esp. with .NET sending arrays, using WSDL and so forth and the suggested method was to write interfaces use java2wsdl to get a starting wsdl then edit it and generate the actually service stubs and skeletons with wsdl2java.

Now a rather personal statement:
I personally think, (if you are not interested in my opinion quit reading please) that when we have to "hack" WSDL in order to get interoperability then something is wrong because the level of automation is very low and also to "hack" WSDL in order to ciruumvent some bugs in the platforms is not an acceptable solution.  Can anyone comment on this.

Paul

.

Axis & WSS4J

[Greg Michalopoulos <gm...@d2hawkeye.com>]

Anyone using axis with wss4j?  I have successfully implemented
UsernameToken, but would like to use encryption and signature.  Apache docs
are pretty limited.  Any help or references would be greatly appreciated.

Thanks,
Greg

Re: Interoperability

[Jim Murphy <jm...@mindreef.com>]

Bouche Paul wrote:

...portions elided...

> I personally think, ... that when we have to "hack" WSDL in order to get interoperability then something is wrong 

I understand this point of view and how you feel that the suggested 
method of generating a WSDL with a tool and then manually modifying 
parts to make it interoperable implies a broken tool.  That may be.

I believe the *real* proposed solution is to consider your WSDL contract 
as a first class artifact of you web service instead of an afterthought. 
  WSDL is the IDL of your service and if that means something to you you 
are probably familiar with the fact that "ContractFirst" isn't new.

As a practical matter WSDL 1.1 can be somewhat unapproachable - too many 
angle brackets, too much cryptic syntax or funky/non-obvious semantics, 
I don't know.     Whatever it is it makes most people NOT look forward 
to authoring it.  To me this is tremendously unfortunate since plenty of 
people consider writing IDL first obvious and necessary.  This is how we 
get to the "generate a WSDL to start with" philosophy.  Once you have 
the boilerplate parts and a rough outline of the types you need you can 
then tweak the non-interoperable parts to get a nice clean WSDL.

Does this mean Java2WSDL is broken?  Maybe, but to my way of thinking 
about it I wouldn't expect such a tool to exist in the first place. :-) 
  Although I have to admit the idea is seductive.

The type contract that is the basis for your service should be authored 
in the XML type system not in the java type system - thats the 
fundamental problem.  As we continue to insist on mapping everyone else 
world to our own we will continue to have interop problems.  To be fair 
much of the the deep thinking has been done here and the 
non-interoperable parts are due in large part to (pervasive) legacy 
toolkits that are based on deprecated technology and of course plain old 
bugs.

Some people suspect a somewhat dark angle here too.  That platform 
vendors are dis-incented to make their toolkits *really* interop so if 
you end up making a service using toolkit A the "best" consumer is a 
client using toolkit A as well.  This is really unfortunate in as far as 
it happens but in my experience this hasn't been the case.  In fact, 
without naming names, those that you think would pull these sort of 
stunts have been most interested in interop - from the start.


(Opening can labeled "Worms")

There are other problems with ignoring WSDL as well - like versioning. 
If your WSDL is being generated from you Java classes dynamically will 
you know when your contract changes?  Will you know what parts of your 
contract change and whether older style messages are still safe to 
process?


Jim Murphy
Mindreef, Inc.