I have Java EE applications (ear) running on separate JBoss instances and on different hardware. I want to call from
one application to another which is in another server JBOSS.
Same JBOSS, between two ear.
Same Server, between two JBOss.
The communication data types can be any type. For instance; JSON or Objects. I want to know what lightweight, Open source Java web frameworks I can use to call from one to another? Here some of them. But I don't have any experience from them. Commonly, SOAP and RESTful services are used and there are many implementation frameworks of them.
Please suggest me know from your experience what are the available frameworks which suit for my requirement? Let me have source which explain any comparison. My concerns are that, the communication methodology should be light weight, should support to transfer any type of data, there should not be much configurations, or standards. The framework should support to transfer simply (all communications are done in my applications. so no need well structured, standardized weight configurations) and securely. and it should be in Java. I use Java 7.
This is a typical integration problem. For integrating, mediating, proxying etc. different services and even transferring data, use Apache Camel. For a short answer what Camel is, see What exactly is Apache Camel?
In Camel you define routes using a Java DSL or a XML Spring DSL. Proxying a web service is described here. Using the XML Spring DSL, the route would look as follows:
<route>
<from uri="jetty:http://0.0.0.0:8080/myapp?matchOnUriPrefix=true"/>
<to uri="jetty:http://realserverhostname:8090/myapp?bridgeEndpoint=true&throwExceptionOnFailure=false"/>
</route>
Using the Java DSL, this would become:
from("jetty:http://0.0.0.0:8080/myapp?matchOnUriPrefix=true"
.to("jetty:http://realserverhostname:8090/myapp?bridgeEndpoint=true&throwExceptionOnFailure=false")
There are many different protocols that are supported by Camel such as JSM, SOAP WS, RESTful WS, plain HTTP, TCP. Have a look at https://camel.apache.org/components.html for all possibilities.
The next example shows you how easy it is to define a RESTful server using the Restlet component:
from("restlet:http://localhost:8400/orders/{id}?restletMethod=post")
.process(new Processor() {
#Override
public void process(final Exchange exchange) throws Exception {
final String res = "received [" + exchange.getIn().getBody(String.class) + "] with order id = " + exchange.getIn().getHeader("id");
exchange.getIn().setBody(res);
}
});
The corresponding client looks as follows:
from("direct:start")
.setBody(constant("Hello, world!!"))
.to("http://localhost:8400/orders/22?restletMethod=post")
.log("order: direct start body result = ${bodyAs(String)}")
That said, Camel supports a plentitude of enterprise integration patterns such as splitter, aggregator etc. that can be used for your needs. Have a look at http://camel.apache.org/enterprise-integration-patterns.html for more information about that.
You can just use "normal" Java classes for transforming data and hook them into the routes. Beside that there are many integrated type converter for transforming one data type to another. These converters can easily be extended. See https://camel.apache.org/type-converter.html.
You could use Camel as your base integration framework and add e.g. JMS/ActiveMQ for the communication. However, it is also possible to use ActiveMQ as your base and add Camel for transforming the data, see https://activemq.apache.org/broker-camel-component.html: "The broker camel component makes this even easier - which intercepts messages as they move through the broker itself, allowing them to be modified and manipulated before they are persisted to the message store or delivered to end consumers." However, I prefer to use Camel as the base and add JMS/ActiveMQ for the asynchronous communication (e.g. if message persistence is needed or if the communication has to occur between different hosts).
Camel supports a huge amount of different protocols and formats. However, you don't have to use them, if you don't need them. Just add the dependencies to your pom.xml if you need them. Apache Camel is a small library (11.2 MB) with minimal dependencies for easy embedding in any Java application. Camel runs standalone, in a Servlet engine, or in an OSGI container such as Karaf/ServiceMix/JBoss Fuse ESB. You can start small and the application can grow, if your needs are growing.
For starting using Camel, read the excellent book by Claus Ibsen: http://www.manning.com/ibsen/.
From my understanding of your situation, I think ESB would be a good solution for your problem.
http://en.wikipedia.org/wiki/Enterprise_service_bus
The one from WSO2 is a pretty light-weight open-source ESB and has a good active community.
http://wso2.com/products/enterprise-service-bus/
you could use jax-ws to provide the webservices from your JBoss and call them using javax.xml.soap. What i dont know is if its possible to send object data, maybe you have to serialize from and to xml end send it encoded as base64 string.
Another way might be jms.
If all of the other solutions listed here do not fit your needs, you could interact with the applications by sending JSON or XML data over HTTP.
Spark is a micro web framework for Java that lets you quickly create web endpoints.
By default, Spark runs on an embedded server, but it can easily run on an existing JBoss server instead. Here is a sample that I put together a few months ago to demonstrate how it works and how to get it working with JBoss.
You can have each application that needs to receive data expose a HTTP endpoint and have the calling applications send a simple HTTP request.
Simple and open win. You can expose objects remotely in many different ways, but Java RMI and EJB limit you to Java only clients.
The most open, easiest way to do it is to use HTTP as your protocol and web services, either SOAP or REST (my preference). These will interact easily with any client, even those that aren't Java. Clients need not know or care that you chose Java and JBOSS to implement your server logic.
Related
In my company we are starting to use web services. My plan is to provide access to services via 2 protocols, http and jms. Any external access (clients outside company network) to services will be typically via http and json through a restful URL, but internally if the service needs to invoke another service, it will do it via jms, mainly to decouple the service from each other.
My question is following
Can camel provide abstraction so that i can write my service code without http, json and jms dependencies? I would like camel to handle http to java, json to java and jms to java conversion through some mediation and invocation of my service should be simply through a java method with accepts a java object as a request. Keep in mind that although http is synchronous model, jms would have to simulate request-response. If yes, can you please point me towards an example which demonstrates this setting.
Likewisely, i would like camel to convert the response from my service, which would be a java object, into json and return the response back to the client.
Lastly, how can i scale in this model. For JMS, it is easy to startup multiple instances and have them listen to a queue. How can i leverage same instances to loadbalance across http interfaces? I would like services to have location transparency, hence, they should not have to care about invoking "jms" specific cluster vs "http" specific cluster?
I think you can achieve all of this with Camel.
Marshalling between different object representations is handled through data formats. You can call POJOs from within Camel routes that can encapsulate your services.
See data formats.
Camel comes with clustering and load-balancing support. But if you only have HTTP type endpoints to load balance, then my personal opinion is that you should use a more http-centric approach, like using httpd as a reverse proxy/load balancer.
I have my web application written in Spring MVC. It is quite simple app for registering some activities and generating reports after some time. Now I have it done fully in Spring. The only entry point is HTTP webapp request. I'd like to add other entry points to allow user to trigger application via JMS queue, FTP files and SOAP-based web service.
I know I can do this all using Spring own features somehow, but I wonder if it is desirable to involve Apache Camel into all that stuff?
I think about leaving web application as it is (communicating directly with services), only add some Camel magic to spring context and expose several endpoints from Camel and then after messages processing and transformations call existing services.
I think about using Camel to be able to use some asynchronous processing and threads/scalability features. Is it the right way to go?
I will recommend you to use Apache Camel. I have used it for a similar purpose. The solution is an appropriate one from a 'Separation of Concerns' point. Camel implement Enterprise Integration Patters and is a better solution for integrating various protocols and interfaces. Your application should deal with functionality only and as designed should just expose a servlet to get requests and process it.
Handling of interfaces and protocols are well structured in Camel and its easy to maintain and configure in the long run.
I have currently two wars files in which one war has to send notification to other war file using spring.Both of the wars are implemented using spring and web service.
My requirement is first war has to send notifications to other war file.
Could you please provide some pointers to implement the same using spring ?
I do not know exactly your requirements but I'd suggest you to use RestFull web service for this notification. Spring has a perfect support of this kind of services.
Internally the first application will send HTTP POST (or GET) request like http://thehost/webapp2/mynotification
Other way is to communicate using JMS. This way is good if you have to make the communication asynchronous. Spring supports JMS using JMS templates.
You can use:
JMS
a webservice (or spring http invoker) in the target app and invoke it from the notifier
You can use RMI to export your beans and make them visible from other modules, better than other alternatives in this case because:
JMS is asynchronous and needs a middleware.
Webservice are less efficient (since it is mostly conceived to communicate heterogeneous platforms).
Take a look here on how to do it:
http://static.springsource.org/spring/docs/3.0.x/spring-framework-reference/html/remoting.html#remoting-rmi
But I would first of all review the architecture you are using, in case you can refactor it for a better integration of business logic.
I have a backend system that currently returns a domain object. I want to build a REST & SOAP front end using mule. To create responses that are REST or SOAP based, and ensure that the backend is protocol agnostic, I am thinking about creating two protocol adapters (REST and SOAP). It is unclear to me if it is better to create a mule translator for the service, which understands the protocol and delegates to generate an appropriate response, or just create two class interfaces (using JAX-RS/JAX-WS annotations) to the service.
I'm not finding much literature, best practices, or design patterns on the subject. Can someone point me to some useful material or provide their opinions?
Writing transformers for message formatting would be a waste of time.
You should write service classes with JAX-RS/JAX-WS annotations, transports exist for both.
For a REST service you can use the Jersey transport:
http://www.mulesoft.org/documentation/display/JERSEY/User's+Guide
For SOAP service you can use the CXF transport (also supports JAX-RS):
http://www.mulesoft.org/documentation/display/CXF/Building+a+web+service
Note: You don't need mule for this at all, both Jersey and CXF run in a servlet container like tomcat.
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.