I plan to implement the message bus where messages would be produced in .Net Core application but consumer applications are to be running on Android devices and written on Java. In initial approximation publisher application will know nothing about consumers. Java tablets will subscribe to message bus, receive messages and unsubscribe from bus. It looks like I'll need to dynamically create queue for each of the Android tablets, bind it to fanout exchange and send messages to the exchange or something like that. For .Net there is the MassTransit framework that already have all this stuff but I am not aware of Java and Android Studio capabilities. I am curious is there any way or a workaround to implement MassTransit consumer application on Java? I've been googling about 2 hours and didn't find any info but I assume that my search requests were incorrect.
MassTransit uses JSON by default for messages, the structure of which is documented on the web site. You can also send raw JSON messages if the envelope structure used by default is unnecessary.
As for how to consumer RabbitMQ messages from an Android device, I don't have any input there. Surely there is a client SDK.
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 understand Java JMS API provides the support for producing and consuming messages asynchronously.
For example, I will implement JMS producer using java and send messages to the JBOSS Message(Destination).
let say the external application say .net applicationin the distributed environment want to consume the messages by connecting to the JBOSS Message(Destination)
Is that possible?
There are several JMS message types:
BytesMessage: can be read by anybody
TextMessage: ditto
StreamMessage: can be read by anybody who can read network-ordered primitive types
ObjectMessage: these are serialized objects and can only be read by Java
MapMessage: these are essentially maps; ditto
JMS itself isn't a message broker, just an API to an existing broker.
If your Java code and the non-Java code can agree on a byte- or text-based message format, you can interchange message between them.
JMS only defines the API an application can use to send and receive messages. It doesn't define a wire format. So it depends on the messaging system you use. JBoss uses HornetQ (since JBoss 6, IIRC), and HornetQ supports other wire formats, namely STOMP and AMQP. It also allows to use REST to send and receive messages.
But, as it is so often the case with interoperability, you'll have to limit yourself for this to actually work. You can't exchange all message bodies (as EJP has elucidated) and probably not all message headers and properties.
Reading a book about it at the moment.
You will need a JMS server that can be accessed through .Net services (either directly or because your JMS can be configured to send the messages to a .Net MOM *).
In any case, it would not be part of JMS but a capability of a particular product. JMS was developed with the intention of being "generic enough" to work in this scenario, but it is up to the specific server implementation (and configuration) to support it (or not).
MOM: Message Oriented Middleware
on a technical level any message over a protocol can be read regardless of message since its all converted to 0's and 1's at some point. However, because JMS are java interfaces you technically wont be using JMS even if you read the messages that way - JMS is the java way to read those messages by using java JMS interfaces and classes that extend those interfaces
I am trying to understand the basics of Message Queues. I see that there are many implementations available as libraries for MQs (ActiveMQ, RabbitMQ, ZeroMQ etc). Also J2EE enabled servers provide such support I think.
What I fail to understand about the topic, is how are these kind of constructs used by real software. I mean what kind of messages are usually being exchanged? Strings? Binary data?
If I understand correctly one can configure the transport protocol, but what is usually the application data format?
Is it a new way of communication, like e.g. SOAP WS or REST WS or RPC etc where each has a different application msg format?
Message queues usually using for application integration. In enterprise it is usually used to implement ESB, but nowadays there are smaller application systems that utilize similar patterns.
Concerning data being transmitted - usually it is XML messages, but actually depends on applications and MQ software - some of them are able to handle binary messages, some are not.
For example imagine you have two applications which require data interchange. If you integrate them using some kind of messaging software such as ActiveMQ, for example, then it will give you some benefits like routing, fault-tolerance, balancing, etc, out-of-the-box.
You may integrate your applications using MQ directly, but ESBs usually
give you ability to use web services: app just calls ws of ESB and knows nothing about underlying architecture.
Also MQs and ESBs gives you a level of abstraction: you may switch your apps in a system absolutely transparent, as long as data exchange interface is preserved.
MQs are mainly used for interprocess communication, or for inter-thread communication within the same process. They provide an asynchronous communications protocol, meaning that the sender and receiver of the message do not need to interact with the message queue at the same time. Messages placed onto the queue are stored until the recipient retrieves them.
wikipedia can be good intro to topic. http://en.wikipedia.org/wiki/Message_queue#Standards_and_protocols
Also, to understand diff between webservice and mq, read this thread: Message Queue vs. Web Services?
I am currently trying to research how to use Android with an existing java based system. Basically, I need to communicate to/from an Android application.
The system currently passes object data from computer to computer using ActiveMQ as the JMS provider. On one of the computers is a display which shows object data to the user.
What we want to do now is use a phone (running Android) as another option to show this object data to a user with wifi/network access.
Ideally we would like to have a native application on the Android that would listen to the ActiveMQ topic and publish to another Topic and read/write/display the object data, but from some research I have done, I am not sure if this is possible.
What are some other ways to approach this problem? The android Phone needs to be able to send/receive data. I have been using the AndroidEmulator for testing.
A quick and dirty way would be to have your JMS pushes the data to a XMPP/Jabber server and use a XMPP library like Smack API on the Android to connect. The advantage of this approach is that
You can emulate the point-to-point and pub/sub in JMS.
XMPP is quite extensible so what you can do is instead of carrying your payload as 'chat' text, you can create your own namespace within the XMPP packet. For data portability, you can use a lightweight like JSON in the namespace.
XMPP will handle your presence for you so your app don't have to keep track of services if they are online.
There is a nice article here that shows you how to use Smack on Android.
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.