GWT and SOAP classes - java

I have a Web Server which uses SOAP to communicate with a several resources.
I'm using pure JavaScript for the Web App interface. There are allot of data changing between the client and server which includes classes returned by SOAP requests.
I use GSON to create JSON objects from the SOAP responses (which can be all sorts of custom classes) and in JavaScript and just need to access the JSON fields.
Now I was thinking about using GWT on the client but started to have some doubts when planning the implementation.
If I use GWT all the classes generated for the SOAP interface must be accessible to the GWT compiler as I wont be using JSON but the classes directly through Assync Requests.
Now the problem is that there are allot of possible versions of this classes depending on the resource software version itself.
If I continue to use JavaScript that's not a very strong issue because the JSON encoded by the Server using GSON can be of any kind and if it doesn't have a particular attribute that's ok due to JavaScript type free nature (I can just check JsonSoapResponse.field22 != undefined).
If I use GWT will I need to have as much class versions as there are in the server side?
I thought about using JavaScript Overlay types but won't that require rewriting almost all SOAP classes to extend JavaScriptObject and expose their methods?

You could take a look at the AutoBean mechanism.
You will not beed JavaScript Overlay types anymore, just interfaces and the GWT Compiler will do the rest.
see: http://code.google.com/p/google-web-toolkit/wiki/AutoBean

Related

Generate WSDL dynamically

I have meta data that can be used to describe several hundred new web services and would like to dynamically create WSDL files from within my own Java class. I see many ways to do this when you have Java methods you want to expose as web services. Unfortunately that approach does not work for me as I have a single runtime method that can service many different operations and services. It's dynamic and as such does not have static classes that can be bound via map.xml. My plan is to generate WSDL files that will allow incoming SOAP envelopes to be received via HTTP POST, recognized, transformed and handled by my existing method.
This is to allow web service access is a 20 year old proprietary dynamically callable back end. I am certain that the meta data for each service can be easily presented to the outside world as web services and operations.
I could always write a custom builder by appending text to a StringBuilder but that least desirable choice. It would be far more reliable if there was an API I could use that would take in the essential items and attributes and when complete, validate and render a properly formed WSDL file.
I would like this to be generic and not require proprietary add on classes from others like what I might find in WebSphere.
In such case I would consider implementing web service using Provider API (standard part of JAX-WS).
In the end we built a WSDL generator using the .NET 4 System.Xml.Schema and System.Web.Services.Description namespaces. The generated WSDL is used in both Java and .NET to build client and server interface classes. It took a while but we have most of the services up and running, and they are totally platform agnostic.
I prefer to use Spring Web Services. Where it can take an XSD with reasonable defaults and turn it into a WSDL.
See sws:dynamic-wsdl in http://docs.spring.io/spring-ws/site/reference/html/server.html#server-automatic-wsdl-exposure

How can I implement Hunch's API in java?

I'm creating a Java application that uses Hunch's API, but the problem is I have no clue as to how I can use a web API in Java. Any ideas?
That depends on what the API provides, generally you'd need a web server (like Tomcat) to run a web framework.
If it's just an api to communicate with a service via HTTP (maybe webservices) then have a look at the corresponding libraries (JAX-WS etc.).
Edit: I looked up Hunch API, and assume it is this: http://hunch.com/developers/v1/
It seems like it would return JSON encoded data, so you might use the URL class to read data from an URL. That data would be a JSON string which then needs to be decoded using one of the many JSON libraries out there (e.g. JSON-simple).

Is it possible to consume an EJB 3 Web Service form a Java client without first generating client stubs/proxies?

In most tutorials that I have seen so far people are using wsconsume or something like that to create classes that clients can use to access an EJB 3 Web Service.
Is this the only possible option? As my EJB's interface is annotated with WebMethod, WebParam, etc. isn't it possible to create a dynamic proxy or use runtime bytecode enhancement to create the proxies, etc. on the fly? E.g.:
MyWebService webService = WebServiceEnhance.getWebService(MyWebService.class);
webService.webMethod("foo");
A link to good reference material is also highly appreciated.
One way is to deal with pure XML request/response. You can trap sample request/response for the web service you want to consume using either SoapUI or Fiddler and then use these samples as templates within your client.

Is it possible to call a GWT servlet from native Java?

I have a GWT application, with a Native Java backend, and a compiled Javascript front-end (as usual).
My GWT service should also be accessible from other clients, including a java applet. Initially my idea was to double the GWT service as a SOAP service, and use a soap client from the applet to access the GWT service, but I am wondering if it might be possible to use the built-in GWT client infrastructure to call the server from Java.
The problem with this approach is serializing the request and deserialize the response so as to be compatible with the GWT service.
One solution is to use GWT SyncProxy:
http://code.google.com/p/gwt-syncproxy/
which is explained here:
(dead) http://www.gdevelop.com/blog/2010/01/testing-gwt-rpc-services/
(Wayback Archive) http://wayback.archive.org/web/20130107141210/http://www.gdevelop.com/blog/2010/01/testing-gwt-rpc-services/
You can use it directly or, since they provide the source, you take a peek to see how they serialize the request and deserialize the response.
Another approach is to use Restlet to provide the services and then convert your GWT client to make REST calls. The Restlet people provide a GWT library to facilitate this.
http://wiki.restlet.org/docs_2.0/13-restlet/275-restlet/144-restlet.html
They provide an example of calling the REST service via Restlet from different clients, including GWT client, Java SE, and Android:
http://wiki.restlet.org/docs_2.0/13-restlet/21-restlet/318-restlet/303-restlet.html
Edit:
I only know RESTlet from evaluating it last year for my GWT project. I'm no expert and I didn't end up using it, but this is no reflection, good or bad, on RESTlet.
OP asks:
What would be the advantage of using the Restlet framework over JAX-RS ?
Essentially, JAX-RS is an just API (like JDBC) - you still need to pick an implementation or use the reference implementation Jersey. RESTLet has an extension for supporting JAX-RS API.
http://www.restlet.org/about/faq#07
7. What is the link between Restlet and JAX-RS (JSR-311)?
...
To summarize, both APIs have very different designs but are potentially complementary. The good news is that Jérôme Louvel (Restlet's creator) is an active member of the JSR-311 Expert Group and that an implementation of the JAX-RS API was made on top of the Restlet API. This "JAX-RS extension for Restlet" was developed by Stephan Koops in the context of his Master thesis and is one of the most advanced implementations available. For more documentation on this extension, please refer to this page.
OP asks:
Is it possible to use Tomcat / web.xml infrastructure instead of org.reslet.server
http://wiki.restlet.org/docs_2.0/13-restlet/275-restlet/312-restlet.html
This edition is aimed for development and deployment of Restlet applications inside Java EE application server, or more precisely inside Servlet containers such as Apache Tomcat.

clarification on the concept of "web service"

Im a little confused on the varying definitions and implementations of web services available as implementations. Need some clarification please.
Ones I have used till now:
If a vendor gives me a specific format of XML that I can send populated with data to request and I make a simple HTTP POST over the internet passing in the XML String as the payload, is this a web service call ? If so, is there a specific name to it, this kind of web service ? Because obviously, it does not use anything like Axis, WSDL or SOAP to establish this connection.
A variant of this is If the vendor gives me an XSD, I use JAXB to make a java class out of it and pass in the serialized version of the object, which eventually works out to be the same as option 1.
RESTful web service: Vendor gives me a URL like http://restfulservice/products and I can make HTTP Requests to the URL and depending on what HTTP verb I use, the appropropriate action is called and the response sent over the wire.
Ones I have only read about\ have a vague idea about
SOAP. How does this work?.. Ive read the W3Schools tutorial and I undertsand that there is a very specific form of XML that is standardized according to W3C standards that we use to pass the same kind of messages as we did in option 1. But how does this work in real life? Vendor sends me what? Do I generate classes? Do I serialize some objects and http post them over to an address? Or do the generated objects themselves have connection methods that will do them for me?
What about WSDL? When does a vendor send me WSDL and what do I do with it ? I guess I can generate classes from it. If yes, then what do I do with the generated classes ?
When do I need that axis jar to generate classes from something that the vendor sends ?
As you can see, I have some clear and other mostly vague ideas about the different kinds of web services available. would help if someone ould clarify and\or point to more real-world resources. I've looked a little bit into Java Web Services on the internet and the numerous four letter acronyms that get thrown at me make me dizzy.
Thanks
If a vendor gives me a specific format
of XML that I can send populated with
data to request and I make a simple
HTTP POST over the internet passing in
the XML String as the payload, is this
a web service call ? If so, is there a
specific name to it, this kind of web
service ?
This is still a web service, yes. It doesn't have an "official" name, I usually refer to it as XML-over-HTTP, mainly because I can't think of a better name.
SOAP. How does this work?.. Ive read
the W3Schools tutorial and I
undertsand that there is a very
specific form of XML that is
standardized according to W3C
standards that we use to pass the same
kind of messages as we did in option 1
SOAP provides a standard wrapper layer around the sort of messages you were sending in (1). This wrapper provides information such as an indication as to which operation you are invoking. It can also provide security services, transaction information, and so on. It's a pretty thin layer, usually.
What about WSDL? When does a vendor
send me WSDL and what do I do with it
? I guess I can generate classes from
it. If yes, then what do I do with the
generated classes ?
Again, WSDL is a pretty thin layer, this time around an XML Schema. It defines the operations that SOAP messages will invoke at runtime, as well as the Schema types of the requests and responses. Its a way of formalising the XML document exchange interface.
Say, for example, you had an XML Schema, and have a web service as you described
Using JAXB to generate java source from the schema
Send XML documents conforming to that schema over HTTP to the web service
With WSDL and SOAP, you would extend this a bit :
Write a thin WSDL wrapper around the XML Schema, formalising which operations are available.
Use a WSDL import tool to generate client/server stubs for that WSDL/Schema. In Java, this often incorporates JAXB.
Use a SOAP client/server to invoke the web service
As you can see, it's essentially the same process. The difference is that SOAP/WSDL provides additional information and context to the tools, allowing those tools to do more of the work for you. It's not hugely different, though.
If you get a WSDL document from somewhere, all you really need to know is that it defines a service interface. You run it through your favourite language's binding generator to make some code that you can use to call the service. Typically that means you'll be talking over the wire to the service using SOAP messages over HTTP. SOAP's just a wrapper round sending pretty arbitrary XML messages.
Axis is a library for doing this stuff in Java (both client and server side). I suspect that there are better implementations in other libraries.

Categories