we are wanting to use a JNDI service with our client applications (all written in Java SE 6) and here is our doubt: what are the dependencies? Does the JVM already comes with all the classes that we'll need to access these services? If not, where can we get them?
Like JDBC (Java Database Connectivity), JNDI is not a service, but a set of interfaces; it allows applications to access many different directory service providers using a standardized API. Just as with JDBC, the JDK contains the JNDI interfaces but does not include a JNDI service provider -- although Sun Microsystems provides adapters for connecting to existing directory service providers, such as LDAP (lightweight directory access protocol), DNS (domain name service), and CORBA. However, you can use one of several free or open source JNDI providers in your J2SE (Java 2 Platform, Standard Edition) applications.
What you're looking for is package javax.naming, which is part of JavaSE 6.
Sun's guide to JNDI.
Now, unless you're building a web application, JNDI is quite a complex beast. If you can afford to bundle Spring with your application, the lookup of an object with Spring is a no-brainer.
Yes, Java comes with all classes necessary to use JNDI. See the tutorial for some examples and explanations.
Related
There are several Java EE APIs that exist as just that - APIs (interfaces, domain objects, enums, etc. but no actual classes that do stuff). APIs like JPA, JDBC or JTA. These APIs must then have implementations; for JPA there are impls like Hibernate, MyBatis or TopLink. For JDBC there are drivers for each specific RDBMS. For JTA there is Bitronix and Atomikos.
But what about JavaMail? Is it just an API? If so, what are some common implementations of it? If I deploy my Java app (as a WAR) to Tomcat 7, where does this implementation come from (specifically)? Does Tomcat have its own JavaMail impl? What JARs/packages/classes compose the Tomcat impl?
JavaMail is a standard JSR 919
TomEE server has support for JavaMail.
The configuration is very easy and goes like this
tomee already comes with apache-tomee-plus-1.6.0/lib/geronimo-javamail_1.4_mail-1.8.2.jar
in tomee.xml (configured at $TOMEE/conf) you add an entry as described by Configuring JavaMail
from inside your classes you can reference the mail session via #Resource like described at javax.mail.Session resource and smtp authentication
After reading the official Java EE docs and after playing with OpenEJB, I am wondering about the capabilities of different application servers to cross-communicate Remote EJBs. Right now, it seems to me that despite the API's standardisation, the inter-process communication is not standardized, for example with the ejbd protocol that only seems to be supported by OpenEJB.
I am in particularly wondering about the protocols that are used for implementing EJB-based RPCs. Until now, I believed that this communication was mostly done via HTTP. From looking into the documentations for WebSphere, JBoss and TomEE, it seems however like every application server cooks its own soup.
My question is therefore: Can different application servers generally communicate via remote EJBs and by what protocol is this typically implemented. And why would an application server like TomEE offer a deriving solution in the first place?
Yes, this is possible. The EJB-Spec requires the support of CORBA/IIOP.
From the EJB 3.1 Spec (Chapter 2.5):
To help interoperability for EJB environments that include systems
from multiple vendors, the EJB specification requires compliant
implementations to support the interoperability protocol based on
CORBA/IIOP for remote invocations from Java EE clients.
Implementations may support other remote invocation protocols in
addition to IIOP.
Is it possible to create a client that accesses an EJB3 bean, with the client having no dependence on a vendor JAR or configuration? We currently need to support scenarios where our service is deployed on a WebSphere or JBoss server, and the client is deployed as an application either on a WAS or JBoss, or is running as a standalone app.
I used to be able to do to this with EJB2.x beans, I just needed to create stubs using RMIC.
But with EJB3, If I'm connecting to WebSphere I have to include thinclient JARs, plus I have to pre-generate the stubs using WAS tools. For JBoss I have to use jboss-client.jar.
No, this is not possible. This has been made explicit in section 10 of the EJB 3.2 specification:
This chapter describes the interoperability support for accessing an
enterprise bean through the EJB 2.1 remote client view from clients
distributed over a network, and the distributed interoperability
requirements for invocations on enterprise beans from remote clients
that are Java Platform, Enterprise Edition (Java EE) components.
Distributed Interoperability is not defined for the EJB 3.x remote client view.
Also note section 10.5.5:
System value classes are serializable value classes implementing the
javax.ejb.Handle, javax.ejb.HomeHandle, javax.ejb.EJBMetaData,
java.util.Enumeration,java.util.Collection, and java.util.Iterator
interfaces. These value classes are provided by the EJB container
vendor. They must be provided in the form of a JAR file by the
container hosting the referenced bean. For interoperability scenarios,
if a referencing component would use such system value classes at
runtime, the Deployer must ensure that these system value classes
provided by the container hosting the referenced bean are available to
the referencing component. This may be done, for example, by including
these system value classes in the classpath of the referencing
container, or by deploying the system value classes with the
referencing component’s application by providing them to the
deployment tool.
For WebSphere Application Server, the EJB thinclient contains these system value classes as well as the IBM JNDI implementation that uses CosNaming. In theory, this thinclient is not needed if you don't need the system value classes and your client JVM has its own ORB with an implementation of CosNaming.
Short answer: No, it's not possible, as a client needs three things:
The interface classes.
The client libraries of the server AS (yes, sadly)
A configuration telling the client the server address/jndi lookup path (qa, prod etc.)
If your client is running on the same product (let's say JBoss to JBoss communication), you will not be in need of client libraries and just be able to do a remote lookup. If you have a mix of client/server application servers this will make things complicated, as you will have to run client libraries of one product in another server product.
Speaking of standalone applications running as clients, I'd just build and provide 1 heavy client jar/lib containing not only the interface classes, but also the client libs of both servers. Then providing a small helper class that returns the correct InitialContext created and based either on JBoss or Websphere depending on a flag in the client configuration.
I know this last idea ain't a clean solution, though might even work in a different AS product running as "client".
For some integration projects I would like to query JMX agents from non-Java clients.
I found two options so far, ws-jmx-connector (Soap based) and mx4j and its JMX HTTP adaptor which returns XML document responses. The JSR 262 based ws-jmx-connector seems to be no longer in active development. I have not tried MX4J so I do not know if it is possible to use the HTTP adaptor with the standard JMX implementation in the J2SE.
Are there other software projects which can help to connect non-Java clients with JMX agents, using open standard protocols?
Update: meanwhile I found this project, a "Restful JMX Adaptor". It is also described in the article RESTful Access to JMX Instrumentation, Via URI-fication of MBean Attributes
I recommend Jolokia, which is a full featured JSON/HTTP adapter for JMX. It has several client libs, i.e. jmx4perl, which allows for programatic JMX access from within perl. For Java and Javascript there are client bindings, too. More are in the pipeline (Scala, Groovy, Python). The installation is dead easy, for a Java EE container it is as simple as deploying a standard Java EE war. Other agents (OSGi, Mule, JVM6) are available, too.
Jolokia is a agent based and implies that I install a server and agents. What I am after is a lightweight pure command line, non-java based, non-agent based solution to call JMX/RMI interface.
Let it be a C-code application or perl or python whatever as long as it is fast.
As the title suggests, this is in relation to Java EE and Glassfish in particular.
From what i've learned the application client is executed in some application client that has the ability to talk to glassfish. But there seems to be limitations to this regarding annotations.
Can someone give me an example of the difference in connecting to a glassfish application server from the two different application types?
What is the benefit of the application client approach, and what approach is the most commonly used when developing application clients for Java EE?
The code (work you need to do) associated with connecting to the app server in either case is not really all that hard... but it is covered in different docs.
These are the instructions on how to access an EJB from a stand-alone java application.
These are the instructions for using an app client to access an EJB from a Java EE 6 Application Client with GlassFish v3: http://docs.sun.com/app/docs/doc/820-7695/beakt?l=en&a=view
Accessing an EJB from an application client gives you access to more of Java EE services 'automagically' than if you were working with the EJB 'directly'. You can cobble together access to some of these services in the stand-alone case, but the burden shifts onto the application developer/deployer to make that access work.
Creating a stand-alone application that accesses an EJB will seem easy, in the short term, and many folks will invest in that strategy. If they deploy their client application onto a large number of machines, the burden associated with a cobbled together service access strategy can become a burden.
Deploying an application client that uses the application client container is not free either. The advantage is the fact that you have the support of your app server vendor to overcome deployment issues.
If you are using GlassFish (v2.1,v2.1.1 or v3), you can also take advantage of Java Web Start support, which simplifies client application deployment a lot.
An application client is actually run in a container and has full access to Java EE resources defined on your server in the same way that a Servlet or EJB does. This would typically be used for some type of admin client, not a user application. Here is one explanation.
In addition to the Java EE Application Client, there is also the concept of a Thin Client, which allows access to some Java EE resources as well, but not as easily as the App Client. It usually involves using JNDI lookup with absolute names as JNDI references are not available. A typical case for this would be a standalone producer/consumer of JMS messages. It is basically a lighter weight option of the full App Client.
If you are simply creating a user application, you will most likely want to either use a Thin Client model, or a plain old application that simply consumes services from your Java EE app via servlet or web service calls.