I was trying to understand the difference between EJB and Servlet (I know both are conceptually different, EJB is a piece of Java Code with some rules and Servlet is something that accepts and processes HTTP requests) But I found that one of the difference between the two is also:
Ejbs allows Remote Accessing.
Servlet/jsp's does not allow remote accessing
I do not understand the above difference. Why an EJB can be remotely accessible and Servlet not.
Servlet responds to http request (normaly) note that a JSP is transformed to a servler. A EJB it's totaly diferent, EJB define your business model.
It seems you are confused about what remote accessing is, it means that you can have a EJB deployed in a different server running in a different JVM and that your servlets can access it.
In the other side you can have local EJBs which run in the same server has the rest of your webapp and in the same JVM as your servlets and jsps. Depending on whether you EJB is local or remote the implementation differs in some little aspects (in remote EJBs you need to create an interface and other things, I won't enter in details, I'll add a link about this).
If you want to understand what's the difference between servlets, jsps and ebjs, you should understand what MVC (Model View Controller) is. Normally Controller is defined by servlets, which receive the http request from the client and delegate the actions that they do in EJBs and JSPs. The View is defined by JSPs ( I assume you already understand what they are). And EJBs are the Model, they define your business model, they don't serve http requests, they just perform simple actions over your "model" like update/select/insert data in your database, and many other things.
See more in:
https://docs.oracle.com/javaee/7/tutorial/doc/ejb-intro.htm#GIJSZ for EJB
Also I recomend you the following two books:
Head First Servlets and JSP http://shop.oreilly.com/product/9780596005405.do
Head First EJB http://shop.oreilly.com/product/9780596005719.do
Related
First of all i'm a newbie in java-ee. I'm working as a java developer and where i work, the company has a web application with java-ee on the frontside and cache(intersystem) at the backend.
Is it possible that the web application may not have any servlet class? I only can find httpservlet imports.
From my understanding, java-ee application always work with servlets with his get/post/init method's. Am i right?
Also,I really don't get the difference between servlets and jsp's.
For the moment, I know that the application is using maven,struts2,jsp,hibernate,taglib...
(Sorry for my english,I try my best)
You are not right, but not totally wrong either. Java-ee application mostly works with servlet but there is also others mechanisms involve like Filter and Listener.
Filters are used to manage request and response before and after servlets are called. For example you could use one to always redirect to a login page if there is no session.
Filter documentation
Listeners are used for listening to events in a web container, like Session creation.
I don't really know Struts2 but with a little of research i found out that it works with a front filter who is interpreting request and dispatch them to your Action class.
Some infos about Struts
A lot of Framework/Apis use a similar system it's actually the design pattern Front Controller, springMVC and Jersey for example both work with an unique front servlet
As for the difference between JSP and servlet, JSPs are just file that are compiled by the web server as servlet.
I have multiple Java web applications deployed on the same server (Wildfly).
They all should use a single WebSocket implementation to send messages (object, not plain text) to the user.
Edit: WebApp1-3 are the applications with the business logic. The only purpose of WebApp4 is to update a Primefaces panel in the browser based on the messages generated by the other WebApps. Sorry for the missleading illustration.
WebApp1
WebApp2 --> ??? --> WebApp4 (WebSocket-Server) --> JS/Browser
WebApp3
Which is the best way/pattern/implementation to make WebApp4 available to the other applications? (RMI, JMS, WebSocket, WebService, ....?)
My advice, for a general way of exposing services, is to expose REST services since they are simpler than SOAP web service and easily allow interoperability (if in the future a PHP or a RUBY webapp needs to consume your services it's much easier with a REST interface than with one base on RMI or JMS). The content of the REST service may vary, I suggest you to look at XML or JSON as a way of transmitting information over http REST services.
If all webapps are in the same server, you should forward requests from one to another. From the point of view of webapps 1-3, they would not need to be aware of whether their incoming requests were coming from webapp 4 or from outside (to which it appears that they are not connected). Of course, you are free to alter requests before forwarding them - or to drop them altogether, for example if authentication fails.
To do this in tomcat: https://stackoverflow.com/a/8951090/15472
When forwarding requests, the external client is completely unaware of the existence of webapps 1-3 -- as far as the client is concerned, it has sent a request to webapp 4, and it will think it is receiving a response from that same server.
You may need to configure your web server to allow these kinds of calls, but I am unfamiliar with WildFly.
I have one webserver with 2 instances of tomcat running. On each tomcat instance I have multiple web apps or web services.
What is the best way to call a function (or trigger some event with parameters) from a webapp of the first tomcat server on a webapp running on the second tomcat server. If it's for example a call using a url with parameters then this call should be secure and not accessible from outside the server.
I've read something about getting the servlet context but is this possible on different tomcat instances? Im thinking that this is only possible with webapps running in the same instance.
I dont want to use CORBA, RMI or SOAP because this is a bit oversized for my problem ... that is what Im thinking :)
Code examples are welcome. Thank you!
The ServletContext is only valid within the same container and can't be shared between two JVMs. The simplest method to do what you're asking is to just use some variety of RPC between the two containers, and RMI doesn't seem like particular overkill. The other usual approach would be a simple HTTP Web service (note the lowercase "s") that invokes your logic in the receiving container.
Spring's HTTPInvoker is great for this. You can use a Java interface, and your code on each instance doesn't need to know the call is remote - it just calls Java methods.
For security, you can use the Sun HTTP server on a different port (instead of using a servlet within Tomcat) and listen only on localhost.
Have a look here
http://static.springsource.org/spring/docs/3.2.x/spring-framework-reference/html/remoting.html#remoting-httpinvoker
Use Simple REST services , not that much secured .
I would like to know what is the starting point of any web application deployed on JBoss/Weblogic/Webphere.
For example, If you take a struts based application the starting point is ActionServlets plays the role of controller which manages all incoming requests. I am sure controller is depends on framework.
If so, please help me identifying the popular frameworks other than Struts, Flext etc., where I can presume ActionServlet as my controller.
Still a question on back of my mind, Wondering is there anything specific to Application Server? if so, any insight would be highly appreciated.
Thanks in Advance...
After your clarification, I'll try to write down how do I structure simple web apps (without frameworks)
a startup servlet, only initializing global stuffs and checking for resources (db pools, jms). Only it's init() method implemented and loaded with order 0.
a login servlet, with a login jsp as its main view.
a set of welcome pages redirecting the user to the login servlet (in web.xml)
a dashboard servlet, with a simple jsp as a view intrumenting menus and providing a nice starting point for the app.
After this, every action/menu, will map to one or more servlet doing all the bacground stuffs and redirecting to jsp views.
Usually I manage each request into a single servlet, doGet() or doPost() method, but it's not mandatory, depends on what I am doing.
For example, if you have to generate a report and this generation takes time, the servlet simply enque a report request somewhere (JMS queue or starts a Quartz task) and gives back control to the browser with a courtesy page stating that the request has been queued.
There are also scenarios in which a single request from the web UI, functionally impacts more of my "servlets", in such scenarios I chain the requests using the RequestDispatcher utility.
Doing this may lead to code duplication, so a good design of a business class tree is a must. Common business code shared among servlets (which act as the glue between user inputs, business logic and data logic - just like controllers ^^)
How do I pass objects from non-GWT server-side code (e.g. regular server code) to the GWT "servlet" (still server-side code), specifically a RemoteServiceServlet?
My GWT server-side code consists of RPC-type RemoteServiceServlets to which I can't seem to get a reference so I can't pass in my real/fake object in testing mode or add servlet attributes. I can't see any way to simply pass objects in (dependency-injection style) as I have no access to the Server object as GWT seems to instantiate it deep within its internals, so what are my options?
P.S. I don't want to use a full-blown DI framework such as GIN/Juice - I find them to much magic. I just want a way to access the instance of a GWT servlet and pass stuff to it.
Let me start out by saying, if you haven't already, I highly recommend watching this Google I/O presentation on GWT Architecture best practices. I found it very useful and it's where most of the following came from.
What I did was create an abstract "dispatch" servlet that extends GWT's RemoteServiceServlet. Every module I have has only one service (that extends my abstract dispatch service) with which I register a set of request handlers. All GWT service calls for a given GWT module come into that module's dispatch service, which looks at the type of request and dispatches it to the appropriate request handler. The request handlers, in effect, handle the work that previously resided in the service servlet. Besides making your life easier by having fewer servlets to register in your web.xml (not to mention avoiding the extra interfaces GWT requires), you can more easily control the dispatcher object that handles all the actual dispatching. You can, for example, pass whatever real/mock object you like into these request handlers since you, and not the web container, are responsible for instantiating them.
And though I rolled my own, the gwt-dispatch project exists for this very purpose.
Hope this helps.
Servlet containers are designed to not allow direct access to the servlets that they host; that's why you've found it difficult to get any kind of handle to a servlet.
Rather, refactor the code that is currently in your servlets into separate request-handler classes, and have your serlvets call into them.
For testing purposes you can hook your testing framework, or your client code, to the request-handler classes directly. That's how people generally solve the problem you've run into.