I am looking for any idea which is Spring equivalent to EJB with local interface. I want to communicate between webapps within one application server (Tomcat), obtain something like direct-call across applications.
Thanks in advance for your help.
The best way depends on your requirements.
For two webapps in a same JVM, I don't think that you have standard for that.
Note that in any cases, an EJB container provides features to communicate between two applications hosted in a same server that you could probably not get out of the box by other technologies (pooling, transaction, and so for...).
1) RMI, a component oriented, close to the EJBs but low level technology
Indeed, technically speaking RMI is close to the EJB technology that relies itself on the RMI technology (among other things).
But RMI is also a low level API, so you should rewrite many features provided out of the box by EJBs (pooling, transaction, and so for...).
2) REST, a service and interoperability oriented technology
Today these webapps are hosted on the same Tomcat instance.
Tomorrow, for multiple reasons (too much loading, cloud and so for...) these could be deployed on distinct JVMs.
Using higher abstraction than JVM and a more standard way to communicate between app such as HTTP REST may be a good thing.
Related
In our system we have a legacy standalone java application which we are trying to made available for new webapps we are developing all together running in a server (f.e. Tomcat)
In order to made requests to this app lighter we thought about made them directly to the same vm using jndi instead of developing a webservice interface.
I would like to start this application environment in some webapp context and make some API available to other webapps and invoke interfaces' methods.
I've not been able to bind this objects by JNDI in the Tomcat's read-only Context without adding the app in the Common lib, when I get more problems due to incompatibilities between dependencies versions. Maybe the best solution is to deploy these interfaces as EJBs so I'd use a Java EE Server instead of a servlet container. Or maybe I'd use some other framework such as Camel or something.
Thanks in advance and any suggestion will be helpful.
I would suggest to wrap your legacy java interfaces in REST. When you expose them as REST APIs, they will become available for any client, not only java. Also you don't need any Application Servers for that, all you need is a jar file for your REST reference implementation.
From performance perspective, well, I know theoretically JNDI should be faster, but in the real world the difference in performance becomes significant ONLY for very very performance intensive applications.
However, if performance is your primary requirement then wrap your legacy interfaces in EJBs.
Manual JNDI/RMI lookups are going to be the fastest, BUT and this is a rather big but, unless you are well experienced in network programming and multi threading, I would advise you to steer clear of that, and use a container. There are a lot of nitty gritty details that the container takes care of and you can concentrate on implementing your business logic.
I am trying to understand what does JBoss AS can bring into the project, comparing to standalone architecture?
My model application is a solid thing, starting, running and stopping as a whole and solely at the host.
It has a database storage, and communicates to user and other servers, clustering required.
It has web-part. It's just a standard big application.
JBoss for me is a shell for (in general) multiple applications, providing my application with some standard services. This shell is also a solid thing - "get all or nothing", something can be turned on/off (influencing your app unpredictably, or influencing other part of the JBoss) or replaced (very hard and is already kind a hack) with different version or other module.
Standalone application for me is something combined of pieces with glue among them (Spring if you like) with IoC wiring. We can get everything we could have with JBoss, but separately. Spring or other glue serves here like an application server, but it's thinner and we still can replace parts or even Spring itself (IoC wiring is straightforward from coding point of view).
For me, standalone, AS-free approach gives more control and flexibility. And further more, last versions of JBoss AS are purely documented, some features (most interested) are not documented at all.
So, why somebody still choose JBoss - what are benefits?
I favors more standalone application approach, but need more facts to understand better and convince others.
It seems to me that what you are describing is the classic choice between best-of-breed (collecting all the parts and glueing them together your self) versus integrated stack (JBoss wrote all the parts and integrated them for you). This is a debate that will rage on for eternity. If best-of-breed is working for you then stick with it.
JBoss is a J2EE container. Take a look at the J2EE spec if you are unfamiliar with it. Basically Sun's community process came up with an development framework that contains components that you may be interested in when creating large scale apps. J2EE contains multiple sub specs such as Servlets, EJB, JTA, JMS, and a whole host of other alphabet soup technologies. If you aren't using any of these technologies then you do not need a J2EE container. If you are just interested in using Servlets and JSPs then you are better off using a servlet container such as Tomcat, Jetty, Resin, etc.
Providing enterprise features such as scalability, transactional support, federated user management, etc. are difficult. A J2EE container provides a standard level of these features. If you can find them elsewhere to a level that meets your satisfaction then more power to you.
You can also pick and choose if you are running inside JBoss. If you are happy with the JBoss services you can use them or deploy some others if you don't like the one JBoss provides for you.
Starting from the JBoss minimal configuration and building up your own configuration should give you a setup where you don't have services running that you don't need. Personally, I like to know what my AS is running, so I prefer to start from minimal configuration adding only the necessary parts.
I would say the only reason to use JBoss is if you need to access the Java EE services (like Messaging, container-managed transactions and similar).
Keep in mind JBoss is (roughly described) Tomcat plus Java EE services (yes, yes, I know, this is a very simplified approach, just bear with me). I mention this as I would say your decision is:
If you only need IoC and some other capabilites you can get with Spring and Tomcat, go with that
If you application requires Java EE services, use JBoss
Keep in mind you can always start with the basic system (Spring + Tomcat) and move to JBoss if required later on. Nothing forbids that.And probably starting with that approach will show you if you really need the Java EE services or you were over-engineering the solution.
What are the primary reasons for using the Java EE (EJBs) over just a simple Servlet implementation?
I am working on developing a new project that will primarily be a web service that must be very fast and scalable.
Sorry for any confusion, Although I am experienced in Java, I am very new to the Java Web world, and may not be asking this question well.
Servlets are HTTP request listeners; they can't respond to anything else.
If you embed a great deal of logic in servlets it won't be available to any other clients.
Write your app in POJOs. Get it thoroughly tested without an app server involved. Then worry about how you'd like to package and deploy it. Servlet? EJB? Web service? Something else? No problem - those are just packaging and deployment issues. Get the behavior that you want working properly in POJOs first.
Spring can give you a lot of options here. I'd recommend it.
EJB's specification 1.x and 2.x added complexity that for most webapps was not needed.
Due this complexities the new frameworks appeared to simplify the development and the runtime architecture ( Hibernate / Spring / other microcontainers / others ORM frameworks ) .
EJB's 3.x matches this changes ( through JDO and JPA ) and now, using Servlets with these enhanced frameworks or Java EE with EJB 3 + would give you basically the same results.
Using a Java EE Application Server would add you a number of administrative advantages ( GUI to manage pools, logs, monitoring, transactions etc. ) With out them you may have the same result but you would have to do it all by hand ( editing configuration files that is ) Which may not seem too problematic, but if you plan to have an administrator for your webapp It would be better to use the admin tools that come out of the box with this servers.
Is the web service stateless? If so, I don't see any real advantage in using a full blown Java EE server over something lightweight like Tomcat or Jetty. You can deploy a jax-ws implementation with either of those, and do what you need pretty easily. If there's some kind of state involved, and you end up wanting to share that across multiple machines, that is where having Java EE can come in handy.
With that said, I don't think Java EE would decrease performance any at all. The app servers generally take longer to boot, and take more effort to manage, but once they are up and running the performance should be similar.
If your web services are likely to need any degree of "enterprise" features such as per-method security or transactions use EJBs.
With EJB 3 this is not actually very hard at all, a couple of annotations and you're done.
Otherwise simple POJOs behind a servlet are enough.
There seems to be multiple extremes when supporting embeddable Java HTTP servers. I have seen minimalist approaches such as NanoHTTPD and leveraging the com.sun.net.httpserver package to attempting to embed Jetty and Tomcat. The ideal embeddable HTTP server would be implemented such that it could be launched via Executor and come with Servlet/JSP support but otherwise should allow for using the logger of its parent and allow for integrating its JMX hooks.
Likewise, it should also be modular enough where you can have the option of NOT including certain pieces of functionality. Has anyone ran across any Java-based HTTP servers with this characteristic?
jetty:
JMX integration
configurable logging (both for request and debugging)
JSP 2.0 and 2.1
I think grizzly is an ideal solution for you. https://grizzly.dev.java.net/ . Out of box it's simply a NIO server, but there are different packages with support for HTTP, Servlets\JSP and etc.
I couldn't afford the overhead (in size) of even a minimal Jetty, so I wrote my own framework - I can't remember if Jetty had OSS licensing encumberances which ruled it out for us. But, at the time, I was highly impressed with Jetty's design and highly modular architecture - it was easily the best option I explored (back in 2001 or so) and I recommend it.
The question is how much functionality you need. The small ones typically only supports http requests, where you may want servlet API, https communications, web applications, etc. Jetty is very highly modular so you can put together what you want.
Imagine a Java client/server ERP application serving up to 100 concurrent users, both web and swing clients. For persistence we can use Persistence API and Hibernate.
But when it comes to client/server communication, do we really have an alternative to using an AS with EJBs to keep down the programming costs of remote communication?
It seems a very heavyweight solution to throw in EJBs and an application server, just for remoting stuff. There is also the standard way using RMI, but who wants nowadays to code everything on his own...
I know that you'll get a lot of features for free with an AS in addition to the remoting part. And, maybe it's the way to go. But, are there really any other (low programming cost) alternatives to an AS for doing client/server communication for an enterprise application?
Personally I consider Seam to be the ultimate solution to the problem I don't have but that aside, there are lots of options and Spring is used for most of them:
RMI;
Hessian (binary HTTP based protocol);
HTTP Invokers (Java serialization over HTTP);
Web Services; or
Even JMS.
The advantage of the HTTP based remoting methods is that they easily plug into Spring's security models. Plus then you get access to things like interceptors.
You can use light weight remoting frameworks. Spring is having a number of options in this section.
If you ask me one word for both, I will suggest two. Seam or Spring. I myself like Seam, but for lightweight remoting Spring has more viable solutions and support. Again if your AS is JBoss, give a thought to Seam.
An application server is a pretty heavyweight solution. Depending on your requirements, I would try to make sure that you can run on a simple servlet container (like Tomcat). I find remoting much easier with Spring-remoting instead of full EJB. Spring-remoting provides an abstraction on the actual remoting technique used. Hessian has a good reputation as a lightweigth protocol.
Having some sort of a server framework (AS or servlet container) is a good thing as you wont need to think as much about all the low level problems (connection establishment, threading, ...).