We have an enterprise solution deployed on Wildfly 8.0.0 server, we intend to support CoAP and MQTT also as communication protocol. We explored extensively but we couldn't find even any oblique reference to our problem case. Is it possible to add CoAP and MQTT support without destabilizing Wildfly setup ??
I think theoretically it is possible to use a https://www.eclipse.org/californium/ within an EE server for CoAP.
The main issue here is that Californium listens to an UDP port (and sends datagrams too).
So if you want to stay within a EE specification, you'll have to implement a JCA adapter for that.
If you want things to just work, you can run/manage it from a JMX bean.
WildFly being a Web Server doesn't necessarily need to support CoAP or MQTT because those are not standard HTTP based Communication protocols but protocols designed to enable M2M (Machine to Machine) Communication.
As of WildFly 8.0.0.Final it only allows HTTP (Servlet, JAX-RS, JAX-WS), Web Sockets, HTTP Upgraded Remoting (EJB Invocation, Remote JNDI).
Related
I have started using Mobicents (aka Restcomm) sip servlets with Wildfly 10 but even i could not find a clear answers in documentation or anywhere else for questions i have below.
1) Do sip servlets support standalone-ha model such as in a sip dialog fail over scenario? For example in an established call, if node one fails will node to accept subsequent invites or return a 404 like response .
2) Is it required to use Mobicents (aka Restcomm) load balancer even if there is a sip load balancer in front of the servers ?
3) Does the sip application configuration,code etc.. change between standalone and standalone-ha mode? Or it is handled by Wildfly, ActiveMQ, Infinispan?
Thanks
1) Restcomm SIP Servlets on Wildfly 10 doesn't support replication yet. Only Restcomm SIP Servlets on Wildfly 7 supported product from TeleStax supports replication, Wildfly 10 is expected to be supported later this year.
2) Nope but you need to make sure your load balancer can support SIP Session affinity to always route messages from a given dialog to the same node.
3) No changes should be needed to the application. Only be conscious of what you replicate as it adds overhead in terms of network traffic and memory usage.
I need to implement a TCP server with a web interface included for management.
Basically, the tcp server will be listening to new connections and keeping current ones active while the web interface allow me to see information regarding these connections and to interact with them (e.g. send messages and seeing received ones)...
My concerns resides in the "TCP Server" integration with the web application.
For received messages I could simple use a shared DB, but I need to send messages to the peers connected into the TCP server.
My best bet is currently on JCA. Some research pointed me to a nice sample: http://code.google.com/p/jca-sockets.
The sample uses an Message Driven Bean to deal with messages received over port 9000, acting as an echo server.
I am new in the Java EE 6 world. I trying to figure out why things were done in one way or another in the sample (e.g. why MDB?).
JCA has a fairly complicated spec. So I am trying at first to adapt the sample above to keep the connections active to exchange data. My next step will be adapt it to accept a string over a servlet to forward it to a given peer.
Can someone help me out on this?
Well, first of all, using Java EE with TCP is not the best approach you may use. If you just need a simple TCP service with Web UI you'd better consider using Java SE with some web container attached (undertow works well).
In other hand, if you need your application to integrate into existing Java EE infrastructure your company has, JCA would be the best approach. While it's not designed for such kind of things, JCA is the only EE subsystem liberal enough for that kind of thread management you would need for TCP networking to work.
JCA-Socket you're referring above is not the best example of a JCA app. It uses plain Java's blocking sockets by blocking WorkManager thread, this is not very effective. Things got much better now and we have Java NIO and Netty for highly effective raw networking to work upon. I have a JCA connector for TCP interactions which may provide you a skeleton to build your own. Feel free to extend and contribute.
P.S. About MDB: message-driven bean is the only "legal" JCA approach of asynchronous incoming messages handling. Since TCP is asynchronous, you'll definitely need one in your application for all the things to start working. Outcoming data transfers happen through various ConnectionFactory interfaces you'll inject into your bean. The link above will provide you with a reference ConnectionFactory implementation as well as a simple tester app utilizing both ConnectionFactory and MDB messaging approaches.
I understand it's available since MSMQ 3.0, is it available via any of the .NET ESBs?
Is this possible with other MQ transports (ActiveMQ, etc)?
Thanks,
E.
NServiceBus use msmq as its main transport but does not support the http option for Msmq. Can you elaborate on what you're trying to achieve? Perhaps the NServiceBus gateway component is what you need?
http://docs.particular.net/nservicebus/gateway/
Hope this helps!
MassTransit does not support MSMQ over HTTP in any way. RabbitMQ only requires a single port open for communication but it is not the HTTP (80 or 443) port.
I am looking for MQ systems (rabbitmq , activemq) for our programs. Almost all MQ run on ports. I was wondering if there are any MQ systems running on smtp or email services.
Basically I am trying to avoid the hassle of setting up a new software and opening up ports in different firewalls (its a hassle).
RabbitMQ is designed from the ground up to interoperate with other messaging systems: it is the leading implementation of AMQP, the open standard for business messaging, and, through adapters, supports XMPP, SMTP, STOMP and HTTP for lightweight web messaging.
supports SMTP? from: http://www.rabbitmq.com/
What is the best way to make a standalone java server built using J2SE Socket API high available? Using an HTTP server would have been a good choice specially for the built-in features e.g. security, clustering, transactions, etc. but the server should be capable of accepting TCP/IP socket connection from java & non-java clients (mainly legacy). Tomcat does not accept non-http TCP/IP requests? Moreover this post points out servlet for implementing socket connection it's not a good practice. What would be good approach?
After exploring online, this is what I have compe up with. A standalone java application can be made high available by using a combination of the following:
2 VM deployed with HAproxy and keepalived to form the highly available load balancing layer.
Keepalived will keep the load balancers in active-passive mode and the HAproxy will forward the requests to a cluster of backend socket based java server apps
At least 2 VM deployed with the custom socket based java server apps. The HAproxy servers will distribute the requests over these 2 VMs
Use at least 2 terracotta server to share the java server apps. Terracotta will provide the sharing of the memory and help the custom java servers to scale.
Use MySQL NDB Cluster for the database.
Any suggestions?