Develop Reference

Difference between AMPS(Advanced Message Processing System) and JMS

What is the difference between the 2 because both of them are based on the same methodology of publishers and subscribers who exchange messages between them via topics/subjects?

I recently came across this post and, as an employee of 60East Technologies, felt that it deserved a more complete response.
If you're asking in terms of "what role in an architecture do these serve", then you're right: both of these fall in the broad category of message-oriented middleware. They're both ways to coordinate and exchange data between processes based on the concept of messages as the units of data exchanged.
JMS is a standard API for Java, and one of the more popular ways of handling messaging. There are multiple implementations from multiple vendors. Since it's a standard, these are all similar in interface and have distinct implementations. Products that support JMS can also support wire standards such as AMQP to provide a level of interoperability for components that aren't written in Java.
AMPS (Advanced Message Processing System) is a bit less widely-known. It's a messaging product developed by 60East Technologies, Inc. Since it's a product rather than a standard, there's one implementation. It's a broker-based system, so in AMPS all message traffic passes through the broker. AMPS supports multiple programming languages (right now, there are clients available for Java, C#/.Net, Python, JavaScript, and C++). AMPS supports a variety of message payload formats (FIX, JSON, XML, Protocol Buffers, MessagePack, etc.). AMPS also supports a few different styles of message delivery: message queues (as JMS does), fan-out publish and subscribe, "query and subscribe" where an application gets current values for a set of records and then receives push updates when the records change, and historical replay ("bookmark subscribe") that exactly replays a stream of messages any number of times. AMPS also provides things like inline message transformation/enrichment, the ability to aggregate messages and project views (similar to the way an RDBMS can project a view of an underlying table).
AMPS was initially designed for very high-volume and low-latency applications (things like crossing engines/crossing networks in the financial sector). AMPS emphasizes performance, and takes a "whole-system" view of performance. That is, performance is considered from the point at which a producer starts to send a message to the point at which a consumer can act on the message, not just with regards to time in the broker.
To sum it up: AMPS is a product rather than a standard, supports multiple programming languages, provides a wide variety of capabilities and beyond message queues, and is designed for very high performance
Ryan
60East Technologies

JMS is a Java-based API for asynchronous messaging supporting both point-to-point and pub-sub semantics. It can be implemented by anyone. Apache ActiveMQ is probably the most popular and well-known JMS implementation, although there are numerous implementations.
AMPS is a proprietary messaging system developed by 60East Technologies which appears to only support pub-sub semantics.

Comparing JMS to AMQP

I was googling around to search for what makes them different. I have used RabbitMQ and ZeroMQ for some of my projects. Knowing that JMS still exists and people use it I begin to wonder why? What motivates the usage of JMS are there any performance, architectural, or any advantages? I have no knowledge of JMS but if what I understand is true why would somebody bound himself to a java specific technology?

JMS and AMQP aren't really comparable. JMS is an API; AMQP is a protocol. It is possible to write a JMS implementation that uses AMQP. Indeed, people have.
Moreover, it is possible to write JMS implementations that use other protocols - and of course, numerous people have.
The goal of JMS is to put a uniform API over all these different messaging protocols. This makes life easier for programmers, who can learn one API, and then have a reasonable chance of using any message queue they come across.
In addition, the existence of a standard API allows JMS to interact with other standards. For example, in ejb, there is such a thing as a message-driven bean, which is an EJB which receives messages rather than method calls, and uses the JMS API to control the process.

How JMS Relates to Service Buses

I'm trying to wrap my brain around JMS and have been reading up on some very helpful sources and examples. I'm now trying to see the "big picture" here and put all the theory behind JMS into a practical context where real enterprise technologies are used.
So here we have four elements: (1) JMS - a Java API for MOM, (2) ActiveMQ - one of the many JMS implementations, (3) EIP - an intriguing and mysterious beast I am only beginning to understand, and finally, (4) Apache Camel, an open source implementation of that beast.
I am trying to now relate these components together to see JMS (and, in general, enterprise-class messaging) in action.
I guess the first thing I'm looking for is a simple and concise definition for what EIPs are. They seem to be a whole set of design patterns for how MOMs should behave, but since I'm already fuzzy on the concept of messaging to begin with, this is just a fuzzier definition being added on top of an already-fuzzy understanding of some pretty hardcore concepts.
Even if I don't "get" what EIPs are, I do "get" that frameworks like Camel, Mule and ServiceMix implement them and allow server-side components ("endpoints") to message each other efficiently.
Most important to this question is my understanding of how these four components relate to one another. I think understanding this will help me connect most of the dots; well, the important ones anyway.
So in the diagram above I labeled all 6 possible relationships and refer to them below:
JMS:ActiveMQ - I understand ActiveMQ to be an implementation of JMS, much like Hibernate is an implementation of JPA. Is this correct?
ActiveMQ:Camel - Camel has the ability to push messages to any JMS implementation, such as ActiveMQ. In this case ActiveMQ is a camel endpoint. Correct?
EIP:Camel - Camel is an implementation of EIPs. Understanding what EIPs are in the first place is also important to my understanding of this entire setup.
EIP:JMS - Although there may not be a direct connection between these two, it seems as though messaging is at the core of EIP, and JMS is Java's foundation for messaging. Is this a fair assessment?
I left relations between EIP:ActiveMQ and JMS:Camel in case there are any "big concepts" that I should be aware of between these systems.
Any help in putting a simple-to-understand definition to EIP and in understanding how all these components relate to each other is greatly appreciated. Thanks in advance!

ActiveMQ is an implementation of a MOM. It provides a client-side implementation of the JMS API for use by JVM languages. JMS is just an API, but implementations are tied to whatever broker they talk to by a wire format, so you can't use the ActiveMQ JMS implementation to talk to WebsphereMQ, for example. There exist other APIs to talk to ActiveMQ from other language platforms - C/C++ via CMS, .Net via NMS. You can also talk to ActiveMQ via other "non-JMS-like" mechanisms, such as via the STOMP protocol which has client libraries in Ruby, Javascript and others.
Yes.
Yes and no. Camel uses the same "language" as EIPs, so by using Camel, you naturally pick up the EIPs. Having said that, knowing them lets you know what you are looking for in the API. I recommend Camel in Action to get a good understanding of the two, and refer to the EIP site (http://www.eaipatterns.com/) when you want to get a bit more info.
Again yes and no. There are a number of patterns implemented via messaging (JMS is only one flavour), but there are a large number of patterns that have a much broader application (e.g. Splitter, Aggregator). Have a look through the EIP site index to get a feel for this.
Camel can talk to other systems using it's JMS component, which uses any underlying messaging provider that supports that API (Websphere, Sonic, OpenMQ etc.). It can also talk over other messaging technologies, such as those that support the AMQP API.
Hope that helps.

Java standard for client/server communication

What is the "official" Java API for client/server or P2P communication? Java RMI? Some other networking API??
Is this official networking API the standard for both SE and EE?
I'm sure the answer is very context-specific, so let's take a look at a few instances:
You have 2 swing clients installed on 2 machines and connected to the same network (or the Internet), and you want either of them to send the other a primitive, such as the integer 4, or some POJO, like a "Widget" object
Same as #1 above, but between a Swing client and a fully-compliant Java EE back-end (implementing managed beans, app servers, the whole nine yards)
I don't have a specific application in mind, I'm just wondering what are the "norms" for client-client and client-server communication in the world of Java.

If being bound by Java isn't a problem, RMI is a pretty abstracted solution when it comes to the client and server solution "exchanging" data (especially when the data is Java classes which might be difficult/too much effort to represent as textual data). Just make sure your object implements Serializable and almost anything can be transmitted over the wire.
If this doesn't fit your bill and you want to drop down the raw networking stuff, the client-server socket framework Netty is a pretty good choice.

There's no such thing as the most official networking API in J2SE, all J2SE APIs are official in the sense they are supported by Sun (now Oracle).
That said, you should choose your API based on following criteria:
Do you (or your team) know how to use particular API;
How simple/complex is this API to use;
What throughput are you aiming for? For performance-sensitive applications you may be forced to use binary protocol. For the rest of cases, you can use text-based protocol.
For example, between two clients simple text-based protocol will suffice for passing POJOs, for example using Apache MINA or Google protocol buffers.
This will work between client and server as well.
Response to Zac's questions in comment:
Binary protocols performance gain comes from the fact you don't need to convert everything to text form and back -- you just can pass binary presentation of you application memory with minimal changes, like, in case of BSD Sockets API, converting from host byte-order to network byte-order. Unfortunately, I don't know details about how RMI/Java serialization processes objects, but I'm sure, it still much faster than passing all data in readable form;
Yes, MINA and protocol buffers have Java APIs. They just not part of Java SE bundle, you have to download them separately. By the way, MINA can use both binary and readable serialization, depending on how you use it.
You should define notion of 'good' somehow, for example, answering to questions I mentioned above. If you want to use objects over network, use RMI. If you don't, Netty or MINA will suffice, whatever you'll find easier to master.

For P2P, Sun at one point pushed JXTA pretty hard.
I wouldn't dare to use RMI for P2P communication.

rmi is pretty much the standard java to java protocol. it's built in and very simple to use. most j2ee backends also communicate using rmi, although that's not the only possibility.

J2SE the most common is probably RMI or raw sockets.
J2EE uses a messaging bus that everyone (servers and clients) subscribes to which is quite different from rmi style solutions (although at the lowest level an implementation may still rely on RMI). It helps automate redundancy and failover. If you need this functionality I believe it can be used in SE as well.
I haven't used J2EE for quite a while now, so this may have changed, but I doubt it. The messaging system was a core component of J2EE.

What is the difference between Java RMI and JMS?

When designing an distributed application in Java there seem to be a few technologies that address the same kind of problem. I have briefly read about Java Remote Method Invocation and Java Message Service, but it is hard to really see the difference. Java RMI seems to be more tightly coupled than JMS because JMS uses asynchronous communication, but otherwise I don't see any big differences.
What is the difference between them?
Is one of them newer than the other one?
Which one is more common/popular in enterprises?
What advantages do they have over each other?
When is one preferred over the other?
Do they differ much in how difficult they are to implement?
I also think that Web Services and CORBA address the same problem.

You already know about method calls. What if the object that you want to invoke the method on is on a different computer? You use RMI to send the call from one computer (client) to the other (server). The client will wait (or "block") until the result comes back from the server. This is called synchronous operation.
JMS is different: it lets one computer send a message to another - like email. The first one doesn't have to wait for a response: it can keep doing whatever work it wants. There may not even be a response. The two computer systems don't necessarily work exactly in step, so this is called asynchronous.
Another way of thinking about the difference: RMI is like making a phone call, and JMS is like sending a text message.
RMI is a little older than JMS, but that's not really relevant. The two concepts are much much older than java.
There's not much difference in the complexity. I think that you should try doing a tutorial on each one. RMI and JMS
If you're starting a project from scratch, and you're not sure which one to use, then probably the synchronous/asynchronous issue is the best decision factor. If you're working on an existing system, it's probably best not to introduce too many new technologies. So if they're already using one, then I'd suggest it's probably best to stick with that one.

You cannot really compare the two, its apples and oranges.
RMI is a form of Remote Procedure Call (RPC). It is a lightweight, Java specific API that expects the caller and receiver to be available at the time of communication.
JMS is a reliable messaging API. JMS providers exist for various messaging systems. Messages can be passed even if one of the parties is not available if the provider implements that. The two I am familiar with are TIBCO and IBM MQ.
RMI doesn't deal with guaranteed delivery or asynchronous responses, JMS may, depending on the provider.
JMS allows loose coupling in the sense of availability.
"Web Services" allows loose coupling in the sense of protocol and data but doesn't specify much in the way of reliable messaging, though some implementations do include this (Windows Communication Foundation) and some don't.
EDITED: Revised per comments. When I wrote this answer in 2010 my experience was actually with only one JMS provider and I didn't actually know there was no default JMS provider.