I have created a web-service which involves accepting certain parameters in URL, validation the and returning XML response to client using JAXB xml library. Recently I came across JAX-WS framework which uses SOAP over HTTP to transfer request/response to/from client. Am I losing something by using simple servlet + connection pooling and serving XML response over HTTP ? Client will be hitting the URL created via some systems which are not known yet.
Is there any advantage to use REST or SOAP protocol, when simple HTTP + XML or JSON can solve the problem.
Sounds like you do not have any constraints over what you serve which leaves you with loads of options. There are quite a few angles to approach this question from, I just list some of the most obvious practical considerations below and leave out any architectural discussion.
SOAP is generally (but not always) used for enterprise integration - but it has a lot of shortcomings - not least in its verbosity. My advice would be not to use SOAP unless you really have no choice in the matter.
XML or JSON ? would your clients prefer to consume JSON or XML? If you are just publishing the service and not consuming it then I would go with JSON since it is becoming a very popular message format now for web services.
If you are the only one consuming the response then you need to think about what your client technology/framework would likely prefer to parse and how big the message payload is likely to be. If it is rich (loads of nested objects and attributes) then an XML schema might suit, but if the messages are very large then consider that the JSON footprint is likely to be smaller than the XML one.
You are not missing anything in your approach. Go for the simplest option - which depends on what framework/libraries you are using and the skill-set of your developer(s). If a servlet appears to be the most straightforward to you, go with that. If your data is already in XML then that seems like the way to go, but if not, I would consider publishing JSON format first. If you're not sure how to do that, first have a look at Jackson.
Update:
If you are still not sure which way to go then just serve JSON.
Also, the format of the messages you consume/publish should not dictate how you implement your application design - I mean, the question to use a servlet or not does not really factor into what message format to use, unless you intend to use a framework which ties you to a particular approach eg. Play Framework will very easily allow you to serve JSON from a Controller (not Servlet) so if you were using this framework - for example - you would not want to use a servlet and you would use JSON since that is the easiest way to go because of the out-of-the box support the framework already provides.
Related
I'm searching for a way to consume soap webservices without using wsimport and tools like that. So far, everyting I found requires the wsdl artifacts generation and I want to avoid it because I don't know wich webservices will be used.
The idea is to give the user the possibility to add several WSDL's urls / methods and the program consume them and send it's response to another url.
I'm not looking for out of the box solutions/code or something like that.
What I need is to know if it is possible or not and how to aproach this problem, ideas and things like that.
Thanks!
SOAP mandates a contract between the Client and Server. The contract is that Client will give a request XML is XYZ format and Server will give response in ABC format. Without this, SOAP does not work. This is what is defined in WSDL. So we have to use WSDL.
Tools like wsimport, wsdl4j convert these WSDL files into an object hierarchy and prepares a JAXB wrapper for you, to make life easy!
Now if you do not want to use the tools which automatically convert WSDL to Java Beans or anything of that sort, note SOAP is based on nothing but an XML. If you know how to parse an XML in java, thats pretty much it. You can use a JAX Parser to achieve this and you can read everything that comes in a SOAP request and response.
The problem that you will face is, as the complexity of the SOAP XML grows, it will be difficult for you to parse the XML properly, identify the nodes, values and relations properly. And add to that the problem where in you cannot, without a proper object hierarchy , relate between nodes which are distance apart. Meaning, from line 100 you cannot go back and relate a line 10 node, unless you start maintaining your own objects, relations etc. (which is not what you want, i guess)
Using Java Beans the object hierarchy is maintained and because of that it is easy for you to relate them between different objects at different nodes easily. But JAXB is comparatively slower than JAX.
We have a webservice which saves data and presents the same on the User interface for viewing the transactions. Now, my requirement is to validate all the input parameters in the web service request to make sure that vulnerable content is not shown on UI. I am looking for solutions to validate input params in the web service request, before it is saved to database.
Some of the solutions that I have are below:
Use Java Filter along with any parser API - Dom or SAX etc and validate all the input parameters. But, this approach might create lot of burden on the server.
Dom and SAX parser
Before saving the data into our database, validate each parameter from java object and if any of them fails, fail the transaction. This looks fine, but kind of maintenance overhead as and when we add a new service.
Are there any API or jars which can be integrated with axis2 or java which takes care of validating the request params rather than doing it manually?
Please suggest what is the best way.
Thanks,
Harika
As you mentioned approach 2 is the ideal one and you can use Apache Commons Lang library's StringEscapeUtils which has methods escapeHtml, escapeJavascript and escapeXml which can eliminate Front end code before saving it into the database.
This will prevent XSS but can not guarantee SQL Injection prevention.
I have developed a simple Spring MVC RESTful API and now I moved to the stage to create a simple GWT project to perform some requests to this api and obviously I choose that the communication will be done by exchanging JSON messages.
When receiving a response I will have to unmarshall it to a POJO.
I am aware that the general approach is to create the so called 'overlay types' but that looks to me as a mere duplicate of the java classes I wrote in api.
So the question is:
why shouldn't I simply create a common api that simply contains the common classes to perform this marshalling/unmarshalling?
I can clearly see that the main benefit is that if any change is needed you won't have to change also the overlay types.
Assuming that you can define interfaces for your pojo, you can share those Interfaces in client and server side (common package)
In server side you have to code your implementations which are used for the RESTful api.
In client side, the implementation of those interfaces can be done automatically with generators. For this you can use gwtquery databinding or gwt autobeans.
To request your RESTful api, you can use either gwtquery ajax or gwt requestbuilder
Each option has its advantages, normally I use gwtquery because its simplicity and because its databinding approach is more lightweight, otherwise, with autobeans you can create your POJOS using autobeans factories in both client and server sides. If you already have developed your backend this is not a goal for you though.
The REST response can be consumed by any client and not specifically one client. If I understand your question correctly, you want to build the logic of marshalling and unmarshalling inside your REST API. Ideally it violates Single Responsibility Principal. You might need to change the mapping logic if the service changes so you are touching two different aspects of an API where as only one component requires change.
Also, the REST API should ideally be designed to be client agnostic. It is your specific requirement to translate them to POJO but another client might want to consume it as simple plain JSON. If you provide an overlay type, your code will be quite loosely coupled.
If your server side class (Player for example) can be serialized/desirialized without any problems, then you can send it to client side without any overlay type / conversion (serialization to JSON on server -> transport -> desirialization from JSON on client). On client side you can use RestyGWT for example to archieve automatic desirialization process. Overlay types and conversion process are necessary only in the case when Player instance cannot be serialized (for example it is backed by Hibernate).
Question is,
What is the accepted 'elegant' solution for parsing URL strings to select a response function in Jetty?
I've provided some background, but feel free to skip my waffle!
The situation is that I've written a bunch of client/server code in Java, using a socket connection to communicate serialized Java objects. Obviously, this depended on both the client and server being in Java, and while that was fine to start with I wish to make the system more universal and resilient to firewalls.
Therefore, I've decided to create a REST API to communicate the data over HTTP.
I DON'T want to produce any HTML - all responses will be JSON-encoded. Therefore, I'd rather not create individual files for each response - instead, I'd like to redirect each HTTP request, based on its type and URL, to a Java method which will produce a JSON response.
Unfortunately my only experience of programming servers is using Python/Django, and I'd rather not change language at this point.
So my question is very simple - how do I set up an embedded Jetty server to parse URLs? I've tried reading the docs, but had trouble making sense of this. At the moment, it seems there are two possibilities.
One is the target string in the handle method of the AbstractHandler javadoc, which I believe contains the entire URL string? So I could manually parse this in a Java method, to which all web requests would be directed.
The other is to use a chain of ContextServletHandler? Not precisely sure how that would be done, or whether this is the intended use of that function.*
What is the best practice for consuming JAX-WS web service in a Java client? I am inclined to use wsimport to generate stubs. It means using JAXB. Please suggest.
Thanks.
I don't know that it's necessarily a best practice, but I definitely recommend using wsimport/JAXB generated stubs for consuming a SOAP service in the client. You could also use any number of other methods but they all boil down to two options:
1) have stub code generated that does all the XML and HTTP (or other protocol) work for me
2) concoct an XML message in a Java String and use various HTTP (or other protocols) methods to send that XML to the remote service. Then parse the result using some method (regex, custom parser, SAX, DOM, etc..)
In reality option 1 boils down to option 2, but you never see it.