Yarkar,
The stringlist is been generated correctly in the WSDL
<xsd:element name="ArrayOfstringItem" type="xsd:string" maxOccurs="unbounded" />
The additional document stuff is the wrapper that the WSD generator is putting on the service (it strips that off when handing off to the service). The wrapper is necessary if you are going to use the new WSD functions, you don’t have to the old way will still work, even though the old way still has a wrapper concept.
I see several issues however with the way you are going about this:
-Generating WSDL from an existing service is not the best design pattern in my opinion. Better to design your WSDL and associated schema outside of webMethods. This will give you the greatest control over your schema and associated composition of types for messages. It will also better protect you from any provider specific implementation of schema types that may cause interoperability issues.
-If you have an existing service that you want to expose the functions, better to still do the WSDL outside of webMethods and then put in a abstract service that will pass off the invocation to your existing service. Benefits being you are hiding the underlying implementation of your webMethods IS service from the consumer, the abstract service is just that and less likely to have a change impact to the consumers. The new WSD provider model is actually trying to do this for you. However I still like a separate abstract service that handles the invocation of the downstream service(s).
-Your schema libraries probably aren’t going to exist with this implementation either, limited your reuse of existing types.
There are many many different ways to do this and there is not just one right way. For me using a router or facade pattern has been very successful. The abstract web service basically handles the incoming soap message and routes it off to the appropriate service using a common message type defined within webMethods IS. I use either an asynch publish or a pub/wait depending on the needs of calling clients.
The benefits of this are hidden implementation, less brittle services and greater reuse. It also means since I’m using messaging internally to the IS/Broker that the actual implementation service can now be invoked/trigger by a common message from within the IS meaning other protocols can play even if they don’t support web services.
The main point here is that there are multiple ways to implement web services within the IS to achieve some good benefits which include agility, reuse, and abstraction. However they all start with doing your schema and WSDL design outside of the implementation.
Sorry for the long winded response :o but it’s one of my hot buttons. I just don’t see the point of web services without thought to the benefits outlined above.
#soa#webMethods#API-Management