We are developing an OSGI (karaf container) based application and it is deployed in fuse ESB. We have some integrations like to ActiveMQ and to SMSC over SMPP etc. We are connecting and interacting with these systems with camel routes. I want to monitor the connections status of these systems by providing a interface implementation like motitor(SomeMonitoringInterfaceImpl):
String url = "smpp://smppclient1#localhost:2776";
from(url).motitor(SomeMonitoringInterfaceImpl).routeId("smpp-route").to("bean:smsSmppService?method=send").end();
is there a way to it?
Note that the camel-smpp component is trying to handle it without throwing any exception, which is understandable however which also hinders to monitor it.
Related
I am creating a Java application in eclipse to let different devices communicate together using a publish/subscribe protocol.
I am using Jboss and ActiveMQ and I want to know if I should use an ActiveMQ resource adapter to integrate the broker in jboss in a standalone mode or I should just add dependencies in my pom.xml file and use explicit java code like indicated here http://activemq.apache.org/how-do-i-embed-a-broker-inside-a-connection.html.
Here the documentation I found to integrate ActiveMQ within jboss in a standalone mode https://access.redhat.com/documentation/en-US/Red_Hat_JBoss_A-MQ/6.1/html/Integrating_with_JBoss_Enterprise_Application_Platform/DeployRar-InstallRar.html
Could someone tell me what is the difference between the two approaches?
Here is the answer for my question:
The first approach starts a broker within your webapp itself. You can use a
normal consumer (not a message-driven bean - MDB), but only your webapp can
access it, via the VM transport (vm://).
The second approach lets the app server manage both the connection to the
broker and the creation of the broker, so it's probably also within the JVM
that runs your webapp and probably only accessible to your webapp, but
those details are hidden from you by the app server. You can only consume
messages via an MDB, but this provides a uniform interface that doesn't
need to change if you switch to another JMS provider in the future.
Since the standard way to integrate a JEE webapp with a JMS broker is via
the RA, I'd recommend using that approach simply for consistency and
standardization. That should also allow you to switch to a standalone
ActiveMQ broker (or another JMS product) in the future with minimal effort.
Does CloudBees offer any JMS hosting or any 3rd party JMS hosting (like IronMQ)? After perusing their Partner Ecosystem pages and developers docs, I don't see anything of the sort. I'd like to deploy a web app to CloudBees but will need messaging, and something like RabbitMQ or ActiveMQ.
I know I could always ship my WAR with an embedded instance of ActiveMQ running inside of it, but that kind of defeats the purpose of scalability in my mind: the harder the queues are working, the slower my app is going to become, and it would be nice to delegate the messaging work to a broker residing on another machine.
Also, it would be most sweet if such a messaging service had a free tier like so many of the other CloudBees tech partners offer...
Any ideas? Thanks in advance!
There is no official partner (yet) to provide messaging service, but you for sure can use a SaaS MQ service from your cloudbees application, even not being an official partner, for sample http://www.cloudamqp.com/ to get RabbitMQ -as-a-service, Iron.io or Amazon SQS. The only consideration is to ensure this service is hosted on Amazon, so your application won't suffer network latencies to access the MQ broker - most SaaS run on AWS anyway
free tier option is another consideration, depends on partner business model... (CloudAMQP has one)
I need to develop JMS based application which will asynchronously process inbound and outbound messages with third party systems.
Is it possible to develop generic JMS application which at runtime may use MQSeriers or WebLogic JMS? any examples of these?
If you want to use a App server agnostic Message System, you can try something line HornetMQ, RabbitMQ or ActiveMQ and check how you can use them from your application (these MQ's can be configured apart from any application server) or you can check how you can integrate them with a specific server.
Case:
Developing a standalone java client which will run on different locations on multiple user desktops.
Application server(Oracle Weblogic) will be running at centralized location in different place.
Now I want to access/call EJB (Session Bean) running on central server from client.
As client and server are on different location and not connected via Intranet or LAN only medium of connection is internet.
My question is how can I call EJB's in server directly from client without using a servlet/JSP layer in between?
EJB was devised for remote access , why a servlet dependency?
I have read that RMI-IIOP can be used to make this type of connection but I am unable to use RMI-IIOP over internet!
What is the best architecture/solution for this type of remote communication?
Remember that the EJB is a consise unit of buisness logic, they are protocol agnostic. Exposing it to the caller is the job of the application server. RMI-IIOP/CORBA is just the default.
The internet routing issue with IIOP is similar to many protocols, it is not that they don't route over the internet, it is that they do not have an easy proxy / reverse proxy feature built in. Hence has issues going through a DMZ. Compared to HTTP which has support for reverse proxy, or SMTP allows for relaying. The firewall port is typically closed as well, You would not normally put an application server in a DMZ.
To solve the problem of giving direct access to business logic to an external network, i typically change protocols to something designed for external network communications. For example, annotate (or deployment descriptor) the EJBs with the #WebMethod and the become available as SOAP services automatically, or use the #PATH (etc.) to expose them as HTTP/JSON/XML services.
CORBA type protocols have out-of-the-box features for security, XA transactions and are very high performance. I usually use this for enterprise level component oriented systems internally. (each EJB component is essentially used as a microservice) While for external integration, especially where the caller does not need to pre-know the interface contract, I typically go with a SOAP or HTTP/JSON/XML endpoints for the EJB.
There is no servlet dependency. There is a custom client/protocol dependency that's app server specific. Each server has their own way of setting up the connection, manifested through configuring JNDI for the proper providers and protocol handlers.
Why won't RMI-IIOP work over the internet? The only potential issue I can see there is security, I don't know if there's an encrypted version of RMI-IIOP or not, but other than that, it's a perfectly routable protocol.
You may run in to port and firewall issues, but that's not the protocols fault. If you want to run RMI-IIOP over port 80 (http's port), then that's fine (obviously it won't be http, nor work with http proxies, but again, that's not the protocols issue).
Weblogic also has (had?) their own protocol, T3? I think it was? Can you use that?
I think the key is why you don't think you can run RMI-IIOP "over the internet", and trying to solve that problem, not necessarily what protocol to use.
The RMI/IIOP is the default provided by the application server. By configuration / annotation SOAP or HTTP/XML/JSON can be used instead. (Although these protocols have some trade-off with security, transactions, etc.)
Well EJB doesn't have at all a dependency on the servlet. They can be called directly using RMI/IIOP.
The only problem you have to face is the network structure, i mean RMI/IIOP uses some ports that usually aren't open in company Firewall and it could be quite difficult to open them.
So usually it is better to make an HTTP request because almost all firewall accepts this kind of request.
So if you are in an intranet (client and server in the same intranet) you can use RMI/IIOP but if your client and server are placed in different networks with internet connection then i suggest to you to use HTTP.
You could use Webservices and "export" your EJB as a web service.
If you don't want to use Webservices then you could implement as extrema-ratio a servlet that receives HTTP request and calls the EJB. It depends on the type of object you have to return to the client.
If it is a simple string or something not too complex then you could even use a Servlet but if they are objects then the Servelt solution isn't the right choice.
In a very popular ecommerce store, I'd imagine the actual processing of the credit card would be moved to some sort of dedicated application server, and made into more of a asynchronous process.
What sort of java application type would that be? i.e. a service that would take a message of the queue, and start processing the request and update some db table once finished.
In .net, I guess one would use a windows service. What would you use in the java world?
It is typically a J2EE application that uses a HTTP web service interface or a JMS messaging interface. HTTP interfaces are accessible via a URL, and JMS connects to a queue to pick up messages that are sent to it. The app can run on any one of the major commercial (WebSphere, Weblogic, Oracle) or free (Glassfish, JBoss) servers.
In Java you already have great open source projects that do all this for you like Glassfish, Tomcat etc.
For a mission critical system, you might want something like IBM MQ series as the middleware, and a straight Java application that uses the MQ interface to process the requests.
At a few banks that I know of, this is their architecture. Originally the application servers were written in C, as was the middleware. They were able to switch to java because the code that was actually doing the critical work (sending and receiving messages, assuring guaranteed delivery, protecting against interruptions if a component went down) were the IBM MQ's.
In our case we use an application server from Sybase that can house Java components. They are pretty much standard Java classes that have public methods that are exposed for calling via CORBA. Components can also be scheduled to run constantly or on a schedule (like a service) to look for work to do (via items in a database table, an Oracle AQ queue, or a JMS queue). All of this is contained in the app server and the app server provides transaction management, resource management, and database connection pooling for us.
Or use an OSGI environment.