I'm new to Java EE and have been looking for a common way to implement a publish/subscribe type model without having to use JMS. I'm interested in creating a simple app that displays strings as they are push from the server to the client. I want to investigate was of doing this without polling to reduce unnecessary requests. The events would be varied quite a bit so I don't think polling over a set amount of time would be the best solution but the client should display the event immediately.
I've read about different ways of doing this outside of Java EE such as HtML5 with sockets api. But I want to know how to do this in Java EE, I'm assuming there is something very common that does this but I have not come across it yet. Really I'm just looking for the technology name so that I can do further research on its implementation.
Maybe Hazelcast is worth for you to have a look at. It offers an easy to use Distributed Topic feature for publish/subscribe messaging.
A simple example from the docs:
import com.hazelcast.core.Topic;
import com.hazelcast.core.Hazelcast;
import com.hazelcast.core.MessageListener;
public class Sample implements MessageListener {
public static void main(String[] args) {
Sample sample = new Sample();
Topic topic = Hazelcast.getTopic ("default");
topic.addMessageListener(sample);
topic.publish ("my-message-object");
}
public void onMessage(Object msg) {
System.out.println("Message received = " + msg);
}
}
I'll answer only the Java EE part, as I'm not familiar with the Apple technology you quoted.
It seems to me enterprise Java is not appropriate for this kind of task. The main use case for a Java EE application is: "lots of users do lots of small, mostly independent tasks on a centralized application". Java EE provides means for the central application to scale to any number of users. And it's mostly users who initiate and steer the dialogue.
Your use case, however, requires the server to be the active part. You can, of course, run almost any kind of logic on a Java EE application server, asynchronous tasks, too, but it doesn't mean you should.
I am not an expert on this topic but since no one has answered I will try to explain what I know.
First of all J2EE uses JMS spec as its fundamental publish/subcribe mechanism. There are various JMS brokers out there. The important point here is that some of these brokers are not specifically tied to any J2EE application server and can work stand alone. Check out Apache's ActiveMQ and it works well as a standalone JMS broker. It has bindings to many languages a well. So you can freely compose a non J2EE architecture using a JMS broker.
Second, there are other message queue brokers that comply to other standards that can be used within a J2EE architecture as well. DDS (Data Distribution Service) is an example. It is an OMG standard and has bindings for Java and can be used in a J2EE architecture if desired.
Third, Web Services standards define a WS-Notification Broker standard. Again this is not part of J2EE as far as I know but is supported by many SOA providers.
So you have many alternatives that can be freely mixed in J2EE architecture.
I hope this helps.
Redis has a Publish/Subscribe mechanism that may be of interest: http://redis.io/topics/pubsub
Related
I have 2 processes that need to communicate over the same PC and different PCs. In the local case the process communication is among different processes e.g Process A and Process B.
In the remote case it will be among 2 instances of Process A running in different PCs.
I will create them from scratch and I am wondering what is the best approach. I am aware of RMI and sockets but I was wondering for my case as described, and taking also into account that the messages exchanged are small and the number of APIs really small, if there is a standard approach/library for this.
Any suggesstions are highly welcome
Update after #EJP comments:
My interest is 1)to implement the requirement for communication in a light manner since the API exposed will be really small and the messages as well 2)use and learn a new popular framework if possible (I already know RMI and sockets)
If you are just looking for messaging frameworks, there's a bunch available out such as
RabbitMQ - http://www.rabbitmq.com/
ZeroC Ice - http://www.zeroc.com/ice.html
AMQP - http://www.amqp.org
OpenSplice DDS - http://www.prismtech.com/opensplice
But when you use a 3rd party framework, you are then adding an additional dependency to your application. If it is something very simple like your case, perhaps writing a TCP client/server would be sufficient for a client/server paradigm or if you are looking for publisher/subscriber paradigm then you can look into using UDP multicast. You just need your data class to extends Serializable if you want to be able to marshal and unmarshal your data to buffer and send it over to network using typical JAVA socket API.
I strongly suggest having a look at Thrift. From all the technologies I've used (web services, RMI, XML-RPC, Corba comes to mind) it is currently my favourite. Essentially the steps involved are:
Download the Thrift compiler.
Add the Maven dependency (make sure it is the same version as the compiler!) I currently use 0.8.0.
Write your Thrift IDL (incredibly easy, google for it as there are plenty of examples).
Compile it for Java.
Writer your server/client.
In general, you can whip together a server and a client in about 30 lines of code. In terms of speed and reliability it has never failed me before.
You might have a look at Versile Java (full disclosure: I am one of the developers), it satisfies at least your criteria #1. From the API documentation, here are some examples of writing remote-enabled objects, running a service, and connecting to a service.
If you want to learn something new then I'd look at OpenSplice. The reason is pretty simple, among the technologies suggested above is the only one that provides you with Data-Centric abstractions.
The cool thing about OpenSplice is that gives you the abstraction of a Global Data Space, yet the implementation of this global data space is fully distributed and very high performance.
Take a look at some of the slides available at http://www.slideshare.net/angelo.corsaro and I am sure you'll get in love with the technology.
Finally OpenSplice is Open Source.
Happy Hacking.
A+
JMX is a good alternative .
Example :
http://www.javalobby.org/java/forums/t49130.html
IMB JMX Example
http://alvinalexander.com/blog/post/java/source-code-java-jmx-hello-world-application
Our frontend is simple Jetty (might be replaced with Tomcat later on) server. Through servlets, we are providing a public HTTP API (more or less RESTful) to expose our product functionality.
In the backend, we have a Java process which does several kind of maintenance tasks. While the backend process usually does it own tasks when it's time, now and then, the frontend needs to wake-up the backend to execute a certain task in the background.
Which (N)IO library would be ideal for this task? I found Netty, Grizzly, kryonet and plain RMI. For now, I am inclined to say Netty, it seems simple to use and it is probably very reliable.
Does any of you have experience in this kind of setups? What would your choice be?
thanks!
Try to translate this document which answer to your question.
http://blog.xebia.fr/2011/11/09/java-nio-et-framework-web-haute-performance/
This society, as french famous Java EE experts, did a lot of poc of NIO servers in the context of a french challenge sponsored by VmWare (USI2011). It was about building a simple quizz app that can handle a load of 1 million connected users.
They won that challenge with great results.
Their implementation was Netty + Gemfire and they only replaced the CachedThreadPool by a MemoryAwareThreadPool.
Netty seems to offer great performances, and is well documented.
They also considered Deft, inspired by Tornado (python/facebook) but it's still a bit immature for them
Edit: here's the translated link provided in the comments
My preference is Netty. It's simple yet flexible. Very fast and the community around Netty is awesome.
The company I work for is currently evaluating CoralReactor. It is a commercial software but it has the easiest API I have ever seen for Java NIO. My personal opinion is that Netty makes things too complicated, especially if you want to go garbage-free and single-threaded, which are a requirement for many companies from the finance, advertisement and game industry.
I would decouple them by using JMS, just have some (set of) control queues your backend sits there listening on and you're done. No need to write a custom nio api here.
One sample provider is hornetq. This can be run as an in process jms broker as well, it uses Netty under the covers.
Let's say I have many web services (REST or normal HTTP request) and I want to define in which order they should be called. I want the order to be easily configured (through XML files) and return error responses in case they are called in the wrong way.
When I say tools I mean some framework in Java. The framework should have good documentation with examples.
I don't want only a name but I would like pros/cons - why should I choose one or another.
EDIT: I forgot to mention it has to be an OpenSource (or any free licence for unlimited usage). And the application will probably run on GoogleAppEngine or Tomcat.
If you want to orchestrate long running processes then what you need is a BPEL engine.. if not you can go for an Enterprise Service Bus..
WSO2 ESB is an open source Enterprise Service Bus and WSO2 BPS is a business process server built on top of Apache ODE.
eBAY using WSO2 ESB to process 1 Billion messages per day.
Disclaimer: I am an architect from WSO2.
You need a Service Bus.
Bea's Aqualogic was a good one.
Pros: integrated with weblogic, support XQuery for message manipulation. Has persistency queues. Flows are defined within it's user interface.
Cons: not so easy to use. Costly.
Regards,
M.
PS: On the pros I would add Bea's good support, but since now they're Oracle I doubt that quality will be high as in the past
EDIT: ops, OpenSource solution needed. So this answer was actually wrong. Sorry.
I am wondering how "WSO2 ESB" or "WSO2 BPS" will address the issues presented in the original question.
The more I look into that project the more it looks to me it is BPEL driven which will probably not play good with "REST/normal http".
I believe Apache Camel should be a good start point.
I am looking to exchange messages between Java classes which are running as part of different Java processes (or JVMs). For example: a Java class which has detected an event will wrap it up as a Java message and send it to an event handling class running inside a different Java process.
What's a simple and well established approach to such messaging? Since the messaging will always be between Java classes, I do not want the overhead of XML SOAP or the complexity of Corba.
Thanks
Neel
The standard solution would be JMS. But it seems its very heavy weight for your needs. I would suggest to write a small TCP layer using MINA or something and build a custom solution over it.
You might want to look at Spring-Integration. It has options for both external and internal messaging. You can use JMS, TCP packages, all kinds of stuff.
If you don't need the asynchronous aspect, simple RMI will do.
One option is Jini, now referred to as Apache River.
Jini will help with discovery and serialization. It allows you to call a method in one class from another class running in a different JVM.
Jini is fairly elegant. It's easy to specify which methods are exposed to remote callers. Exceptions from the called method are communicated as exceptions to the caller. Discovery supports painless redundancy.
I come from a background of MoM. I think I understand ESB conceptually. However, I'm not too sure about the practical differences between the two when it comes to making a choice architecturally.
Here is what I want to know
1) Any good links online which can help me in this regard.
2) Can someone tell me where it makes sense to use one over the other.
Any help would be useful.
Messaging tends to concentrate on the reliable exchange of messages around a network; using queues as a reliable load balancer and topics to implement publish and subscribe.
An ESB typically tends to add different features above and beyond messaging such as orchestration, routing, transformation and mediation.
I'd recommend reading about the Enterprise Integration Patterns which gives an overview of common patterns you'll tend to use in integration problems which are all based above a message bus (though can be used with other networking technologies too).
For example using open source; Apache ActiveMQ provides a loosely coupled reliable exchange of messages. Then you can use Apache Camel to implement the Enterprise Integration Patterns for smart routing, transformation, orchestration, working with other technologies and so forth.
I put MOM solutions and ESB solutions on two distinct planes.
I consider MOM a building block for ESB solutions. In fact, ESB solutions reach their own loose coupling and asynchronous communication capabilities, just using the paradigm offered by the specific MOM implementation.
Therefore, MOMs represent solutions for data/events distribution at customized level of QoSs (according to the specific vendor implementation), instead ESBs represent solutions providing capabilities to realize complex orchestrations in a SOA scenario (where we have multiple providers offering their services, and multiple consumers interested in consuming the services offered by the first ones).
Complex orchestrations imply communication between legacy systems, everyone of these with its own data domain representation (rules and services on specific data) and its own communication paradigm (one consumer interact with the ESB using CORBA, another one using WS, and so on).
It is clear that ESB represents a more complex architectural solution aimed to provide the abstraction of data-bus (such as the electronic buses that everyone have in his own pc), able to connect a plethora of service providers to a not well specified plethora of service consumers, hiding heterogeneity in (i) data representation and (ii) communication.
Sorry for the long post, but the concepts are complex and it is very difficult to be effective and efficient in a short statement.
An ESB is typically a layer that routes, logs, transforms, and performs other 'technical' (i.e. non-business) functions on messages. It could process messages from a messaging system (such as something JMS-based), or it could work with other types of message (such as SOAP-based web services). In that respect, it's more general than MoM.
Disclaimer: I am an IBM WebSphere consultant - although I am not contributing here in an official capacity.
ESB with web services in its true form provides Application loose coupling by sending the data through one the elements of the message.
MOM provides not only Application Loose coupling but process loose coupling along.
ESB comes with additional features supporting Governance centric approach.
Both can be used independently or together depending upon the scenario.
IBM and Oracle have SOA certifications. Since they're the leaders in the marketplace (Gartner Magic Quadrant), I would read about how they define SOA and ESBs (along with methodology and the components needed to support SOA like Governance, Registry, etc etc)
EBS is just yet another buzzword, as is SOA 2.0.
You can have a ESB system easily implemented with normal Web Services with a queue behind them.
You can have message routing and or orchestration with SOA 1.0 (Tibco, BizzTalk), one things does not stop the other really. More importantly, it is the semantics given to the messages exchanged in the system that play an important role, in this case events. Messages as events, are triggers about something that happened in your system, so the context is different.