WSDL -> WSDL translation

[badbrownie <ba...@gmail.com>]

I work with a system (Salesforce) that can only consume document/literal
wrapped WSDL files. However, my customers need me to connect with older
systems that generate other formats of WSDL file (RPC literal for example or
just doc literal). So I often receive wsdl files in 'unfriendly' formats and
I have a Hell Of A time trying to shoehorn it into a format acceptable by
Salesforce. Basically, there can be no external references in the wsdl and
it must be doc/literal wrapped.

So... I was thinking that a sneaky way to solve this issue might be to
consume the wsdl in Java and then recreate the wsdl from Java
programmatically with a single call.

Can cxf be used to solve my problem?  Has this problem been solved before? 
If not, then am I on the right track? Has anyone solved this wsdl
transformation issue before?  I assume XSLT could probably do the job for a
smarter man than myself, but I've got to work with the brain I was issued
and it seems determined to learn the minimum possible about wsdls in order
to solve this problem.

TLDR: can I consume/create arbitrary format WSDLs from java so I can create
WSDLs in wrapped doc/literal format with no attributes (elements instead)
and no imports (a completely self contained WSDL should be the output).

If you can help me solve this problem I will buy you a pizza! That's right.
I'll email you a papaJohn/Dominos/Pizzahut coupon (or even call your local
pizza joint and buy it for you if you want to give me your home
address/phone number - which you probably don't).

--
View this message in context: http://cxf.547215.n5.nabble.com/WSDL-WSDL-translation-tp5535639p5535639.html
Sent from the cxf-user mailing list archive at Nabble.com.

Re: WSDL -> WSDL translation

[Mark Streit <mc...@gmail.com>]

You may wish to FIRST take a look at this page:
http://jax-ws.java.net/nonav/2.1.2/docs/customizations.html  (this might
help).

Also when you say "external references" are you referring to the use of
imported XSD files in the <types> element?  I know we do a lot of
code-first development in our group where we GENERATE the WSDL/XSD from
annotated POJOs (they have @WebService, @WebMethod, and @WebParam
annotations on the service classes (or interfaces)).  What often then
happens is you get generated XSD files that are "imported" into the
generated WSDL file.   HOWEVER, when you run tools like either *wsimport *(part
of JAX-WS RI/Metro) or *Java2WS *(CXF)... you can control how this
generation occurs based on attributes and options passed on those
commands.  When we use this approach, we wind up with a WSDL <types>
element that looks like this:

    <wsdl:types>
        <schema xmlns="http://www.w3.org/2001/XMLSchema">
            <import namespace="http://webservices.book.acme.com/"
                schemaLocation="BookOrderManagerService_schema1.xsd" />
            <import namespace="http://util.book.acme.com/"
schemaLocation="BookOrderManagerService_schema2.xsd" />
            <import namespace="http://dvo.services.book.acme.com/"
                schemaLocation="BookOrderManagerService_schema3.xsd" />
        </schema>
    </wsdl:types>

where the import statements are LOCALIZED (they are placed in the same
directory as the WSDL)...

Then... when we use such WSDL/XSD to go the other direction and create the
client proxy classes and associated types classes - we package these files
into the resulting JAR file that we create by specifying the *wsdlLocation *to
be in the /META-INF/wsdl folder of the resulting JAR project.  The code
that gets generated winds up resolving the WSDL and the XSDs w/o a problem
because it is NOT external (the imports don't have HTTP URL paths in them)
as one would get if you reach out over the wire to some service endpoint
dynamically appending "?wsdl" on the URL.  In that case, the "live"
endpoint would return imported XSDs that are also HTTP URL based which is
NOT what we want in our environment.  We "localize" WSDL/XSDs into the JAR
file containing the code generated from them.  That's the purpose of that
copy-wsdl-local target in our build.xml (not everything is Maven, not yet
at least... for us).

    <!-- JAX-WS task definitions for CXF -->
    <target name="cxfWSDLToJava" depends="init,* copy-wsdl-local*">
        <java classname="org.apache.cxf.tools.wsdlto.WSDLToJava"
fork="true">
            <arg value="-*wsdlLocation*" />
            <arg value="/META-INF/wsdl/${ws.endpointName}.wsdl" />
            <arg value="-d" />
            <arg value="${src}" />
            <arg value="-client" />
            <arg value="-verbose" />
            <arg value="${src}/META-INF/wsdl/${ws.endpointName}.wsdl" />
            <classpath>
                <path refid="cxf.classpath" />
                <path refid="project.classpath" />
            </classpath>
        </java>
    </target>

There is a CXF committing member from www.talend.com, Glen Mazza, who has a
very useful blog with many WS tutorials on various topics that you also may
find helpful:  http://www.jroller.com/gmazza/entry/blog_article_index

For the record, we had a similar situation where we rec'd some horrible
WSDL document (no imports, all in-line types) from a Siebel implementation
(that had wrapped by a .NET WCF layer). It contained underscores,
non-standard naming conventions, etc and was JAX-RPC based.  We had to use
some bindings customization tricks (that first link above) to get around
some of the problems and yet then had to actually manually change one of
the items in the WSDL to avoid naming collisions.  We then localized all
this into our JAR file, along with the generated artifacts from wsimport
and we were still able to communicate with the service.  It was, indeed, a
huge mess.


HTH

On Sun, Mar 4, 2012 at 2:10 PM, badbrownie <ba...@gmail.com> wrote:

> I work with a system (Salesforce) that can only consume document/literal
> wrapped WSDL files. However, my customers need me to connect with older
> systems that generate other formats of WSDL file (RPC literal for example
> or
> just doc literal). So I often receive wsdl files in 'unfriendly' formats
> and
> I have a Hell Of A time trying to shoehorn it into a format acceptable by
> Salesforce. Basically, there can be no external references in the wsdl and
> it must be doc/literal wrapped.
>
> So... I was thinking that a sneaky way to solve this issue might be to
> consume the wsdl in Java and then recreate the wsdl from Java
> programmatically with a single call.
>
> Can cxf be used to solve my problem?  Has this problem been solved before?
> If not, then am I on the right track? Has anyone solved this wsdl
> transformation issue before?  I assume XSLT could probably do the job for a
> smarter man than myself, but I've got to work with the brain I was issued
> and it seems determined to learn the minimum possible about wsdls in order
> to solve this problem.
>
> TLDR: can I consume/create arbitrary format WSDLs from java so I can create
> WSDLs in wrapped doc/literal format with no attributes (elements instead)
> and no imports (a completely self contained WSDL should be the output).
>
> If you can help me solve this problem I will buy you a pizza! That's right.
> I'll email you a papaJohn/Dominos/Pizzahut coupon (or even call your local
> pizza joint and buy it for you if you want to give me your home
> address/phone number - which you probably don't).
>
> --
> View this message in context:
> http://cxf.547215.n5.nabble.com/WSDL-WSDL-translation-tp5535639p5535639.html
> Sent from the cxf-user mailing list archive at Nabble.com.
>



-- 
Mark *
*