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.
Related
I know that Tomcat is a web server but why it is not an application server?
Any server needs to follow some specification. What is that spec?
Is it possible for apache to make the tomcat application server?
Also I have read in a blog that the tomcat do not have some lib to act as an application server. What are those libs?
Thanks
I've heard once the following explanation I tend to agree with:
There is a spec of JEE (Java enterprise edition).
Formally you can think about it as a bunch of pdf-s describing the behavior of various technologies that comprise the JEE stack (for example: JMS, EJB, JPA, JPA, JSF, CDI and so on and so forth) as well as deployment models (EARs for example).
Implementors of Application servers have to implement all those technologies and offer interfaces that can be used by the application developers. So teams that stand behind WildFly (former JBoss), Geronimo, WebSphere, WebLogic and so on have read these specs and implemented everything in there.
Now, Tomcat didn't do that, they've only concentrated on (primarily) Servlets/JSPs. These are web technologies, so Tomcat can't be considered as an Application server that implements the whole JEE stack.
In general Tomcat (as well as Jetty, incidentally) should be more lightweight than full JEE compliant Application servers, it should start-up faster and it memory footprint should be smaller. So Tomcat/Jetty call themselves web servers.
I understand that this answer can be considered as speculation, but for me it makes a lot of sense.
Bellow is my perceive:
know that Tomcat is a web server but why it is not an application server?
Here, Application Server is specially for Java EE Server，Java EE is a huge specific collections for Enterprice Application Development，So Application Server should implement most specifics of these, while Tomcat(or Jetty) is only a Web Server(More accurately，Servlet Container)，they only implements the specific about Web(such as Servlet Spec(JSR340), JSP(JSR245)). Therefore，Application Server is stronger than Web Server，but Web Server is more lightweight and enough to satisfy most web applications.
Any server needs to follow some specification. What is that spec?
Of course，it depends on that your Server want to provide what services(functions)，these specifications can view here.
Is it possible for apache to make the tomcat application server?
I don't think apache will make tomcat to be an application server. Now, there are some popular Java EE Server: Jboss，WebLogic, etc. Not all enterprices need a heavyweight Application Server, on the contrary, most only need a lightweight Web Server。
Also I have read in a blog that the tomcat do not have some lib to act as an application server. What are those libs?
Tomcat only need care the specs about Web，and implements them.
Hope for your help.
I was arguing with a coworker about ESBs. I mentioned that Glassfish is an ESB as it manages database transactions, provides SOAP messages, and messaging systems through JMS. He disagreed and said that Oracle Enterprise Service Bus is an ESB whereas Glassfish isn't. I asked him what features make an ESB and he couldn't respond.
What is Glassfish lacking that prevent it from being an ESB?
Glassfish has a bunch of the components of an ESB, but what it is specifically lack in the orchestration component. The orchestration is managing the "wiring" of the various services to each other. GF has all of the capability in terms of managing the endpoints, but not the routing and transformation of messages from endpoint to endpoint.
That said, it USED to have an ESB bundled with it. It used to ship with OpenESB in GF 2.x, but that's been removed from GF 3.x.
Glassfish is an application server. You could certainly run an ESB on top of it, but there are several features missing out-of-the-box from what is typically considered an ESB. You're kind of comparing apples to oranges here -- an app-server provides the structure that supports a web application, whereas the primary goal of an ESB is to help distribute information to/from potentially several applications.
I'd like to use the Java Message Service but it says it's for the Java EE Platform. Is there a way to port it to a regular Java application (which I'm working on in Eclipse)?
JMS is part of the Java EE spec, but you can use it from any Java application. Depending on your needs, you may have to run a standalone broker, but this is just like running a regular daemon (or Windows service).
Yes, you absolutely can use JMS from a J2SE application. In fact, you can access a JMS broker from programs not written in Java at all. The ActiveMQ JMS server includes several transport connectors. The connectors allow clients to interact with ActiveMQ using different communication protocols. Most Java clients use the openwire connector. I've written a PHP client that used the STOMP protocol with great success. It consumed messages sent to a JMS Queue by a Java application running in the Tomcat Servlet Container.
This is a much more complicated question than the answer would indicate. Jms is a spec. Really just a set of interfaces. You can absolutley use those interfaces from a standalone java process. Hell you could write your own jms compliant messaging implementation. Questions you should be asking yourself is what messaging implementation will i be using and does it support jms? Even after answering that there are numerous caveats to take into account when connecting to brokers outside of a container including but not limited to transactionality, load balancing, connection pooling, and high availability. You should be very clear about what your trying to do and what messaging vendor you are working with before you can answer this completely
Many Messaging servers also provides their java api for the communication like MQ, open source Apache ActiveMQ. In that case you don't realy need to worry about JMS. You simply need to understand and use that API.
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.