The Secret language of WSDL - The entry point

Hi there, if you like me has to deal with a lot of service definition you'll be wise if you read how that WSDL actually works.

If you, like me, are to lazy to actually learn all that you may want to read this post.

So  this post series (at least I hope to create a series out of this) will try to sum up the main thing one should know about how to read from a WSDL.

We will start by the main thing, at least for me, the ENTRY POINT.

So what to I mean by Entry Point.
For me it's just the Java class that will actually allow you to access all the operations defined in the service definition.

Where is this defined in a WSDL, easy just look for this tag:

<wsdl:service name="UserServiceImplService">
    <wsdl:port binding="tns:UserServiceImplServiceSoapBinding" name="UserServiceImplPort">
        <soap:address location="https://fake.service.provider.com/Some-path-dev/services/admin/UserService"/>
    </wsdl:port>
</wsdl:service> 

Now this portion of the WSDL will basically describe the entry point of some service.

Once you run your wsdl2java tool to generate the Java code,  what class should I look for?

Well for starters I'll go with: UserServiceImplService
Which is the value of the name parameter in the wsdl:node service.

This class will allow you to access the proxy class (which is no other than the port), this proxy class will expose all the operations that are defined to be accessible for this service.

How do I find this port/proxy class?
Well..... try looking for: UserServiceImplPort
Which is no other than the value of the name parameter in the node: wsdl:port


This has worked out for me in the past I hope it helps you!

BTW do thank my good friend the Master of CXF Gustavo

Cheers

Multipart message with jersey

Hi there, so I'm really happy to see that there is people at least accessing this blog.
Honestly I was intented only for me but if it helps others BRILLIANT, one thing though: DO COMMENT.

Most useful data is usually find in the comments.

Now to today's topic: multi part messages.
In short multipart is a message that could be compose by more than one content type.
All this is part of the HTTP specification and in different RFC of it the guys creating the specification had defined different multiparts.

Today I'll show you how to handle two of them, which are more or less the same, with Jersey Client.



MULTIPART-MIXED
In this example I'll be sending a form with part of the message as XML and the other is the content of a file encoded in BASE64.

            // Asume that this method will just return you a builder 
        WebResource.Builder builder = getBuilder(user, password, url, null);

        // Add headers
        builder = builder.type(MultiPartMediaTypes.MULTIPART_MIXED);

        MultiPart multiPart = new MultiPart();

        // XML Document
         String xmlContent = getXMLContent();
         multiPart = multiPart.bodyPart(new BodyPart(xmlContent, MediaType.APPLICATION_XML_TYPE));

        // File content
        BodyPart bodyPart = new BodyPart();
        multiPart = multiPart.bodyPart(bodyPart);

        InputStream fileInputStream = getFileInputStream();
        bodyPart.setEntity(getFileContentInBase64(fileInputStream));

        ClientResponse clientResponse = builder.post(ClientResponse.class, multiPart);



MULTIPART-FORMDATA
For this example I'll be just sending some plaint text fields in the form and then the content of a file.

            // Asume that this method will just return you a builder 
        WebResource.Builder builder = getBuilder(user, password, url, null);

        // Add headers
        builder = builder.type(MediaType.MULTIPART_FORM_DATA);

        FormDataMultiPart form = new FormDataMultiPart();
        form.field("document[file_name]", fileName);
        form.field("document[description]", fileDescription);
        form.bodyPart(new StreamDataBodyPart("document[attached_file]", fileInputStream));

        ClientResponse clientResponse = builder.post(ClientResponse.class, form);



As you can see there is not much difference but the content-type header.
The other big difference is that the multipart-formdata does has the shape of a form.
This is you set a name of a property in the form and it's value.

But in multipart-mixed you just add body parts that can be what ever you want.
Of corse under the hod the serialized message looks quite different. In the mixed message you'll see some separators and the fact that the file is encoded, this is plain text but encoded.

Any ways this may save you some time.

Hope you like it.