I'd like to expose a public RESTful API and either configure our ActiveMQ instance (is possible) to listen at that API and automatically enqueue a JSON or XML version of those API calls, or configure/write software to translate the API call into a message and enqueue the message to an ActiveMQ queue/topic.
So, in other words:
A third party sends an HTTP request (GET/POST/PUT/whatever) to http://myserver.com/api/enqueue
Either:
ActiveMQ is somehow listening at http://myserver.com/api/enqueue and automatically enqueues a toProcess queue/topic with the API call's body; or
I have some kind of servlet listening at that URL and then pass the request on to some software (either open source Java library or something homegrown) that can extract the HttpServletRequest's body and enqueue it to a queue/topic on the ActiveMQ server
So I ask: does ActiveMQ come with this capability out of the box (initial research indicates it doesn't), or are there any open source libraries that would do this for me, or some part of it for me? Or, am I stuck with a custom homegrown solution? Thanks in advance.
In a simple way, ActiveMQ actually does support HTTP/REST-ish interaction with queues out of the box.
As you did ask for Camel, yes, it does support creating more advanced REST API:s and works very well with ActiveMQ (actually, the Camel Core and JMS modulels is part of ActiveMQ distribution).
My favourite way to create REST APIs with Camel is through restlets.
As Brian Roach said, this should be very straight forward to do in plain java code as well with some helper libs, so don't feel bad about a home grown thing here.
Related
I'm trying to implement something similar to https://code.msdn.microsoft.com/Brokered-Messaging-Request-0ce8fcaf#content in Java, but can't find functionality from the Service Bus Java SDK to match the QueueClient.AcceptMessageSession used in the example.
So how can I make the client to poll the response queue only for messages that match the expected sessionId? Do I need to create a seperate response queue for each client? Or is it best practise to re-insert non matching messages back to the queue?
I'm using the com.microsoft.azure/azure-servicebus maven package version 0.9.3.
Seems that this feature is not supported in the Java SDK because it uses the service bus REST api instead of the WFC api. Topic/Subscription way might be the only way to implement this with the Java SDK.
More detail: https://github.com/Azure/azure-sdk-for-java/issues/246
#HannuHuhtanen, in my mind, I think the solution is that using two JMS connections to seperately connect two service bus queues for a continuous WebJob as server and clients, please try to refer to the tutorial to know how to use JMS with AMQP for ServiceBus.
I've learned a respectable amount about networking protocols in Grad School and in professional experience and sent HTTP requests programmatically using AJAX and such.
The project on which I work professionally uses JMS to communicate and I'm curious about how it works.
When using REST (for instance) one makes an HTTP request with parameters in either the URI or the message header in order to invoke a service and further describe its needs.
A mentor of mine at work and I were discussing how JMS works and I'm struggling to understand at an application level how messages are actually sent. As far as I understand JMS in general (I realize there are many implementations of JMS) it is a specification for how to format data being sent.
Is the message itself still sent via HTTP(S)? Could it be SMTP?
Without going excruciatingly deep I would like to understand how one would, at a code level, send a JMS message from one service to another?
Am I even thinking about this correctly?
Can it be done any number of different ways?
Is there a convention that's used in the industry?
If someone could shed some light on JMS for me I would appreciate it.
Thanks!
JMS is not a protocol, it's an API specification. It's not something like TCP or HTTP protocol. Simply put the JMS specification defines signature of messaging APIs. How the APIs are internally implemented and what protocols they use to communicate with the messaging provider is vendor specific.
The vendor specific JMS implementations know how to communicate with their own messaging provider, but not with any other vendors messaging providers. For example IBM's MQ JMS implementation uses it's own protocol to communicate with IBM MQ Queue Manager, similarly Oracle JMS, Active MQ implementations with their own messaging provider.
Hope this helped.
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.
I'm trying to kludge some legacy connectivity into one of our newer applications, and this marks my first foray into MQ. We have a middleware server that accepts an XML message delivered via MQ; converts this into a proprietary request for our ancient system of record, and then delivers a response on a reply queue in a similar XML format.
I have a sample of the input and output XML structure, and the MQ host, target queue, and reply queue. What I do not have is a clue as to where to begin.
Is there a decent tutorial available for building a simply request/response mechanism with OpenMQ or one of the other free MQ libraries?
Thanks!
I would suggest that you first get comfortable with the Java Message Service (JMS) concepts and API and then concentrate on the particulars of OpenMQ.
To learn about JMS, read the JMS chapter in Oracle's Java EE 6 Tutorial. The Manning book ActiveMQ in Action gives a good introduction to JMS concepts.
If you want to simplify your JMS code, consider using Spring JMS.
The Oracle developers guide for OpenMQ would prob be a good place to start:
http://download.oracle.com/docs/cd/E19798-01/821-1796/index.html
Gives you example code, explains how to interact with it, etc.
WebsphereMQ has an API tester - a demo application that allows you to experiment with the API and different features from a GUI
There's a similar tool for generic JMS providers called hermes
I've asked Google and searched through the NServiceBus website and forums, but I can't seem to find any prescriptive guidance on how I would write a Java application to subscribe to a publisher. Does anyone have any such link or experience?
This scenario is not well supported out of the box - you'll need to do some infrastructure munging yourself. In general, look at how the proxy is built, and add some gateway-style HTTP communication in the mix, or expose that with a standard .NET webservice.
You could manually send the subscribe message to the publisher over MSMQ, the publisher would then send any relevant messages to your java subscribers input queue. But you would need to receive those manually also.
I guess you're then committed to using MSMQ as your transport layer for your entire bus also.