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.
Related
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.
We have multiple web apps on our container (Tomcat) that don't interact with each other but they share the same data model. Some basic data access operations are used in multiple web apps, and of course we don't want the same code duplicated between multiple webapps.
For this case is it better to build a library to provide the common functions or to expose the functions as a web service?
With the library the user would have to provide the data source to access the database while the web service would be self-contained plus have its own logging.
My quesion is similar to this SO question but performance isn't a concern - I think working with a web service on the same container will more than meet our needs. I'm interested to know if there's a standard way to approach this problem and if one way is better than the other - I'm sure I haven't considered all the factors.
Thank you.
I would make them a library. This will reduce any performance hits you would incur from network traffic, and in general would make it easier to reach your applications (because your library can't go 'down' like a webserver). If your applications which use this library otherwise do not require a network connection, then you will be able to totally relieve yourself of network connectivity constraints.
If you think you may want to expose some functionality of this library to your users, you should consider making a webservice around this library.
If it is just a model with some non-persistent operations (non-side effect calculations, etc) I'll use jar library. If it is more like a service (DB/Network/... operations), I'll create a separate webservice. If you have strong performance requirements, local library is the only solution.
Also you can implement it using interfaces and change implementation when it will be clear, what to use.
Webservice will certainly have its own share of overhead, both in terms of cpu and the codebase. If you dont to duplicate the same jar in every project, you can consider moving it to server lib, so that once updated every webapp gets the change. But this approach has a major drawback too, suppose you make some non backward compatible change in the model jar and update one webapp to use the newer model, you will certainly have to update all other webapps to be able to adapt to changes made in the common jar. You cant run multiple version from same server lib. You can package appropriate version of common jar in every webapp, but then for even a minor change in the common (model) jar, you will have to repckage and deploy all the webapps.
When I looked into Java EE6 doc and some other articles, Java EE6 is a platform.
To me, platform is just Java with bunch of API/framework available like JSF, JPA, Web services like REST. (more like bunch of jars maybe?)
So anyway I got Netbean6.9/Java EE6/GlassFish v3 bundle but figured I don't need JSF at all.
Is there a way to remove JSF from Java EE6 so that I can save some disc space on my server?
Sorry if my statement doesn't make sense because I'm not fully understand what exactly Java EE6 by reading documentation.. (or this JSF is bundled with Netbean6.9...)
Update:
I'm building REST web app so far using JAX-RS and JPA (toplink essential) and for UI side, JSF was going to be used but we decided not to, so wondering if things that won't get used can be removed. (after reading comments I think removing JSF is not good idea though)
Java EE is a set of interfaces/annotations/etc for performing tons of different kinds of tasks commonly needed when building, well, 'Enterprise' applications. (the definition of which is its own multipage thread.) Glassfish is includes an implementation for each of the different APIs that make up JavaEE. Basically, when you use Glassfish, you can just go ahead and use anything in a 'javax ' package and it will be there for you, working. (although sometimes not the most performant or scalable implementation available...)
There are several options for java web containers that don't include implementations of the entire J2EE API built in. Tomcat and Jetty are probably the two most popular and widely used. Tomcat installs and integrates right into netbeans very well. But if you find yourself wanting to use something in most javax packages, you will need to provide an implementation, include the jar files yourself, etc.
--
Also, as an aside, the very, very nice Glassfish administration console (which is to me the chief motivator for using Glassfish) is done in JSF, so no, you can't really remove it :)
Regarding JavaEE, you don't need any jar file, but only a compliant application server, Glassfish in your case. And no, you can't remove features you don't need. But you don't have to use them if you don't want to... ;-)
In order to be J2EE certified there are certain requirements that must be met, and removing some of the functionality may cause problems.
For a nice discussion on what it means to be certified, you can start with this:
http://en.wikipedia.org/wiki/Java_Platform,_Enterprise_Edition
A Java EE application server can
handle transactions, security,
scalability, concurrency and
management of the components that are
deployed to it, in order to enable
developers to concentrate more on the
business logic of the components
rather than on infrastructure and
integration tasks.
If you find that you don't want to use much of J2EE you can look at something like the Spring framework (http://www.springsource.org/) which will offer more capabilities than just tomcat/jetty, but you can add/remove the parts you don't need, though you will need to include the core.
If you just need JAX-WS for example, then you can just add that manually, but, depending on your application you may find that there are many parts you will eventually need to make your life easier.
I'll need to develop a Java service that is simple because:
It only communicates via a TCP socket, no HTTP.
It runs on a dedicated server (there are no other services except the basic SSH and such)
Should I make this a standalone service (maybe in something like Java Service Wrapper) or make it run in a container like Tomcat? What are the benefits and detriments of both?
If you aren't working with HTTP, you will have to build your own connectors for Tomcat. When I've written these types of applications, I've just written them as standard Java applications. On Windows machines, I use a service wrapper that allows them to be part of the Windows startup process. On non-windows machines, you just need to add a start up script.
Using a container (regardless which) buys you that all the details about starting, stopping, scaling, logging etc, which you have to do yourself otherwise, and it is always harder than you think (at least when you reach production).
Especially the scalability is something you need to consider already now. Later it will be much harder to change your mind.
So, if somebody already wrote most of what you need, then use that.
Tomcat doesn't sound like a good choice for me in your situation. AFAIK it's primarily made for Servlets and JSPs, and you have neither. You also don't need to deploy multiple applications on your app. server etc. (so no benefit from ".war").
If you need dependency injection, connection pooling, logging, network programming framework etc., there are a lot of good solutions out there and they don't need tomcat.
For example, in my case I went for a standalone app. that used Spring, Hibernate, Netty, Apache Commons DBCP, Log4j etc. These can be easily setup, and this way you have a lot more freedom.
Should you need a HTTP server, maybe embedding Jetty is another option. With this option too, you have more control over the app. and this can potentially simplify your implementation compared to using a tomcat container.
Tomcat doesn't really buy you much if you don't use HTTP.
However, I was forced to move a non-HTTP server to Tomcat for following reasons,
We need some simple web pages to display the status/stats of the server so I need a web server. Java 6 comes with a simple HTTP server but Tomcat is more robust.
Our operation tools are geared to run Tomcat only and standalone app just falls off radar in their monitoring system.
We use DBCP for database pooling and everyone seems more comfortable to use it under Tomcat.
The memory foot-print of Tomcat (a few MBs) is not an issue for us so we haven't seen any performance change since moved to Tomcat.
A container can save you from reinventing the wheel in terms of startup, monitoring, logging, configuration, deployment, etc. Also it makes your service more understandable to non-developers.
I wouldn't necessarily go for tomcat, check out glassfish and germonimo as they are more modular, and you can have just the bits the need, and exclude the http server.
We faced a similar decision a while back, and some parts of the system ended up being jsw based, and the others as .war files. The .war option is simpler (well more standard for sure) to build and configure.
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.