Does Jboss 7 support remote jndi lookups from a remote client - java

I have custom components that are standalone java components that do not run within the Jboss application server. These components need to interface with a HornetQ JMS queue which runs inside of AS7.
Looking at the Jboss AS 7 documentation, there seems to be conflicting information on whether remote JNDI lookup is supported or not.
This JIRA entry seems to provide some information https://issues.jboss.org/browse/AS7-1338 but it doesnt explain it well.
I guess my question is, Is it possible to access JMS queues running within the AS 7 application server from an external standalone client via remote JNDI lookup? If it is not possible is there an alternative approach that can be used to get to the JMS queues from an external remote JNDI lookup?

Looking at this comment (and subsequent ones) I'd say this is supported in AS 7.1.0.Final (and later). The fact that this goes over remoting and no longer over rmi is an implementation detail which you need to cater for in your code.

Related

Interest of using activeMQ resource adapter

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.

Java web application calling different other Java applications (workers)

I am looking for a better logical solution of a situation where one core Java EE (Web) application will call/execute many other Java applications/workers (which can be core Java or J2EE(web) application (don't know what will be the best)) at a certain time.
Those other Java applications/workers will basically connect (individually) with different Data sources (can be from remote DB or REST or SOAP, etc...) and populate/update local DB at a certain period of time.
I was doing research on Java Quartz Scheduler recently. Do u have any good suggestion to me for this Enterprise level architecture?
Btw, I am using Spring 4, Java 7
Thank you as always for all good and professional ideas.
Sample diagram can be as follows:
You can connect your java application with others easy with spring's httpInvoker or rmiInvoker.
More information here: http://docs.spring.io/spring/docs/current/spring-framework-reference/html/remoting.html
Not sure to understand good, but you can look at a messaging mechanism. Typically, the WebApp will send a message that will be received by all the Workers.
Have a look a JMS which it designed for this kind of use, and integrates well with both JEE (it is a part of the JEE spec) and Spring.
There are basically two parts to your question:
How do I schedule jobs on a Java EE server?
How do I invoke remote services from that scheduled job?
Job Scheduling
The trick with job scheduling in a Java EE environment is that you are typically running jobs in a cluster, or more than one server. Thus, only one of the nodes should be running that job at a time "on behalf of" the cluster, otherwise, you'll get multiple calls to those remote resources for the same thing.
There is a standard out there for this, JSR-237, which covers Timers and WorkManagers. Each Java EE vendor has its own implementation. WebLogic has one, WebSphere has one, and JBoss has one (the JBoss one isn't compliant with the JSR, but it does the same thing).
If you are running one of the servers that only runs the web tier of the Java EE spec (i.e, Tomcat or Geronimo), then Quartz is a good choice.
How to invoke remote services from timed jobs
Echoing #Alexandre Cartapanis' answer, probably what you'll want to do is create a JMS Topic in your Java EE server, and then when the job runs, post a message to the topic. The remote services (whatever Java EE servers) subscribe to this topic, and then you can run your queries.
The big advantage here is that if you ever need to add another service that needs to populate the local DB, all you have to do is have that server subscribe to the topic - no code changes needed. With JSch or remoting, you'll have to make a code change every time a new service comes online. You also have to make code changes if DNS addresses or IP addresses change, etc, where as the JMS way is just configuration on the server. There's a lot more that you can do with JMS, and the support is much better across the board.
Spring has adapters for Quartz and I think there's one out there for WorkManagers and Timers too.
You can make use of JSch - Java Secure Channel to trigger remote ssh calls which can start a JVM and run the Worker class.
Here are some examples.

What are the specific uses of Java Application Server that cannot be done with web servers?

I am a little confused about the roles of a java application server and its differences from a web server.
I found many sites explaining the same difference between the two but not to my satisfaction.
So please explain me about the two following cases:-
1)App. Server and its difference with web server:
From these two links:
Difference between an application server and a servlet container?
What is the difference between application server and web server?
web server: It handles everything through http protocol by accepting requests from clients and sending
responses to them with the help of its servlet container(e.g Apache Tomcat)
App. Server: An application server supports the whole of JavaEE like JMS,JPA,RPC etc.
Now what I am confused with is that how can I use a lot of JavaEE APIs like JMS,JPA etc. with my Tomcat
by adding their jar files in my web application ?
Does that mean that if I use an appliation server I don't have to add those jar files?(I don't think so)
2)The roles of an appl. server (This is very important to me)
From Wikipedia
http://en.wikipedia.org/wiki/Application_Server
An application server provides services such as security,transaction support etc.
"The term is often used for web servers which support the JavaEE" -- It sounds like if we add the required jar files of JavaEE APIs a web server becomes an appl. server.What about it.
Now my question is how an application server performs the tasks of security control or transaction management by itself ?
E.g. in my web application using Spring framework I am providing security by using spring-security and transaction management by using #Transactional annotation and all those things you know.
So does the appl. server have anything to do with my security or transaction management or it has its own ways ?
Forgive my ignorance.
Using Spring, you're in fact embedding some kind of Java EE container inside your application. But even when using Spring, if you need JTA support (because you need distributed XA transactions), you'll need to use an additional transaction manager. If you need JMS, you'll need to install an additional JMS broker. If you need connection pooling, you'll need to use an additional connection pool. Sometimes it's as simple as adding additional jars to the classpath and properties or XML files. Sometimes it's harder.
A Java EE app server comes with everything bundled. You have less flexibility, but you don't need to install, configure and make everything work by yourself.
When you use the Java EE framework, that is a specification. So the application server, if it is Java EE compliant, needs to implement this. So once it is implemented the specification, then it will address Security,transaction etc because it is mentioned in the spec. So it is a contract. Whereas, in a web server, it will just pull out your static resource. There is no need for handling other stuff.
In case of the Spring framework, the framework knows how to handle transaction, security etc. So particularly the developer need not look into these aspects which are implemented by the Application Server in the other scenario.
how an application server performs the tasks of security control or transaction management by itself
It is rather the specification that address these issues, not the application server. So, the duty of the app server is to implement these.
So, if your application is Java EE compliant, then these areas will be addressed and the implementation would have been done by the app server.
May be this is oversimplification,
A web server is basically a HTTP server serving contents over http protocol. So a web server is simply about serving the contents over http protocol. A typical example would be Apache web server. This is simply a file server.
Now the question is where does the web server gets the contents from ? Possible sources are
Static contents (the contents like images/css etc) which are not generated on request but statically served.
Dynamic contents: Simply put, the contents to be served are generated upon the user request.
For the static contents, the web server does not need anything as it simply reads the file and serves it.
For dynamic contents, the web server might need help of additional components which will generate the contents to be served.
Here the Application Server comes into picture.
Now these additional components referred earlier, might interact with database or some other system etc.
In a web environment where your website is exposed to huge number of users (intended/unintended), you need typical services like transaction/security/concurrency etc. so that the user get expected responses and do not see inconsistencies in the behavior of the application.
An application server has inbuilt abilities to manage transaction/security/concurrency/resource management. generally these are referred as Managed services and environment offered by them is called Managed Environment where these basic services are managed by the application server and programmer does not have be bother for them.
Application Server needs web servers or we can say Web servers use Application server's services to generate dynamic contents.
For example, JBoss uses Tomcat as inbuilt web server. Whereas web logic has its own web server. Tomcat again can be called as application server (in principle) as it also offers managed environment for servlets (it manages concurrency and instance pool of servlets/JSPs ).
Coming your your example of Spring:
An Application server will come inbuilt with transaction/security etc whether you need it or not. The Spring offers a very nice way handling this. Spring has all these things BUT you use what you need. Not just these, but just a Java Web Sever like Tomcat is sufficient to build a full fledged services that needs an application server.

Does EE Server need to be installed to make a use of JMS?

I got a question about usage of JMS(Java Message Queue). Somewhere in documentation I have seen that everything I need to use JMS is jms.jar on the machine where the client is going to run. But I still not sure if I need glassfish or JBoss also installed on machine.. Anyone can me tell if it's really only jms.jar is needed or I need something more installed on machine?
Thanks,
Serhiy.
You need jms.jar to access JMS topics and queues. But in order to have a working JMS setup you need a JMS provider. Applications servers have JMS providers bundled. There are stand-alone JMS providers, like Apache ActiveMQ or HornetQ:
you need the jms provider jar(s) on your classpath, so that its concrete classes get instantiated (The JMS API only defines the contract)
you need the jms provider running and handling incoming and outgoing messages.
Well, actually JMS is just an standard API for messaging. You'll have to use an existing implementation as well as a provider in order to use it.
If you're using JBOSS take a look at HornetQ
There's a tutorial on developerWorks which you may be interested in that describes how to run a JMS program outside of a Java EE environment using WebSphere MQ.
The question of whether you need something other than the JMS jar file is another matter. The best answer is to always use the install media supplied by the vendor. I don't know about JBoss but with IBM's implementation that install media includes diagnostic utilities and if you just grab the jar files it may not be supported. Other vendors may also have support issues if you just grab the jar files but I don't have specifics.

What do I need to realize notification using JMS?

I just need notification system. javax.jms.* - good solution I think, but I can't understand what do I need to use JMS?
I don't want to use any app. servers like GlassFish or Tomcat, I just would like to use standard jdk and myserver(very light) and myclient(very light too) and some MessageSystem to exchanging bitween myserver and myclient. As I understand to use JMS I need JMS Provider. For example: ActiveMQ. But I don't uderstand ActiveMQ needs any server?(GlassFish probably), and what kind of *.jar do I need from Java EE ?
JMS provider or more correctly a Message Broker can be a stand-alone application. Most of J2EE app servers include a broker inside them but yes we also have many very good stand alone JMS brokers, ActiveMQ is good, then there is OpenJMS and many others. And as they are stand alone they don't need another app server to run them. And they usually come with every needed jar as well :) SO you'll not need to copy any jar from other app-server to say ActiveMQ or OpenJMS.
ActiveMQ runs as a standalone server; it requires the Java VM like any Java application but nothing else beyond that.
Other stand alone JMS brokers (open source) which can be run standalone or even embedded in your Java application are Open Message Queue (OpenMQ) which is also included in GlassFish, and the new JBoss HornetQ message broker which will be the JMS implementation in JBoss application server.

Categories

Resources