What kind of arguments one should use when choosing between integration using web service vs JMS? I'm familiar with basics of both approaches however in some cases it is unclear as to which one would be the best for a given situation. I guess I'm looking for a high overview comparison with use cases.
thanks
JMS is a messaging service. It is asynchronous and 2 directional, i.e. you can write application that both sends and receives messages. But this must be application implemented typically in java. I mean it cannot be thin client. And standard protocol of JMS is TCP based, so it may be blocked by firewall.
Web service is designed as a transport over HTTP, so it typically passes firewalls. But it is one directional: client calls server; server cannot call client. It just can response client's calls. Client of web service (especially RestFull web service) is very simple, so it can be easily implemented as a thin client (e.g. AJAX client).
Good question.
I will use Web Service when:
1. Dealing with cross domains, typically services environment when I am not sure about the client technology.
2. Need Synchronous response.
And pickup Messaging when (Hope you mean Messaging not just Java version):
1. Need Asynchronous request/response.
2. High Availability.
3. Confirmed Delivery.
Related
Hi there we are planning on integrating a websocket server implementation as frontend to our RabbitMQ systems. Currently we are running some Java/Groovy/Grails based apps which use the RabbitMQ server.
We would like to have a simple websocket server implementation that handles connections etc and that passes the request to our RabbitMQ layer.
Clients (hardware devices) would connect to a websocket layer that handles the request to RabbitMQ. Some other process takes on the job of handling the request and places back data in the queue if needed so that RabbitMQ is able to pass the data via websockets back to the client.
I am a bit lost in the land of websockets so i am wondering what other people would advise to use.
You can use rabbitmq itself with the webstomp plugin and sock.js for web frontends. You can expose this directly or via something like haproxy.
http://www.rabbitmq.com/blog/2012/05/14/introducing-rabbitmq-web-stomp/
In version 3.x it is now included by default, just enable the plugin.
For Java there are a couple of choices:
Atmosphere
Vert.x
Play 2.0
Netty directly
There are so many ways to skin the cat. Atmosphere will probably get you the furthers if you already using Grails. You will have to write a custom Broadcaster IIRC there is not one for RabbitMQ but you can just copy one of the existing ones.
Also with RabbitMQ or any queue your going to have to decide whether your going to make queues for each for each user (browser using websocket) or your going to aggregate based on some hash and then dispatch internally (ie make a giant map of mailboxes). Akka would be a good choice for mapping to mailboxes.
Does the webservice adaptor's function is let different webservice(eg,http/jms) can call each other?Does it like a proxy such as transform soap/http webservice to soap/jms webservice?
enter link description here
In the picture there exist three webservice,webservice-1 and webservice-1 are published by third part,adaptor-A and adaptor-B are used to call them,webservice-3 is published by adaptor-c.first,when someone call webservice-3,the adaptor-c intercept the soap request and send it to esb ,the esb have a broadcast router and the router send it to adaptor-A & adaptor-B,adaptor-A & adaptor-B then analyse the message and call webservice-1&webservice-2.after that adaptor-A & adaptor-B send webservice response to esb,esb also have a aggregator in it,then aggregator assemble these two response and send it to adaptor-c,At last,adaptor-c send the final result to webservice-3 user!
I want to if this flow is feasible?if feasible,how to design the adaptor-A and adaptor-B and adaptor-c?
yes, this is well suited scenario for an ESB. When your adapters don't implement a special business logic and are only responsible for "speaking" the protocol expected by the Web service, you can probably connect the services directly to the ESB. This kind of "protocol virtualization" is basically provided by all kinds of ESBs, even plain Web service stacks like Axis2 or CXF can deal with a large set of transport protocols.
Regarding the business logic there are different possibilities. For simple scenarios you can consider using a EIP-aware framework like Apache Camel and chain Enterprise Integration Patters (EIP) [Hohpe et al] to achieve the desired integration. For more complex scenarios you can consider using BPEL (Business Process Execution Language). BPEL is descriptive parallel programming language with focus on orchestrating Web services in a transactional, long-running fashion. BPEL can be executed e.g. by Apache ODE.
We are currently are at a stage in our product lifecycle where we are thinking about moving to Web Services. Our system is written in Java which consists of a number of client and server applications which talk to one another over TCP Sockets and also has in-line SQL to perform data retrieval and updates (yuk! I know) which uses our own SQL Connection class which then uses the java.sql.Connection to connect to a SQL Server database using the Microsoft JDBC driver.
The applications bind to one another using TCP sockets. They request data from and push data to one another. Which works perfectly fine.
Thought
So we are looking at converting all data access and TCP communication to a web service.
The web service would be designed to run on a companies secure internet site. The idea would be that users could connect their clients to the web service from home - when they are not on the company network - or at work, when they are.
The client applications would send/recieve the messages to/from the server side applications using the web service.
The client applications would retrieve and update data in the database using the web service.
Question
I would just like to know what peoples experience is of doing anything with 2 way communication (request and push) over a web service (if possible) and what the thoughts are about doing this.
Converting the data access to a web service seems straight forward enough - I can forsee some issues with performance where large data sets are retrieved in some parts of the system.
I am looking through various reading materials on the matter as it is a while since I have touched web services (using C# and ASP.NET). Currently reading "Building Web Services with Java™: Making Sense of XML, SOAP, WSDL, and UDDI". I must admit I thought web services were always stateless but have just read that they are not!
Thanks,
Andez
It helps to think of WebServices as being the same as any other web application on the transport layer. It uses HTTP/HTTPS protocols in the same way, it's just that instead of sending HTML, it sends XML according to a predefined format (SOAP). As such:
It's Request/response oriented
Can be stateful in the same way as a web-page can be stateful, using sessions (assuming you have a web-service client that supports maintaining session cookies across requests)
All requests eventually boil down to good old-fashioned servlet endpoints in the server
Keeping these limitations and features in mind, think about your requirements and how they map against each other. If you need true two-way communication (push), then web services are not ideal. They are client/server, request/response oriented. The achieve push, you would have to poll from the client. A possible alternative could be to let both the "server" and the "client" act as web service "servers". That would mean bundling some light-weight servlet engine with the client (like jetty) so the "server" could make web service calls TO the "client". Another way is to look at two-way RMI/IOOP.
Yet another way would be to keep the communication layer as you have it today. There is no inherent gain in refactoring to Web Services just for the sake of using web services. If they don't add any benefit, it's just waste. As you already mentioned yourself, Web Service comes with a load of additional overhead (verbose protocol, servlet engine etc), so it really needs to balance the extra cost and development time with a clear benefit. As the saying goes "if it's not broken, don't fix it". As you say the current solution "works perfectly fine", I would probably not change it. That's just me though.
What is the best way to provide an asynchronous service interface to multi-platform (primarily java and .net) clients? The backend service is implemented in java.
We are looking at asynchronous web service and message queues, but apparently cross platform asynchronous web service* is not supported yet in java (as far as I know) and for message queues, I was not sure which codec/protocol would be best.
*:Cross platform asynchronous web services can be described in WSDL 2.0, but not in WSDL 1.1 (As far as I understand). Now, JAX-WS 2.x does support asynchronous web service, but not WSDL 2.x. So I'm assuming that JAX-WS asynchronous web service's clients have to be JAX-WS clients, and that we can not use.
Thanks in advance!
EDIT: The difficulty here is that the service is asynchronous, and we prefer a callback based interface for efficiency (so we don't want to use 2 calls on a synchronous WS interface, etc.)
If its messaging, than use a Messagequeue system. like ZeroMQ. they are all cross platform.
otherwise we do it with .net WCF, and use JaxWS from java to test, that the interface is compatible.
Don't know, what's best, but SOAP is a good choice for a Java backend. The messages are xml based (e.g. not restricted to Java platforms) and it is widely used so you get a lot of support, tools and libraries on the net.
Another idea that might fit your needs: XMPP.
It is definitly asynchronous, client sending a service request (wrapped in a xmpp message) is the callback and doesn't wait for an immediate answer. I've used in a scenario where I send 'service request' from a xmpp client to a server and received the answers, immediately or a bit later, depending on the complexity of the calculation. This was a human-machine interaction but machine-machine should be even easier.
I'm in the process of writing a client/server application which should work message based. I would like re-use as much as possible instead of writing another implementation and curious what others are using.
Features the library should offer:
client and server side functionality
should work message based
support multi-threading
should work behind load balancer / firewalls
I did several tests with HTTPCore, but the bottom line is that one has to implement both client and server, only the transport layer would be covered. RMI is not an option either due to the network related requirements.
Any ideas are highly appreciated.
Details
My idea is to implement a client/server wrapper which handles the client communication (including user/password validation) and writes incoming requests to a JMS queue:
#1 User --> Wrapper (Check for user/password) --> JMS --> "Server"
#2 User polls Wrapper which polls JMS
Separate processes will handle the requests and can reply via wrapper to the clients. I'd like to use JMS because:
it handles persistence quite well
load balancing - it's easy to handle peaks by adding additional servers as consumer
JMSTimeToLive comes in handy too
Unfortunately I don't see a way to use JMS on it's own, because clients should only have access to their messages and the setup of different users on JMS side doesn't sound feasible either.
Well, HTTP is probably the best supported in terms of client and server code implementing it - but it may well be completely inappropriate based on your requirements. We'll need to actually see some requirements (or at least a vague idea of what the application is like) before we can really advise you properly.
RMI works nicely for us. There are limitations, such as not being able to call back to the client unless you can connect directly to that computer (does not work if client is behind a firewall). You can also easily wrap your communication in SSL or tunnel it over HTTP which can be wrapped in SSL.
If you do end up using this remember to always set the serial version of a class that is distributed to the client. You can set it to 1L when you create it, or if the client already has the class use serialver.exe to discover the existing class's serial. Otherwise as soon as you change or add a public method or variable compatibility with existing clients will break.
static final long serialVersionUID = 1L
EDIT: Each RMI request that comes into the server gets its own thread. You don't have to handle this yourself.
EDIT: I think some details were added later in the question. You can tunnel RMI over HTTP, then you could use a load balancer with it.
I've recently started playing with Hessian and it shows a lot of promise. It natively uses HTTP which makes it simpler than RMI over HTTP and it's a binary protocol which means it's faster than all the XML-based protocols. It's very easy to get Hessian going. I recently did this by embedding Jetty in our app, configuring the Hessian Servlet and making it implement our API interface. The great thing about Hessian is it's simplicity... nothing like JMS or RMI over HTTP. There are also libraries for Hessian in other languages.
I'd say the best-supported, if not best-implemented, client/server communications package for Java is Sun's RMI (Remote Method Invocation). It's included with the standard Java class library, and gets the job done, even if it's not the fastest option out there. And, of course, it's supported by Sun. I implemented a turn-based gaming framework with it several years ago, and it was quite stable.
It is difficult to make a suggestion based on the information given but possibly the use of TemporaryQueues e.g. dynamically created PTP destinations on a per client basis might fit the problem?
Here is a reasonable overview.
Did you tried RMI or CORBA? With both of them you can distribute your logic and create Sessions
Use Spring....Then pick and choose the protocol.
We're standardizing on Adobe's AMF as we're using Adobe Flex/AIR in the client-tier and Java6/Tomcat6/BlazeDS/Spring-Framework2.5/iBATIS2.3.4/ActiveMQ-JMS5.2 in our middle-tier stack (Oracle 10g back-end).
Because we're standardizing on Flex client-side development, AMF and BlazeDS (now better coupled to Spring thanks to Adobe and SpringSource cooperating on the integration), are the most efficient and convenient means we can employ to interact with the server-side.
We also heavily build on JMS messaging in the data center - BlazeDS enables us to bridge our Flex clients as JMS topic subscribers. That is extremely powerful and effective.
Our Flex .swf and Java .class code is bundled into the same .jar file for deployment. That way the correct version of the client code will be deployed to interact with the corresponding middle-tier java code that will process client service calls (or messaging operations). That has always been a bane of client-server computing - making sure the correct versions of the respective tiers are hooked up to each other. We've effectively solved that age-old problem with our particular approach to packaging and deployment.
All of our client-server interactions work over HTTP/HTTPS ports 80 and 443. Even the server-side messaging push we do with BlazeDS bridged to our ActiveMQ JMS message broker.