While using DWR in a intranet, will disadvantages like perfomance or security issues occur?
Direct web remoting is a tool which uses Ajax request to contact a server from a js file.
One thing I would watch out for is that your server will most likely get hit by more HTTP requests than if you have the (normal) full page HTTP delivery.
Let me explain. When your web page is AJAX-enabled, your clients will end up creating more HTTP requests for (say) form filling, page-fragment regeneration etc. I've seen scenarios where developers have gone AJAX-crazy, and made the web page a largely dynamic document. This results in a great user experience (if done well), but every request results in a server hit, leading to scalability and latency issues.
Note - this isn't particular to DWR, but is an AJAX issue. I've used DWR, and it works nicely. Unfortunately, I found that it worked so well, and so easily, that everything becomes a candidate for remoting, and you can end up with huge numbers of small requests.
I worked on a project with DWR - a really nice tool.
I'm not convinced about the pace of development though. They did post on the development log that they're working on getting 3.0 out the door, but the last stable release - 2.0 - was out in summer 2006. It's a bit worrying taken from a support perspective - bug fixes especially.
Main problem I've experienced is trying to script a load test on a system where the main bulk of the work is done via DWR calls. The format of the calls is difficult to replicate when compared with just replying a bunch of urls with changing parameters.
Still DWR is an excellent framework and makes implementing Javascript -> Java RPC pretty damn easy.
One feature missing of current DWR 3.x that any user should take good care is that when an instance of a bean has properties of NULL value, those properties will be still injected to the JSON and these redundant data DO affect the performance.
When a property has the value of NULL, usually it should not be sent to frontend.
Details of problem: http://dwr.2114559.n2.nabble.com/Creating-Custom-bean-converter-td6178318.html
DWR is a great tool when your site has a lot of ajax calls.
Each page that makes dwr rpc calls needs to include :
a) an interface file corresponding to the calls being made.
and
b) a js file bundled with dwr that contains the dwr engine code that makes these calls possible. for e.g. <script src="/dwr/engine.js" ></script>
one technique that is frequently used while optimizing web applications is to use the browser cache as much as possible when a resource(like a js file) has not changed on a server.
engine.js is something that will never change unless you upgrade your dwr to a newer version. But, by default, engine.js is not a static file served by your webserver. its bundled as part of the dwr tool itsef and is served by the dwr controller/servlet.this doesnt aid client side caching.
So, it is beneficial to save engine.js under the document root of your webserver and let the webserver serve it as a static file.
The biggest difference among other solutions to transfer objects (marshaling) is object references.
For instance, if you use it to transfer a tree:
A
|-B
|-C
in a list {A,B,C}:
B.parent = A
C.parent= A
then A is the same object in Javascrit!
On the bad side, if you have complex structures with circular dependencies and lot of objects: A<-B, B<-C, C<-B, C<.A,... it could crash.
Anyway, I use it in a real project used by many hundreds of companies in production to transfer thousands of objects to a single html page in order to draw a complex graph and it works nicely with a good performance.
Related
I am trying to implement a reasonably complex page flow (100+ pages) as a traditional web application. I found a few options, but none of them are 100% convincing
Harcode the flow into the controllers, do redirects, etc. This is obviously not the best thing for maintenance
JSF not only handles the flow, but also requires to use JSF as the view technology. I don't like this lock-in
Spring web flow. The current version 2.3.1 defines flows in XML that is not easy to maintain. The upcoming 3.0 release promises to define flows with annotations in pure java, but it does not even have a timeline. Additionally the project development slowed down significantly in the past years.
GWT and Vaadin's concept is closer to a traditional desktop application then to a web application, that is really convenient to use, but it wont fit to my project.
Additionally I found dozens of abandoned projects like this: http://javasteps.sourceforge.net/
I am wondering why all these projects are abandoned, what is the way to implement a complex page flow in 2012?
Personally, I'd recommend Single Page Architecture:
Architecture of a single-page JavaScript web application?
I'm not sure if that is feasible or not with your application. I've used all the flows you mentioned above and am currently working on a single-page application and I love it. We're using Dojo on the client-side, which calls a REST API on the server. It's been pretty nice.
Vaadin is pretty solid too and is much easier to set up than just bare-bones GWT. If you have a lot of UI guys on your project that like to code in CSS and Javascript, they'll hate that approach though.
Spring Webflow is pretty solid actually. I haven't looked at it in a while, but when I was using it, it got the job done for what I worked on at the time.
This is really late but I don't see a satisfactory answer to this question and would like to share an approach I had tried in a recent project which I feel is better than the spring web flow approach which is strictly tied down to spring views. I created a SPA using angular js with Spring MVC. In angular js I did not use routers or state, rather I created a div within the controller like below
<div width="100%" id="fullertonDataPanel" ng-include="page"></div>
On the server side to capture all possible transitions from one frame(I am referring to a particular screen in the SPA) to another I created a tree of rules using MVEL . So in the database I had a structure which stored a tree of rules for every frame . The data in the MVEL expressions were being set by the various services each action invoked. Thus on any action the following steps were followed.
1) Validate the action.
2) Invoke various services.
3) Capture the data from these services and merge it with the existing data of the user.
4) Feed this captured data into collection of rules for each frame along with the details of the current frame.
5) Run the rules of the tree w.r.t to current frame and fetch its output.
6) If there is only one transition then that is the final transition. If there are 2 transitions and one is default then ignore the default transition and use the other transition.
7) Return the template name of the transition to the angular controller and set the value of the page variable in the scope of the controller.
Using this approach all my services had to do was store data in different data fields w.r.t a particular action. All the complex if-else conditions for Web Flows or any complex process definitions(like the one defined in Spring-Web Flow) were not required. The MVEL rule engine managed all that and since it was all in the database it could be changed without needing a server re-start.
I believe this generic approach with MVEL is a flexible approach which comprehensively handles the problem of a convoluted flow without making the application code a mess or adding additional unnecessary xml files.
There is a new MVC framework and web flow implementation for Vaadin component model called Lexaden Web Flow
You can try it out for your application as possible alternative.
I need to create 5 methods on the server side, which will work with binary data. The remote clients are applet and JavaScript. The Client will send files to the server, and the server must parse these files and then return the response as XML/JSON.
So I am confused - is it good practice to use REST-service in this case? Or should I use a servlet?
My colleague told me:
"Creating REST-service that will be used only by one Application isn't
good. REST must be created only when it will be used by many apps. And
REST has some disadvantages over servlet: REST is slower than servlet;
it more difficult to write thread-safe REST than servlet"
However, I see some disadvantages with using Servlet: I need to send a function name that I want to call (i.e. as extra HTTP parameter send function name)
and then inside the doPost method perform the following switch:
switch(functionName) {
case "function1":
function1();
break;
case "function2"
function2();
break;
//.... more `case` statements....
}
In case of REST I can simple use different URLs for different functions.
Also, in the case of REST, it more convenient to return JSON/XML from server.
You are confusing two paradigms here:
REST is a software architecture “style”;
Servlet is a server-side technology.
You can, for example, implement REST-like services using Servlets.
Well,
I wouldn't agree with your colleagues' opinion that isn't good to have rest used by only one application, since you may decide in the future to have different applications using the same rest api. If I were you I would choose the pure REST. Why?
If you're using some framework for rest implementation (let's say apache cxf or jersey) you get lots of stuff out of the box - you write POJO you get a rest, you get serialization and deserialization, to and from let's say, JSON object out of the box (eventually you will need to implement some JsonProviders but this is not a big deal).
It is intuitive to work (if you design your rest APIs well).
Very easily consumable by JavaScript clients (especially if you're using JQuery or something like that)
However, it strongly depends of what exactly do you want to do, if you have some strong transactional logic, the rest could be quite tricky. If you're only going to do POST requests (without using the other HTTP methods) you might want to use the Servlet since you won't have to work with additional frameworks and making more dependencies. Note that the REST is more or less an architectural concept and it does not contradict with the Servlet technology, if you're stubborn enough you can make a rest api only with servlets :-).
Hope I've helped.
First, you're speaking in terms of two different paradigms. It's kinda apples-and-oranges.
REST is a style of service that uses HTTP operations (GET, PUT, etc.) to read and write the state of resources. Think of resources as "nouns" and "things".
Servlet, on the other hand, is a software specification originally provided by Sun Microsystems for connecting HTTP requests to custom Java code. Servlets often speak in terms of method calls: "verbs" and "actions".
Since your question implies that you are looking to deal with input->output methods, just a plain servlet should do the job.
I cannot see any problems on using Jersey and create a REST service. I know that I'm a REST-taliban but it's really simple to implement this kind of architecture using JAX-RS, so... why not?
Your colleagues say: "REST must be created only when it will be used by many apps" but I cannot see how this can be true.Why I cannot create a REST service for a single app?
Sounds like your collegue is applying premature optimisation. If you can write it with a JAX-RS library quickly, do so... If it then proves to be the bottleneck only then do you take the time to rewrite as servlet.
In my experience the performance overhead of JAX-RS is not sufficiently big to justify the development and maintenance overhead of writing the equivalent in servlets directly where the problem maps well to JAX-RS
Depending on your container version, Jersey (or any other JAX-RS implementation) will still use a Servlet for dispatching requests to the appropriate handler.
If your application is truly RESTful, then JAX-RS will do what you want. Otherwise, consider using a FrontController to interpret the Request and forward it to the appropriate handler.
Also, don't confuse XML or JSON with REST. You will get these for free in most (if not all) JAX-RS implementations, but these implementations still delegate content marshalling to other libraries (e.g. JAXB).
Here is the similiar link. he has done it with simple servlet
http://software.danielwatrous.com/restful-java-servlet/
I need to build a dashboard for an application, the dashboard will have different dashlets and each dashlet can have any one of the following things:
Graphs (JFreeCharts and some Javascript Chart)
Table data from tables
Data from external sources
Maps
What can be a good architecture for such kind of application?
What I have currently in mind is:
Each dashlet should have its own lifecycle and when the dashboard loads it should just show the UI of the dashlets initially.
After the page load each dashlet sends a server call (based on its type) to fetch its data
After the data has been fetched, each dashlet (based on its type) renders the data.
First of all, there are plenty of front-end frameworks to get you started. Some of the more popular ones include:
Backbone
Javscript MVC
Sproutcore
A bit of Google searching can yeild pros and cons of each and I would weight your options accordingly.
That all being said, the basic problem you posed actually seems similar to ours. In the end, we built something a bit different in house. Many of the frameworks out there are optimized to display a singular canonical "view" based on a Model reflected by the DB and a Controller to manage small changes. A dashboard has, in essence, a variety of different modules that must be doing their own independent things as you've mentioned in your question. Because of the high number of independent modules, I feel like you might feel pains in some of the frameworks listed above.
I can't tell you exactly how to implement such a module architecture, but here are some rules of thumb we used when designing ours:
Module Design:
Module-based. (Login module, Map module, each Dashlet may be a module, etc.)
Modules must have one Model, may have no more than one Collection (which is-a Model), and may have one or more Views.
A module may be used in multiple places and pages. The singular Model should stay the same, but the Views are likely different.
Rendering:
Almost all HTML on the page is written and updated by javascript modules. The template files are almost empty except for headers and basic scaffolding.
All modules render their full HTML selves and replace themselves into the DOM. The module should have as complete of a static HTML representation ready to go before inserting into the DOM. This means the render functions use “.replaceWith()” instead of “.append()”.
If simple HTML replacing isn’t an option (i.e. needs to be animated) a transition function should be defined detailing how to go from one rendered state to another.
Because rendering is expensive, Views by default do not auto-refresh on all Model changes. Re-rending happens through events only. _render() is in-fact an internal method.
Orthogonality:
A single inter-module event dispatcher on the page Controller handles all cross-effects between modules.
Modules should never “reach outside” of their own DOM context. If an event in one module affects another, it should go through the page controller dispatcher.
Each module as orthogonal as possible. They depend on each other as little as possible.
Each module in its own file.
Connecting to backend:
All modules use the same global backend adapter. Modules never talk to the backend by themselves. This makes your front-end back-end agnostic.
Recursive:
Modules are commonly included in other modules.
Modules re-render recursively.
Testable:
Because modules render static HTML, they can be predictably tested.
Modules must be testable.
Standard input -> Module -> Predictable static HTML output.
Standard events -> Module -> Predictable static HTML output.
If anyone knows of other frameworks along these lines, please share!
Our web app is based exactly on this architecture and in production since end of last year. You can see it at http://beebole.com
We just optimized the calls to our own server.
There is a single call to get the common data needed by most widgets, each time a screen is loaded.
Then if a widget needs additional data, it makes a call itself to our server.
The external widgets call their own data too, but to another server.
I would advise against using a custom web framework when there are so many free ones available.
As mentioned in another answer, the traditional MVC style frameworks don't really fit well to your 'dashboard' desired style of UI. They are best used for creating static web sites based on data retrieved elsewhere. They don't handle user interaction well and you usually have to hand roll your own AJAX to do anything useful without a page request.
A better breed of web frameworks to look at are the Web 2.0 fraemworks, also known as the frameworks which help you build web applications. It is important to understand the difference between web site and web applications. They are usually differentiated by the latter being interactive and the former being mostly static. Websites which also have some interactive components are still web sites. A good way to think of it is ask yourself "Does this feel like a desktop app?".
For web application development in the Java (JVM) realm, I would use Vaadin. It lets you write Java code similar to Swing programming, with event based methods. You can even avoid writting HTML altogether if you'd like by defining your views programatically. This lets you unittest your view logic (in web apps, there is more than usual) which is not posible with regular HTML template based frameworks. The other main advantage is that it has built in methods which allow you to write Java code to handle dynamic, asynchronous functionality and it all gets translated to JavaScript automatically. No need to write 4 different languages while writing your web app, just write Java for everything! Try it out, it is fun to work with!
Another web app framework that is getting alot of attention is Lift. I do not have experience with it but many devs I have spoken with have promoted it to me. I believe it uses HTML templates with Java code as the back-end. It is also apparently really easy to get started and your web app spun up. It also has built in support for doing AJAX like functionality. Worth looking into at least.
There are probably many more web app frameworks out there that would suit your needs. These all have the advantage of being tested, independently maintained, updated, and secure*. If you roll your own framework for this project, you need to worry about everything yourself. Written a web framework that doesn't offer anything new would be like written yet another programming language that isn't innovative; it is just a waste of time.
I think what you are looking for is more along the lines of managing or controlling your dashboard. I am designing something similar. I would suggest you look at google app engine it can be used to automate and control this: https://developers.google.com/appengine/docs/whatisgoogleappengine
Also look at these open-source dashboards: https://github.com/twilio/stashboard
I'm going to write my first Java based web app, and I'm sort of lost how to begin.
Firstly, I would like a web app and a desktop app that do pretty much the same thing, without the hackish idea of embedding a web browser into the desktop app because that doesn't allow to easily make changes to the desktop without affecting the web app and vice versa.
Now, here my questions.
Right now, I have a bunch of POJOs and they communicate with a single class that, right now, uses a flat file as a "database", of course, in production, I would use a legitimate database and just change that single class. Is this a good idea? Will I be able to go from POJOs to a web app?
Should I use a framework? I would like to have this app written pretty soon, seeing that all the buisness logic is there, I just need to wrap it so its usable, so, I don't want to spend an extreme amount of time learning, say, Spring (which AFAIK is huge), but, I don't want to keep reinventing the wheel throughout my app either. I can always just use JSP and scriptlets...
If you said yes to the above, what framework(s) do you suggest? Please note that I would like a framework that I can start using in maybe 3-4 weeks of learning.
Will I have to start from scratch with the POJOs that I have written? They're well over 30k LOC, so, if it is like that, I'll be hesitant.
You will need:
a web framework. Since you have Swing background, JSF 2 will be your best bet (everything will be painful, of course, but JSF will get you up and going quickly and will help you avoid the most tragic mistakes). Also, wrapping business pojos into web guis is the main use-case for JSF and it's biggest focus.
a "glue framework". One thing that is much different with web applications as opposed to desktop ones is that you cannot create view components by yourself - they must be created when browser requests a page. So you have to find a way to create the view objects and deliver all the references to the pojos that represent logic, some of which may have very different lifecycles (this is not a problem on desktop, but on web you have to distinguish between pojos that live along with the whole application, along with a single user session, along with a single request, and so on).
The "glue framework" could also provide the additional benefit of managing transactions. You have three choices:
Spring. It's not half as complex as you thing; you only need to learn some basic stuff.
EJB. You would need a real application server, like Glassfish or JBoss
bare JSF has good support for dependency injection, the only drawback is the lack of automatic transaction management.
If I were in your position, I would go with bare JSF 2.0 - this way you only need to learn one new technology. At first, try to avoid libraries like PrimeFaces - they usually work worse than advertised.
edit - and addendum
or - what is "dependency injection"(abridged and simplified)
When request comes to a web application, a new task starts in a new thread (well, the thread is probably recycled, but that's not important).
The application has already been running for some time and most of the objects you are going to need are already built and should not get created again: you have your database connection pool, maybe some parts of business layer; it is also possible that the request is just one of many request made during one session, and you already have a bunch of POJOs that the user is working on. The question is - how to get references to those objects?
You could arrange your application so that resources are available through some static fields. They may be singletons themselves, or they could be acquired through a singleton locator. This tends to work, but is out of fashion (hard to test, hard to refactor, hard to reuse, lifecycles are hard coded in application). The real code could look like this:
public void doSomething() {
Customer Service cs = AppManager.getInstance().getCustomerService();
System.out.println(cs.getVersion());
}
if you need clustering and session management, you could build a special kind of broker that would know and provide to anyone all kinds of needed objects. Each type of object would be registered as a factory under a different name. This also works and is implemented in Java as JNDI. The actual client code would look like this:
public void doSomething() throws Exception {
CustomerService cs = (CustomerService)new InitialContext().lookup("some_fancy_looking_name_in_reality_just_string");
System.out.println(cs.getVersion());
}
The last way is the nicest. Since your initial object is not created by you but by the server just after http request arrives (details depend on the technology you choose, but your entry point might be a JSF managed bean or some kind of action controller), you can just advertise which references you need and let the server take care of finding them for you. This is called "Dependency Injection". Your acts as if everything is taken care of before your code is ever launched. Spring or EJB container, or CDI, or JSF take care of the rest. The code would look like this (just an example):
#EJB
CustomerService cs;
public void doSomething() {
System.out.println(cs.getVersion());
}
Note:
when you use DI, it really uses one of the two former methods under the hood. The good thing is: you do not have to know which one and in some cases you can even switch them without altering your code;
the exact means of registering components for injection differs from framework to framework. It might be a piece of Java code (like in Guice), an XML file (classic Spring) or an annotation (classic EJB 3). Most of the mentioned technologies support different kinds of configuration.
You should definitely use a framework as otherwise sooner or later you'll end up writing your own.
If you use maven then simply typing mvn archetype:generate will give you a huge list of frameworks to choose from and it'll set up all of the scaffolding for you so you can just play with a few frameworks until you find the one that works for you.
Spring has good documentation and is surprisingly easy to get started with. Don't be put off by the pages of documentation! You could use JPA to store stuff in the database. You should (in theory) just be able to annotate your existing POJO's to denote primary keys and so on and it should just work. You can also use JSP's within Spring if that makes life easier.
... I a bunch of POJOs and they communicate with a single class that, right now, uses a flat file as a "database", of course, in production, I would use a legitimate database and just change that single class. Is this a good idea? Will I be able to go from POJOs to a web app?
qualified yes. if the pojo's are sane you should not have many problems. many people use hiberbate.
Should I use a framework? I would like to have this app written pretty soon, seeing that all the buisness logic is there, I just need to wrap it so its usable, so, I don't want to spend an extreme amount of time learning, say, Spring (which AFAIK is huge), but, I don't want to keep reinventing the wheel throughout my app either. I can always just use JSP and scriptlets...
probably. spring is huge, but things like grails or roo can help.
if you want to have a responsive web app, you will need to do some kind of rich client (AJAX). this may require a lot of your code to run on the client. this means writing a lot of javascript or using gwt. this will be a pain. it probably will not be so easy to just "wrap it". if you have written a swing app, then basically that code will need to run on the client.
If you said yes to the above, what framework(s) do you suggest? Please note that I would like a framework that I can start using in maybe 3-4 weeks of learning.
i like groovy and grails - grails uses spring-mvc, spring, hibernate. but there is roo, play and others.
Will I have to start from scratch with the POJOs that I have written? They're well over 30k LOC, so, if it is like that, I'll be hesitant.
the code that will run on the server can probably be mostly left alone. the code that has to run on the client needs to be rewritten in javascript or maybe you can get some reuse out of that code by using gwt,
The Play Framework is doing great things. I would recommend it highly. Having worked with EJB apps and Tomcat/Servlet/Spring apps it's a breath of fresh air. After framework installation you get a working app in a few seconds. Reminds me of Ruby on Rails or Node.js with the type-safety of Java.
Much quicker turnaround on getting started, faster development cycles, and a clearer configuration model than previous Java web app frameworks.
http://www.playframework.com/
We have a gwt-client, which recieves quite a lot of data from our servers. Logically, i want to cache the data on the client side, sparing the server from unnecessary requests.
As of today i have let it up to my models to handle the caching of data, which doesn't scale very well. It's also become a problem since different developers in our team develop their own "caching" functionality, which floods the project with duplications.
I'm thinking about how one could implement a "single point of entry", that handles all the caching, leaving the models clueless about how the caching is handled.
Does anyone have any experience with client side caching in GWT? Is there a standard approach that can be implemented?
I suggest you look into gwt-presenter and the CachingDispatchAsync . It provides a single point of entry for executing remote commands and therefore a perfect opportunity for caching.
A recent blog post outlines a possible approach.
You might want to take a look at the Command Pattern; Ray Ryan held a talk at Google IO about best practices in GWT, here is a transcript: http://extgwt-mvp4g-gae.blogspot.com/2009/10/gwt-app-architecture-best-practices.html
He proposes the use of the Command Pattern using Action and Response/Result objects which are thrown in and out the service proxy. These are excellent objects to encapsulate any caching that you want to perform on the client.
Here's an excerpt: "I've got a nice unit of currency for implementing caching policies. May be whenever I see the same GET request twice, I'll cache away the response I got last time and just return that to myself immediately. Not bother with a server-side trip."
In a fairly large project, I took another direction. I developed a DtoCache object which essentially held a reference to each AsyncCallback that was expecting a response from a service call in a waiting queue. Once the DtoCache received the objects from the server, they were cached inside the DtoCache. The cached result was henceforth returned to all queued and newly created AsyncCallbacks for the same service call.
For an already-fully-built, very sophisticated caching engine for CRUD operations, consider Smart GWT. This example demonstrates the ability to do client-side operations adaptively (when the cache allows it) while still supporting paging for large datasets:
http://www.smartclient.com/smartgwt/showcase/#grid_adaptive_filter_featured_category
This behavior is exposed via the ResultSet class if you need to put your own widgets on top of it:
http://www.smartclient.com/smartgwtee/javadoc/com/smartgwt/client/data/ResultSet.html
There are two levels of caching:
Caching during one browser session.
Caching cross browser sessions, e.g the cached data should be available after browser restarted.
What to cache: depend on your application, you may want to cache
Protected data for particular user
Public static (or semi-static, e.g rarely to change) data
How to cache:
For the first caching level, we can use GWT code as suggested in the answers or write your own one.
For the second one, we must use Browser caching features. The standard approach is put your data inside html (whether static html files or dynamic generated by jsp/servlet for example). Your application then use http://code.google.com/webtoolkit/doc/latest/DevGuideCodingBasicsOverlay.html techniques to get the data.
I thought Itemscript was kind of neat. It's a RESTful JSON database that works on both the client (GWT) and server.
Check it out!
-JP