I have a scenario where i am hosting different java Rest Services on different Tomcat instances (different machines). These projects running on the tomcats do not have any UI. For simplicity's sake, lets assume that the user will directly enter some URL in the browser (or curl) to avail these services. Now I need this service to be able to talk to (call functions) the services available in the other tomcat instance.
For eg. If TomcatInstance1 gets the call, and all this does is act as a 'router' to the different services, i want it to be able to place the Rest call for the other 'service' available on, say, TomcatInstance2. Is this possible?. If so, how to achieve that? (Tried searching for similar questions on SO, couldnt find any). Are there any online reference for the same?
PS: Hosting the services in the same Tomcat Instance is against the requirement that I'm having.
That is completely possible. You can use (for example) Jersey-client (http://jersey.java.net/) to make the queries to the other RESTful web services in the other Tomcat instances. Only need to define the correct URIs of the end points and query them according the the API exposed and call it (like you were a client from a browser, or curl).
See here a nice example of using Jersey-client to do that: http://www.mkyong.com/webservices/jax-rs/restful-java-client-with-jersey-client/
I would suggest Spring Restful api ( http://static.springsource.org/spring/docs/3.0.0.M3/reference/html/ch18s02.html , http://www.mkyong.com/spring-mvc/spring-3-rest-hello-world-example/ ).
As #emgsilva mentioned the only thing you need to do is to point correct uris between each other.
The beauty of spring restful api is it is simple to use and you don't deal with any serialization - deserialization.
Related
I have been asked to create a JAVAX-WS web service which basically performs some basic computation on the input to return the output. I also need to lookup some values from a database.
I am using this book :
Java Web Services: Up and Running
What I've done so far :
1. Created the main java program containing the methods that perform the computations.
2. Used wsgen and wsimport to generate the various artifacts.
3. Used Endpoint to publish the service on localhost.
What I need to do :
I need to get it running on something like a windows server for .NET services. So that it can serve multiple machines.
I know next to nothing about web services and servers, and have just gone through the first chapter of the aforementioned book so far.
From what all resources I've gone through I believe I could use GlassFish, but I don't know if it serves my purposes.
So if anyone could point to some helpful resources for the same, it would be extremely helpful.
P.S : I have no idea about looking up the required values from the database, so please point to some resource for that as well.
Endpoint can also serve requests concurrently, you can enable thread pooling by creating a ThreadPoolExecutor and registering it with the endpoint. See Endpoint.setExecutor(Executor executor)
If you want to deploy your Web Service on GlassFish you should change it into a WAR project, see http://docs.oracle.com/javaee/6/tutorial/doc/bnayl.html
I'm looking for some advice on the simplest way to create some product registration communication. I have a Java desktop application that needs to be re-newed every year. When a user downloads and install this app (through JNLP) they get a limited demo-version. There is code in place on the client to "register" the product and unlock all of the features.
My next step is to build the server-side components. There will be a database with customer ID numbers and other information about the customer. When the user clicks register, some contact information will be sent to the server as well as some product registration ID. The server will check this against the database and then either give the client the o.k. to unlock the features or the user will be informed that the registration id was not valid. This seems like a very standard thing. So what is the standard way to do it?
I have my own VPS and I'm running Tomcat, so I'm really free to implement this any way I choose. I was planning on building some web service, but I have never used REST before.
Use REST; REST is nothing more than using plain HTTP 'better'. Since you are already using HTTP, somehow you are already doing REST like calls and moving these calls to full fledged REST will be easy.
Implementing REST calls is easy. You have two approaches:
Low end: using URLConnection objects on the client, servlets on the server and following some REST conventions on using HTTP methods and 'clean' URLs (see here). Advantage is that you need no 3rd party library and minimize the footprint. Maintenance and evolutions are harder though.
High-end: a framework and specifications like JAX-RS. Using Restlet you can be up in running with a REST server in a couple of hours without having to deploy a servlet container.
Don't use SOAP. The only reason you would want to use SOAP is that you want to contractualise using a WSDL what you are exposing (you can do the same with REST btw, see the Amazon documentation for instance). Trust me, SOAP is way too heavy and confusing for what you are trying to do.
I have a Web Service accessible via SOAP. Let's assume it provides a method with the signature
sayHello(String name)
Of course, I have the WSDL describing the Web Service.
What I want to do now is to generate a client web application (war archive) with a GUI that provides a form to enter the parameter for the Web Service method. In case of the example, the form must just allow to enter the value for the "name" parameter. Then, a SOAP message must be assembled and sent to the WS.
Is there any way or any framework to generate such a webapp automatically!? The actual kind of the resulting webapp is not important, it may be a GWT webapp, JSF, plain Servlet with JSP or whatever. Even a plain HTML/JavaScript client app would be OK.
I mean, there are tools to generate CRUD forms out of data models, so there must be tools to create forms for Web Services, too...
I've been googling around for a long time, but the only thing I've found is a feature of Eclipse: http://www.eclipse.org/webtools/jst/components/ws/M3/tutorials/WebServiceClient.html . Basically, this does what I want, but I'm looking for a more ..hm.. elegant way to do this ;-)
Thanks in advance,
Frank
What you are looking for is (I think) similar to what this site seems to do: link soaptest
As far as I know there is no framework that supports this out of the box.
All frameworks support the automatic generation of client stubs and artifacts and application developers use that to implement their functionality.
In your case create the HTML interface your self to test the web service.
Only .NET web services provide similar tool for testing link text
If I remember correctly, Netbeans provides simple web pages to test the functionality of web services methods (methods offered by the server). You can find a decent amount of guides showing you how to create wevservice clients on youtube. It is a relatively straight forward process.
If it is just for testing the web service: go for soapUI. It's a standalone application and (to my opinion) a must for every SOAP engineer.
Basically I need webservice where client can request with id one boolean value from our webservice. What technology would be most suitable for this small API? Of course it is possible that there will be more functions to interface, but now we need only one function. It also needs to have authentication, so that only auhtorized clients can access service. And every client have different auth credientials.
What would be good technology for this purpose?
I am using resteasy to build my webservices and it is pretty easy to use ... just need to use annotations on my methods to deliver the webservices.
Here is a comparison of different JAX-RS frameworks. Take a look at it
First of all: authentication and authorization. Don't do it yourself, pick an app server or servlet container and configure it to do the job.
For the web service....
The simplest thing to do it just implement a servlet that responds to a POST (not a GET if request modifies internal state) and returns the result in the body. This way you don't need any frames works, no learning to do (if you already know servlets). The downside is it won't scale as you add more features, and your not using enough buzz words.
If you want a SOAP based webservice, then look at JAX-WS. Now that it's backed into java 6 it's pretty easy.
At the simplest level JAX-WS lets you put a few annotations on your class, like #WebService, and it auto generates a wsdl and exposes an instance of your class via the web service.
There is plenty of documenation out around how to do it:
http://java.sun.com/webservices/docs/2.0/tutorial/doc/
http://www.java-tips.org/java-ee-tips/java-api-for-xml-web-services/developing-web-services-using-j.html
http://cwiki.apache.org/GMOxDOC20/simple-web-service-with-jax-ws.html
JAX-WS + any servlet container (Tomcat is usual choice)
#WebService(targetNamespace = "http://affinity.foo.com", name="RewardsStatus")
#SOAPBinding(style=SOAPBinding.Style.RPC, use=SOAPBinding.Use.LITERAL)
public interface RewardsStatusIF {
#WebMethod(operationName="GetLastNotificationDate", action="urn:GetLastNotificationDate")
#WebResult(name="return")
public Date getLastNotificationDate() throws AffinityException;
...
Actually, you don't even need a servlet container. JAX-WS has a way to run the service under a standalone Java application. It has some limitations (I have failed to make a stateful service work), but it's
very simple to create.
Given that you tagged your question as "Java", I suggest Jetty. It is a very good small servlet engine. It has support for sessions, so adding authentication should not be a problem.
If you are using Java 6, there is already a HTTP Server builtin, it supports Http authentication. That's all you need. Check out,
com.sun.net.httpserver
You could use some restful framework like jersey.
An alternative to SOAP-based web services with JAX-WS would be JAX-RS (for RESTful web services).
We have a lot of scenarios on our project where we want small amounts of data available via simple HTTP URLs while the app is running and in my experience, Restlet (http://www.restlet.org/) seems to be one of the easiest things available for setting up simple "web-service"-like interfaces (RESTful interfaces) within Java apps.
Here are some tools that I have found to test web services consumers:
http://www.soapui.org/
https://wsunit.dev.java.net/
Are there any others? I would prefer testing frameworks that are written in Java or Python.
I have used soapui by a maven plugin. It can create junit-linke reports to be run and analysed like unit tests. This can be easily integrated in continious build, also with the free distribution of soapui.
I've used Web Service Studio.
Web Service Studio is a tool to invoke web methods interactively. The
user can provide a WSDL endpoint. On clicking button Get the tool
fetches the WSDL, generates .NET proxy from the WSDL and displays the
list of methods available. The user can choose any method and provide
the required input parameters. On clicking Invoke the SOAP request is
sent to the server and the response is parsed to display the return
value.
This tool is meant for web service implementers to test their web
services without having to write the client code. This could also be
used to access other web services whose WSDL endpoint is known.
Also the Web Services Explorer in Eclipse which comes as part of the Web Tools Platform.
Through UDDI and WSIL, other applications can discover WSDL documents
and bind with them to execute transactions or perform other business
processes. The Web Services Explorer allows you to explore, import,
and test WSDL documents.
The Grinder is right up your ally with both Java and Python, that handles most web services, (SOAP/REST/CORBA/RMI/JMS/EJB) etc.
http://grinder.sourceforge.net/
You really need to be more specific: What is it that you want to test in your WS-consumer? That it calls the right WS? This looks a bit pointless - WS are a perfect place for mocking whatever may be called - without anything being called.
In order to test the consumer you'd otherwise be writing a Webservice that mocks the original, right? I'd suppose that the communication protocol that goes through the wire is not the clients domain - e.g. it's generated. So the only thing a WS-consumer's client sees is the interface. And there's nothing to test in an interface.
It might be that I completely misunderstood your question - please clarify if I did. I'll revise the answer then.