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.
Related
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.
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 would like you guys to give me some feedback, on my understanding about the
difference between Application Servers such as JBoss and frameworks such as Axis and CXF.
CXF is a standalone, web-app based framework that
implements JAX-RS, JAX-WS API wich, in turn, are part of the
larger API set of JEE.
Being a web-app based implementation, it
can only be used to host "SOAP on HTTP" services even if the
standard JAX-WS defines other possible channels for SOAP
messages,such as SMTP.
Application servers,such as JBOSS, instead implement JAX-WS as well as all the other JEE APIs in a more "native" and direct way, so,for example, they can be used to host also SOAP on SMTP services.
Both AS and standalone frameworks such as CXF and AXIS make
extensive use of Inversion of control.
Application Servers, such as Jboss, can be thought as composed by a
set of frameworks that implement all the JEE stack API.
Please take some time to correct/enhance the above statements.
Thanks
Working on a Java-based large distributed system, so there will be multiple services running across multiple machines .....
Looking for an open source framework to be able to manage these services(e.g. start/stop a service, install a new a service remotely etc.)
Apache Karaf seems to be a good choice, but underneath it uses apache felix (an OSGi reference implementation) bundle which I have a hard time to really understand. In particular, it seems to be easy to define and register a service in felix, but how do you invoke such a service remotely? Do you need to have a separate RPC mechanism to achieve that? There seems to be very few links describe it. In general how do people use OSGi? Is Apache felix out of date?
Any other framework that can be used to manage services assuming I will have my own RPC layer (say RMI based or Netty based)?
I guess you have to specify the way you define a service.
There are services, like remote services that use RPC mechanism, for example EJB remote calls.
Another way to define services is to talk of Web-Services, either using SOAP(XML) or JAXRS(JSON) as transport protocol. And there is the definition of services in OSGi which just means a separation of API (service definition) and implementation. As sum-up you could define OSGi as a SOA for Applications within the same VirtualMachine. (it gives much more, but this is one way to look at it from a service perspective)
Apache Karaf is a OSGi server that is comparable to a Application Server, only it works for OSGi applications. It brings a lot of convenience technologies on top of a choosable OSGi framework. That would be either Apache Felix or Eclipse Equinox. Both are OSGi frameworks that provide the basic OSGi infrastructure - SOA in the same JVM.
Now there are a lot of other benefits of it, like starting and stoping services, updating services.
Taking the RPC into account this can easily be achieved, by combining OSGi-Services with CXF for example. It can easily be configured to export an OSGi service as CXF service. (this is very Karaf/CXF specific)
Apache Karaf itself also supports clustering with Apache Karaf Cellar, which also provides a DOSGi service for easier communication of services across cluster groups. DOSGi stands for Distributed OSGi, which can also be achieved by using CXF and much other implementations.
Apache Felix and OSGi in general are far away of being out-of-date. A lot of Java EE Application servers use OSGi as their underlying technology to be modular and have a smaller footprint.
That would be GlassFish, Websphere, Geronimo etc...
Since EJB 3 we have embeddable EJB containers, JPA implementations can be used without an application server, there is Weld for contexts and dependency injection and so on. Since on many systems is only Tomcat available, I wonder, if Java EE could be used without an application server but with a Servlet container like Tomcat.
What would I have to do to set up an Java environment? What drawbacks do you see?
Note that Tomcat is an Application Server. That said, in October we released Apache TomEE which is Tomcat with the missing JavaEE parts added, then Java EE 6 certified using the official TCK from Oracle.
The stack evolved from what used to be simply called "OpenEJB/Tomcat", which was a useful stack with a bad name :) Commonly overlooked because of the "EJB" part, meanwhile it also delivered Transactions, JMS, WebServices and more to Tomcat. The new name is far better and now it's officially certified like JBoss or GlassFish. We're pretty excited about its future.
If I understand well, you want to use EJB3/JPA within a servlet container.
There are not only stand-alone implementations of JPA, but also embeddable EJB3 container, such as OpenEJB or Glassfish embeddable container. So nothing prevents you from starting such an embeddable container from the Servlet container to use EJB3.
(Note: I don't know all the details about transactions. In a full-blown app. server, you have JTA and a distributed transaction manager. You don't have that in a Servlet container such as Tomcat. JPA works with JTA and plain JDBC, but I don't know exactly how an embeddable container work without JTA. Still, I guess that would work given that such embeddable containers are also meant for unit-testing where I guess there is no JTA distributed transaction manager.)
Another approach would be to use Spring. Spring and EJB3 have indeed become very similar. You can start the Spring DI container within the Servlet container and benefit more or less from the same facilities as EJB3 (declarative transactions, etc.). See this post about Spring vs. EJB3.
All these technologies have become pretty modular, especially with Java EE profiles. You can use Sevlets, EJB3, JMS, JPA, even JTA somehow independently of one other. You can also create an environment where you cherry pick the ones you would like, either with Spring or with Java EE. The question is when does it stop to make sense and rather use an app. server with everything available and easily manageable. I think Servlet/EJB3/JPA is the limit, if more is needed go for an app. server.
You will generally require some kind of container, even if that container doesn't provide Java EE-related services. After all, you do need a long-lived JVM process to host the code that you're executing. Tomcat and Jetty will do the job nicely, and in addition to basic servlet services, provide a few useful extras that will be relevant, like connection pooling.
J2EE without application server was introduced years ago by me (Guy Pardon, from Atomikos), with this seminal article: http://www.onjava.com/pub/a/onjava/2006/02/08/j2ee-without-application-server.html - focused on JMS and JDBC at the time.
In general it's easy to setup thanks to Spring and Hibernate. Actually, I got inspired to do this after doing a Java EE project and being confronted with the XML hell associated with app servers and EJBs. Without application server things suddenly became a lot simpler and more testable.
If you need a Tomcat installation then can be a bit more of a hassle to configure, but recently Atomikos has introduced out-of-the-box Tomcat integration as part of its commercial offering at http://www.atomikos.com.
HTH