I am working for a web service project that is generated with Java and XML based architecture. The Operations are create / update / retrieve of some business documents in the workflow. The requests are very complex and are supported by complicated schemas.
We need to share the web service to other teams in the organization. I am using Soapui tool to generate the sample XML (create / update / retrieve request xmls). Due to the complicated schema and so many number of parameters possible in the request, the generated XML files are also becoming huge and I have to physically remove a lot of tags and filling up the others with request data to make those valid requests.
I really need to know whether this is a common practise or do we need to provide a SoapUI project containing some sample XML requests. I really want to know what do people do generally in these kind of cases.
If required please let me know and I can provide the XMLs being generated and the XSDs refered at. They are huge in volume...thats the reason I was trying to bypass them.
Is sounds like your SOA contract (the WSDL) is quite complicated.
If your request/responses are huge, then unfortunately you may have to trim them down.
Also, are you validating against the xsds? If so, are they embedded in the requests?
Joined: Aug 10, 2006
Thanks a lot for your prompt reply. The xmls are validated against the schema xsds at runtime while the requests are processed at runtime but they are not validated in the XML documents itself(although they could). The xsds are also refered at in the wsdl document and the xml elements are scoped in the same namespaces. So at runtime the processor knows which XSD to validate the request type with.
What is the general practise? I hope most of the businesses would have moderately complicated business logic. What do people do in those scenarios. Providing the complete SoapUI project seems an option but is it a common practise? I just dont want to be funny in the organization specially with other teams.
XML Schemas are not required for creating a SOAP-based web service message. It looks like you have a sloppy mix of "technical" things which are only required because of the design. I'd suggest looking at changing the design so that it does not require XML Schema instance on either client or server.
Web service technology can be complex by iteslf, when you mix in XML Schema and data definitions and other mess in the data transmission, you end of with brittle designs with tons of dependencies.
Web services should only transmit data, and there shouldn't be dependencies on any type of implementation programming language or customized classes or XML-based languages.
I’ve looked at a lot of different solutions, and in my humble opinion Aspose is the way to go. Here’s the link: http://aspose.com
subject: How to share a webservice with other teams