in this case the wsdl is generated from a interface - (I checked the properties file..) ie: in the first target fullclassname is the interface - but now I do realise that this only referes to the class whoose methods are exposed by a web service, not the data objects.... (ahmm -oops) nonetheless I think it would be interesting to try and return interfaces from the method instead of concrete objects. - and see what happens. Sorry about that ! ( maybe its helps nonetheless?) C
<target name="gen-wsdl" depends="compile">
<echo message="Running Java2WSDL Emitter" />
<path id="build.path">
<pathelement location="${build}" />
</path>
<!-- Java to WSDL -->
<axis-java2wsdl
className="${fullclassname}"
exclude=""
extraclasses=""
location="${webservice.host}:${webservice.port}/${project.name}/services/${project.interfaceName}"
namespace="urn:${project.urn}"
output="${wsdlUrl}"
style="DOCUMENT"
typemappingversion="1.2"
useinheritedmethods="false">
<classpath refid=" compile.classpath" />
<!-- build.path -->
<mapping namespace="urn:${project.urn}" package="${project.package}" />
</axis-java2wsdl>
</target>
<!-- Generate WSDL -->
<target name="export-java" depends="gen-wsdl">
<axis-wsdl2java
output="${generated}"
serverside="true"
skeletondeploy="true"
url=""> verbose="true"
debug="true"
testcase="true"
all="true"
helpergen="true"
nowrapped="true"
printstacktraceonfailure="true"
wraparrays="false">
</axis-wsdl2java>
On 9/12/06, [EMAIL PROTECTED] <
[EMAIL PROTECTED]> wrote:
How do you declare the interfaces rather than the actual data objects when creating the WSDL?
I agree that interfaces are one way to do it, and JAXB 1.6 for instance generates dto's which implement classes. It is a pity that you have to adulterate your dto's with interfaces though - don't really want to change my dto's because of the communications infrastructure, though I suppose you have to do that in any case :-(
Should look at how xfire/axis2 do it.
thanks
Java Developer
"Carl Woermann" <[EMAIL PROTECTED]>
Sent by: [email protected]2006/09/12 11:05 AM
[email protected]
[email protected] [CTJUG Forum] Re: Web services, schemas and dto's
Hi - I think one way to get around this is by declaring the interfaces rather than the actual data objects when creating the WSDL - that way your implementation and the objects returned by the web service only expose that interface methods to you-- and only when cast to the web services implementation will show the messy guts.. I think Crossfire (xFire)and Axis2 go a some way to tidy up the irritation - (not sure but guess that proxy objects get used..) !
Also keeping to standard mapping and away from any fancy (other than arrayList) collection will make life a lot easier. (If you need a map then just write the code that generates it on the client form a list or array..) C.
On 9/12/06, [EMAIL PROTECTED] <[EMAIL PROTECTED] > wrote:
Recently I joined a project where web services is the de facto means of communication.
When building web services, the best practice approach is to build the wsdl, and then generate the pojo or session bean skeleton from that. If you require complex objects to be exchanged, then you also need to provide an xsd schema which will define the protocol.
Data objects are generated from the schema. I assume this is a standard practice accross all web service platforms? I know websphere does this.
The problem with this is that typically you already have those same data objects in your code base. So what do you do? Ideally you don't actually want this duplication, but is there an alternative?
One solution is to make a generic mechanism to simply copy between your written data objects and the generated data objects (from the schema).
Another possibility is to refactor your code to use these new generated objects - typically they're not very "nice" however - websphere generates arrays when there are unbounded properties. If you move these new dto's around you'll also need to move the code to marshal and unmarshal, adulterating the code base a little.
Allowing the user to create their own mappings between their data objects and the schema (reusing their data objects), is probably not the way they'll go because then there's no guarantees that the mapping is correct.
Any ideas on this issue?
Michael Wiles
Disclaimer
Sanlam Life Insurance Limited Reg no 1998/021121/06 - Licensed Financial Services Provider
Disclaimer and Directors
Disclaimer
Sanlam Life Insurance Limited Reg no 1998/021121/06 - Licensed Financial Services Provider
Disclaimer and Directors
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "CTJUG Forum" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/CTJUG-Forum
For the ctjug home page see http://www.ctjug.org.za
-~----------~----~----~----~------~----~------~--~---
