Supposing a classical 3-tier JavaEE architecture like this
JSF / JSP / Servlets (Web)
EJB (Biz)
DB (Persistence)
All JavaEE tutorial examples show the web and biz layers in different containers, but in the same JavaEE server.
Is there any situation where there is an advantage to keep the EJBs apart, in their own machine? In this case, supposing they're going to communicate with the web tier via RMI, is there any kind of JavaEE container that manages EJBs but not JSP and servlets?
Is there any situation where there is an advantage to keep the EJBs apart, in their own machine?
Sometimes, specifics non-functional requirements can determine your app design.
For example, security: in order to achieve some security norms, the business layer has to reside in a more secure server not exposed directly to Internet.
Availability: if your business layer exposes some services consumed by a different client than the web server, and these services offer some kind of mission-critical functionality, probably they need to run on a 24/7 server.
I'm not sure that think in terms of "advantage" is the correct way to see this kind of decoupled architecture.
I think that is more like a price (which is translated in a more complex design) that you have to pay if you need achieve this kind of requirements.
is there any kind of JavaEE container that manages EJBs but not JSP and servlets?
Yes, for example OpenEjb.
Related
I have developed a web application with Java EE, which connects to a DB. The app is deployed on Tomcat 8. The app is divided in three layers: db layer, business layer, and presentation layer.
Now I need to develop a RESTful API that will use the business layer and will provide most of the functions that the presentation layer provides. Clients will have two options to choose from: open a browser, connect to the APP and use it or consume the RESTful web services from their own software.
My question is: should I deploy the RESTful API on the same server where the APP is deployed or separately? What are your suggestions?
And, what kind of authentication would you suggest for the REST web services?
Thanks!
It is a rather broad question and the short answer is it depends.
Functionnally, you have three parts here:
the presentation layer
the API interface
the back office: business and db layers behind the 2 first ones
Common technical architectures are:
one app for the API and business and db layers, one app for the web layer using the API
everything (API, Web and business) on the same application.
The former offer a better separation and can be interesting for heavy loaded applications, or if you plan to move to a javascript interface (AngularJS ofr example), the latter will be simpler to implement.
For the authentication, it is simpler to pass the credentials along with each request for an API, but you should considere managing it outside the application itself through filters and/or AOP concepts. Spring Security is an example of how this is possible and gives a very loose coupling between the business code and the authentication and authorization ones. You can then choose and change your authentication methods with little impact on the core of the application.
As shown in the above pic, I have a EJB-3 Enterprise application (EAR file), which acts as a portal and holds 3 web applications (WAR files) that communicate and transact with the same datastore. These 3 webapps are not portlet implementations, but normal webapps which interact with the datastore through the Enterprise App's Persistence Layer. These webapps are developed independently and so, some of 'em use Webservices from the Enterprise App and some of 'em use EJB-Clients.
Also, there is an other option of replacing these webapps (Web App1, Web App2 and Web App3) and using independent Enterprise Apps to communicate and transact with the database, as shown below:
Now, my questions are:
1) What is the best Option among the listed 2 options (above)?
2) How does it affect when we replace those webapps acting as clients to the Enterprise App, as independent Enterprise Apps (EAR files)?
3) What is a better model for Transaction handling, SSO functionality, Scalability and other factors?
4) Are there are any other better models?
EDIT:
1) In the first model, which method is a preferred way to interact with the EAR file - webservices or ejb-client jar file/library (interfaces and utility classes)?
2) How do both models differ in memory usage (server RAM) and performance. Is there any considerable difference?
Since you are being so abstract I will do it as well. If we remove all buzzy words as "Portal", "Enterprise Apps" and so on... What we have at the end is three web apps and a common library or framework (The enterprise App).
Seeing its app as simple as posible. You have three developers that need develop three web apps. You will provide some common code useful to build their apps. The model you will use will depends of what kind of code you will provide them.
1.- You will only provide some utils, and common business code. May be the clasical library fit your needs. (In Java EE environments you must take in account how can you take the advantages of persistence cache level 2 sharing a Session Factory for a single datastore)
2.- You will provide shared services as persistence, cache, security, audit, and so on... You will need a service layer as the first option. You will have a shared state so you need only one instance.
3.- The more common case is both you provide some business API and a service layer to common services.
You aren't indicating any requirement that force you to use a more complex solution for your scenario.
EDIT:
About if it is prefered rmi (the ejb-client) or webservices. I always use rmi to communicate applications geographically close. It use is simple and the protocol is much more faster that webservices (you can read a lot of comparison over this topic searching for rmi webservices performance on google).
On the other hand rmi is more sensible to network latence, require special firewall configurations and it is more coupled that webservices. So if I pretend to offer services to a third party or connect geographically sparse servers I will prefer webservices or even REST.
About the last question initially there is no any difference about deploy one or ten applications in the same server. The deploy fee will be insignificant over the overhead for the use of the application. Of course, you must take this as a generical assumption. Obviously the size and how you deploy your applications will have an impact about the memory consumption and others.
You must take in account that this decisions can be easily changed as you will needed. So as I said you could start with the simple solution and if you encounter a problem deploying your applications your could restructure your ears easily.
I'm inclined to agree with Fedox. If there is no reason for choosing one solution over the other ( business reason, technical reason, etc) then you might as wel choose the path of least resistance. To my mind that would be the first solution.
In general terms start simple and add complexity as you need to. Your solutions have no meaning without context. A banking app needs different considerations to a blog.
Hope this helps
There is a new platform called Vitria's BusinessWare, it's a very successful project which is worth millions.
Now let's see how does it work and what it does so that we can do the same in theory:
It interconnects projects with their databases, web-services with their EJBs..etc.
From their concept we can learn the following:
Create main EJB stateless bean (API), whose job is to pass messages
from:
web-services to other web-services
web-services to webapps
webapps to other web-services
The purpose of this EJB is first do validations in the main database
and then pass the calls to the other modules.
Only this EJB has access to the DB to more secure the connections
This EJB will queue the messages until the modules to sent are free
to accept
This EJB will control all the processes in the DB
This EJB will decide where to send the messages
If I have a hosted web application, is it good practise to split the web and api web service into 2 different projects/hosted applications in tomcat?
I can see that if people try and abuse the API it will effect the performance of the web application.
If I was to go with creating 2 separate projects (or if not initially but build for the potential to split things off), can I somehow share my hibernate data layer between 2 projects?
I'm using IntelliJ, how can I do this? Would it be to create a seperate module for hibernate (domain entities, Dao, and Service classes).
I wouldn't say is a good practice in general, but maybe a good idea for some scenarios.
In a service oriented architecture, a service layer is consumed by not only the web layer, but potentially other clients. In this case is probably a good idea to build the web and service layers in separate servers.
Another case would be when you want to perform separate deployments, because e.g. work in both layers is done by different teams or in separate workstreams - I would question whether this is a good practice though as opposed to teams working in vertical features rather than in layers.
You can create your service layer in many different ways:
As web services. When you need interoperability.
As remote EJBs (this is possible in TomEE). When interoperability is not necessary.
You can also create a combination of the both above, they are not mutually exclusive.
In terms of splitting the projects, you could create:
A set of domain objects in a jar module that is to be shared between your web and service layers.
A war module for your web layer.
A jar module for your service layer interfaces that is a dependency for your web layer.
A jar/war module for your service layer containing services and DAOs.
What's the difference between what you call "web" and "api web service" from the client perspective? A programmatic client can "abuse" either of those, so not sure if it makes sense to split them for that reason. You can use a load balancer to scale out.
You could make an internal API that the web interface consumes, and a web api that consumes the internal API.
I want to create a web service (SOAP) under Apache Tomcat with Axis2, and I must respect the three-tiered architecture:
DAO -> Business Logic Layer -> Presentation Layer
I'm new to web services. Is there a step-by-step tutorial for this?
There isn't really a presentation layer in a web service, unless you consider the service itself to be the presentation layer.
http://www.roseindia.net/webservices/axis2/
There is tons of DAO information on the web, and there's nothing special about a DAO layer for a service versus any other application. A lot of this will depend upon how you want to build your DAO layer. I like using Spring JDBC.
Three tiered architecture means different things to different people.
One common interpretation is (with tiers from the user starting with #1):
Presentation layer running in the browser. I.e. Javascript (possibly from some framework such as jQuery, GWT, etc).
Business Logic layer running on the server. I.e. A dynamic web server (Tomcat in this case)
Database such as MySQL, SqlServer, Oracle, PostgreSql, etc.
It's also possible to have a layer #2.5 doing the DAO work for you (or a custom DAO) such as Hibernate.
Another interpretation is that #1 is actually the web server, and #2 is a separate business logic server, where #1 and #2 live in separate server instances (likely on separate machines or VMs) for security, isolation, and the ability to scale and release separately (and many other motivations).
In any case, you should read up on typical Java serving architectures and possibly describe your goals better. I.e. you use "Presentation Layer" which in some definitions doesn't make sense for a non-UI based web service. Of course, Axis2 could be your "presentation layer" for a web service as well :)
A little context: I would like to separate the Java application I'm writing into a more or less typical server-client model. I would provide a "server" which takes care of business logic and persistence, but write it in a very service oriented fashion. Any front-end code (GUI) would then call upon the server to provide the functionality in a user friendly fashion.
As I'm writing the application using Spring (and an ORM framework), it would make sense to explore the usual suspects to expose the server functionality, with the usual suspects being RMI, Spring HTTP, Hessian, web services, etc (the Spring natively supported options). These are well well documented, both in reference documentation and on here.
However, for the actual question: are there any less obvious, more exotic options I could consider to use for exposing my server services?
It's important (as always) to get the right balance between ease of use (from a front-end POV), performance and scalability. For example; since I've thought about providing the Spring-BlazeDS integration in the server any way (for Flex/AS3 clients), it dawned on me that BlazeDS provides a Java-native API for calling AMF services.
Any pointers are much appreciated.
I would recommend BlazeDS if you have a Flex front end and Spring HTTP if not. Both eliminate the non-productive work introduced by having to translate XML to objects and back again.
Spring HTTP is especially attractive because you can write POJO Spring service interfaces just as you always do, deferring the choice to expose via HTTP remoting until the end. You keep your options open that way. If you decide that Spring web services work better for you later on, you can keep re-using the same POJO Spring interface.