I want to exchange data between two applications JEE6/JSF2.0 and i'm looking for the best solution. I thought of the below solutions :
by using a JSON file.
by using XML file.
by using GSON file.
by using Remote interface (EJB 3.0).
For you, what's the best solution to use ?
edit : This two applications will be always running on the same network (but can not be on the same JVM)
I want to provide an alternative to David's answer, as I feel that there are some drawbacks to RMI that he underplayed.
This is a Java specific technology. If a third server needs to be introduced and it is a Microsoft Reporting Services server for example, then it cannot talk in the same language.
RMI is an OLD technology and doesn't particularly look well on a CV. Web services are the future. Experienced RMI developers are more uncommon than experienced web service developers.
Cumbersome and heavy framework
A better solution in my opinion would be to use SOAP XML based web services. Here are some advantages to this approach:
Universal acceptance in nearly any development framework. No matter the technology, nearly all have helpful libraries for interacting with web services.
Java has good support for object serialization into XML. This means objects can be quickly serialized into a SOAP XML request, sent to the other server, and deserialized back into a Java object by the other application server for processing.
A service layer can give you the decoupling interface between the two applications just as RMI can.
I hope you reconsider the use of SOAP XML based web services in your application.
There's two options really as you yourself stated.
Using RMI to connect to a EJB or using a webservice and communicating by JSON/XML etc...
From my experience RMI can be favorable if your applicaitons are on the same network, if not then you might get problems with firewalls etc and be forced to tunnel the RMI using HTTPS... which pretty much makes the RMI calls webservice calls.
If your on two different machines then webservices are nice as they dont cause as much trouble with firewalls. Also as they use the HTTP protocol you dont have to worry about the data being transfered.
These examples are kinda generalised but should give you some insight.
GSON vs XML vs JSON is a completely different subject... Non is superiour to the other, and all are fairly easily read by the human eye.
UPDATE
From what I've understod you wont have to worry about firewalls and such, I would recommend using RMI. It usually results in cleaner code and somewhat better performance.
Since I have seen both in action, I can make a comparison between the two technologies, EJB and WebServices. I can confirm that EJB is way more efficient, has support of transactions (including distributed transactions, if that is your requirement), exception handling, and binary streaming out of the box. In terms of performance EJB may exceed SOAP by a factor of 5 times in speed, and REST for about 3 times.
However, EJB is not an integration technology. In fact, it has never thought to do so. The biggest flaw of EJB is that it is very coupled to the Java Platform. Therefore, both endpoints must be written in Java and should use the same Java EE version.
Another problem is that EJB is not a protocol per se, so the implementations from two containers/vendors is probably different. If you need to access a remote EJB from JBoss AS on an Oracle WebLogic server, you must bring JBoss EJB client implementation with you.
Another big problem related to integration with EJB is a lack of data exchange format. Since it uses Java Serialized objects for communication, the data types must be shared on both ends. If you create a new exception type on the server that is classified as an Application Exception, if the client who consumes this service triggers the exception, his code will break. Note that, in this case the remote API was not violated, but another unknown type was introduced.
And, of course, by depending solely on the class type as an exchange format, you are giving the programmers opportunity for doing very stupid things. If you have many different teams in large projects using EJB as integration technology using different versions of Java EE, prepare yourself to experience uttermost pain. I've seem a programmer including a JPA entity on the client, who was annotated with named queries, the table which was accessing, its columns, etc, essentially giving away all the database layout to the service consumer. But it can get even worse. I've already seem a programmer returning a data structure that belonged to a dependency, namely Eclipselink 1.0. However, if you access this from a JBoss server, Eclipselink is also a JPA implementation technology, which conflicts with JBoss' hibernate. So, now you have to include Eclipselink jar in your JBoss APP classpath and configure the container for not loading JPA related packages, which otherwise will break your application completely. Even so, it can get WORSE than before: some other service you need to connect had also the bright idea of using the same datastructure, but now from Eclipselink 1.1.1, that has a different implementation, but the same class signature. Now you are in a very bad situation.
The bottom line: NEVER, EVER, use EJB as an integration technology. Use SOAP using a contract-first approach, where you define a canonical data model for the application, mapping java datastructures to a XML exchange format that can be used by any client, be it written in any language or using different stacks. Or use REST implementing a resource based, using HATEOAS principles. These days I rarely seem a reason for using EJB at all, since CDI is now on the market, support many features that EJB does and does not include any RPC related technology.
Related
Does anyone know where is a good example of GWT application with non-Java backend? Something like the "Contacts" application on the official pages of GWT. I'm interested in the following topics specifically (this is how I see the "back" part of the application, but it may be different, of course):
DTO serialization.
Communication layer (the very back one). Should it use generics and work with any abstract DTO? Is there any other proven approach?
Service layer, which uses the communication layer with specific DTOs.
Requests caching. Should it be implemended on the service or communication level?
Good abstraction. So we can easily substitute any parts for testing and other purposes, like using different serializators (e. g. XML, JSON), different servers' behaviors when managing user sessions (URL might change once the user is logged in).
I know, there are many similar topics here, but I haven't found one, which is focused on the structure of the client part.
Use REST on both sides. PHP/Python REST server-side. GWT client-side.
Don't use GWT-RPC.
The following gives a guideline for Java-java REST, but there is leeway to move out of server-side Java. It explains why REST is appropriate.
http://h2g2java.blessedgeek.com/2011/11/gwt-with-jax-rs-aka-rpcrest-part-0.html.
REST is an industry established pattern (Google. Yahoo, in fact every stable-minded establishment deploys REST services).
REST is abstracted as a HTTP level data structure. Which Java, PHP and Python have established libraries to comply to ensure DTO integrity.
Communication layer (the very back one). Should it use generics ???
Don't understand the question or why the question exists. Just use the REST pattern to provide integrity to non-homogeneous language between server and client and to HTTP request/response.
If you are using Java at back-end, there is no escape from using generics. Generics saves code. But using generics extensively needs programmer to have equally extensive visual capacity to visualise the generics. If your back-end is on PHP or Python, are there generics for PHP? Python generics? Might as well stay in Java land or C# land and forget about Java-free service provider.
Did you mean DTO polymorphism? Don't try polymorphism or decide on it until after you have established your service. Then adaptively and with agility introduce polymorphism into your DTOs if you really see the need. But try to avoid it because with JSON data interchange, it gets rather confusing between server and client. Especially if they don't speak the same programming language.
If you are asking HTTP level generics? I don't know of any framework, not SOAP, not REST where you could have generics carried by the XML or JSON. Is there? Generics?
Service layer? REST.
Requests caching? Cache at every appropriate opportunity. Have service-provider cache query results for items common and static to all sessions like menu, menu/drop-down box choices, labels, etc. Cache your history and places.
On GWT side cache records so that forward/backward button will not trigger inadvertent query. Use MVP pattern and history to manage history traversal that might trigger redisplay of info.
If you are talking about unified info abstraction, you should start your project with JAX-RS to define/test the API and perform data abstraction. Without performing any business logic.
Then, once your HTTP-level APIs andDTOs are defined, convert server-side to using language of your choice to proceed to write more complex code.
BTW, I don't dig your terminology "Backend".
We normally use the terminology client-side for service consumer, server-side for service provider, backend for data repository/persistence access, mid-tier or middle-ware for intervening/auxiliary software required to provide mathematical/scientific/graphical analysis/synthesis.
If our terminologies did not coincide, I probably answered this question wrong.
I have a couple of web services running on JBoss 5.1.0 GA with JBossWs native stack (shipped with JBoss 5.1.0 GA binary)
These web services are simple POJO services. Many of the WebMethods exposed by the services are of Complex Object type (I call these Complex types as DTO's) and a lot of custom defined exceptions. These DTO's are also bundled in a jar file, so that they can be used at the Client end as well.
I started creating a client using Eclipse (which I understand is using wsconsume to generate the client stub) and I saw that the utility would generate the DTO's from the WSDL and I could not find any way of enforcing the utility to use the DTO & exception classes provided in the jar file.
I had earlier asked a question on this on SO and could not find any answers.
From reading of various resources on wsconsume and generating client stub using eclipse (which would use JBossWS) i have now started to believe that what I am trying to achieve might not actually be possible using wsconsume.
My question is:
Is there a better way to create a client stub which would use the DTO classes from the jar files. I am open on changing the Client generation mechanism and move to axis or any other library for Client generation if that is possible. It would also be ideal if an ant task can be created for Client stub generation.
PS: My knowledge on web services is very limited and if I am being stupid with my question here, please pardon me for that.
Why do you want to use Data Transfer Objects in Your Web Service ? Is that necessary? Because If you use such objects, those web services can be use only in Java I think. That is a interoperability issue. So If you can avoid those kind of objects that will be a good practice.
I'm learning how to develop with OSGi in recent days, but facing a lot of problems.
I don't know how to design my client-server system based OSGi with Equinox as framework. Should I use socket connections to implement this or use a distributed model?
I'm also confused whether I need to import some third party packages to support my programming on socket, jdbc, swing, etc, or there're existing packages offered by Equinox or other OSGi open source projects?
First time to ask questions here, can anybody help me?
just take a look at OSGi Remote services implementations (more details in OSGi spec):
Web services (Apache CXF: distributed OSGi) - http://cxf.apache.org/distributed-osgi.html
Eclipse Communication Framework - http://www.eclipse.org/ecf/
Cheers,
Dmytro
The HTTP model is probably the simplest to implement, as opposed to protocols based on low-level socket handling and binary protocols.
The first question I'd ask is what kind of information your clients and server need to exchange. If you can live with HTTP (and in many cases you can), you can just use servlets on the server-side, http client libraries on the client side and a RESTful communications model.
Servlets are easy to implement in OSGi using the HttpService, see for example http://www.osgilook.com/2009/09/08/osgi-http-service-registering-servlets-on-the-fly/
Working with sockets is not more or less complicated in OSGi than it is in 'plain' Java. You design your application in much the same way as you would normally, but gain the benefits of modularity and services by using OSGi.
You could, for instance, decouple connection acceptance and request handling by introducing something like a WorkerFactory, or maybe reuse services on both the client and the server; those are the things that OSGi is good at.
OSGi as a 'technology' (as far as that notion holds water) does not mandate any specific interaction method. The compendium specification mentions Remote Services (a.k.a. Distributed OSGi), but it also contains an HTTP service specification is Servlets are your thing.
In short, just pick the interaction solution that best matches your scenario, and let OSGi help you with the services and modularity.
My question is very simple, my intention is to generate a repository with your responses so it could serve to the community when selecting frameworks for developing enterprise general purpose applications.
This could apply very well for general purpose languages such as C++, C# or Java.
What Framework do you recommend for generating Layered Architectures?
Based on you experience why do you prefer the usage of some Framework versus your own architecture?
How long do you believe your selected Framework will stay as a preferred option in the software development industry?
This is indeed an overly general question, especially since there are so many interpretations of the very word framework, and within the world of frameworks many different kinds for different tasks. Nevertheless, I'll give it a shot for Java.
Java
Java EE
The default overall enterprise framework of Java is called Java EE. Java EE strongly emphasis a layered architecture. It's a quite large framework and learning every aspect of it can take some time. It supports several types of applications. Extremely small and simple ones may only use JSP files with some scriptlets, while larger ones may use much more.
Java EE doesn't really enforce you to use all parts of it, but you pick and choose what you like.
Top down it consists of the following parts:
Web layer
For the web layer Java EE primarily defines a component and MVC based Web Framework called JSF - JavaServer Faces. JSF utilizes an XML based view description language (templating language) called Facelets. Pages are created by defining templates and letting template clients provide content for them, including other facelets and finally placing components and general markup on them.
JSF provides a well defined life-cyle for doing all the things that every web app should do: converting request values, validating them, calling out to business logic (the model) and finally delegating to a (Facelets) view for rendering.
For a more elaborate description look up some of the articles by BalusC here, e.g. What are the main disadvantages of Java Server Faces 2.0?
Business layer
The business layer in the Java EE framework is represented by a light-weight business component framework called EJB - Enterprise JavaBeans. EJBs are supposed to contain the pure business logic of an application. Among others EJBs take care of transactions, concurrency and when needed remoting.
An ordinary Java class becomes an EJB by applying the #Stateless annotation. By default, every method of that bean is then automatically transactional. Meaning, if the method is called and no transaction is active one is started, otherwise one is joined. If needed this behavior can be tuned or even disabled. In the majority of cases transactions will be transparent to the programmer, but if needed there is an explicit API in Java EE to manage them manually. This is the JTA API - Java Transaction API.
Methods on an EJB can easily be made to execute asynchronous by using the #Asynchronous annotation.
Java EE explicitly supports layering via the concept of a separate module specifically for EJBs. This isolates those beans and prevents them from accessing their higher layer. See this Packaging EJB in JavaEE 6 WAR vs EAR for a more elaborate explanation.
Persistence layer
For persistence the Java EE framework comes with a standard ORM framework called JPA - Java Persistence API. This is based on annotating plain java classes with the #Entity annotation and a property or field on them with #Id. Optionally (if needed) further information can be specified via annotations on how objects and object relations map to a relational database.
JPA heavily emphasizes slim entities. This means the entities themselves are as much as possible POJOs that can be easily send to other layers and even remote clients. An entity in Java EE typically does not take care of its own persistence (i.e. it does not hold any references to DB connections and such). Instead, a separate class called the EntityManager is provided to work with entities.
The most convenient way of working with this EntityManager is from within an EJB bean, which makes obtaining an instance and the handling of transactions a breeze. However, using JPA in any other layer, even outside the framework (e.g. in Java SE) is supported as well.
These are the most important services related to the traditional layers in a typical enterprise app, but the Java EE framework supports a great many additional services. Some of which are:
Messaging
Messaging is directly supported in the Java EE framework via the JMS API - Java Messaging Service. This allows business code to send messages to so-called queues and topics. Various parts of the application or even remote applications can listen to such a queue or topic.
The EJB component framework even has a type of bean that is specifically tailored for messaging; the message driven bean which has a onMessage method that is automatically invoked when a new message for the queue or topic that the bean is listening to comes in.
Next to JMS, Java EE also provides an event-bus, which is a simple light-weight alternative to full blown messaging. This is provided via the CDI API, which is a comprehensive API that among others provides scopes for the web layer and takes care of dependency injections. Being a rather new API it currently partially overlaps with EJB and the so-called managed beans from JSF.
Remoting
Java EE provides a lot of options for remoting out of the box. EJBs can be exposed to external code willing and able to communicate via a binary protocol by merely letting them implement a remote interface.
If binary communication is not an option, Java EE also provides various web service implementations. This is done via among others JAX-WS (web services, soap) and JAX-RS (Rest).
Scheduling
For scheduling periodic or timed jobs, Java EE offers a simple timer API. This API supports CRON-like timers using natural language, as well as timers for delayed execution of code or follow up checks.
This part of Java EE is usable but as mentioned fairly basic.
There are quite some more things in Java EE, but I think this about covers the most important things.
Spring
An alternative enterprise framework for Java is Spring. This is a proprietary, though fully open source framework.
Just as the Java EE framework, the Spring framework contains a web framework (called Spring MVC), a business component framework (simply called Spring, or Core Spring Framework) and a web services stack (called Spring Web Services).
Although many parts of the Java EE framework can be used standalone, Spring puts more emphasis on building up your own stack than Java EE does.
The choice of Java EE vs Spring is often a religiously influenced one. Technically both frameworks offer a similar programming model and a comparable amount of features. Java EE may be seen as slightly more light-weight (emphasis convention over configuration) and having the benefit of type-safe injections, while Spring may offer more of those smaller convenience methods that developers often need.
Additionally Spring offers a more thoroughly and directly usable security API (called Spring Security), where Java EE leaves a lot of security details open to (third party) vendors.
To specifically answer the second question:
Developing your own framework gives you the burden of having to maintain it and educating new developers in using it.
The larger your framework becomes, the more time you have to devote specifically to it and the less time you thus have to solve your actual business problem. This is okay if your business problem is the framework, but otherwise it can become a bit of a problem, even for very large companies that can dedicate a group of people to such a framework.
If you're a smaller company (say ~15 developer max) this can really become a huge burden.
Additionally, if your own framework is the kind of framework that can take advantage of third party developments (e.g. third parties can develop components for JSF), then your own framework obviously won't be able to take advantage of that.
Unless of course you open source your own framework, but this will only significantly increase the burden of supporting it. Just dumping your source code on sourceforge does not really count. You will have to actively support it. All of a sudden your framework becomes their framework with maybe 'weird' feature requests and awkward error reports for environments that you have no personal interest in.
This also assumes that your framework will actually be used by external users. Unless it's really very, very, good and you put lots of energy in it, this will probably not happen if it's simply the umpteenth Java web- or ORM framework.
Obviously, some people have to take up the job of creating new frameworks, otherwise the industry just stagnates, but if your prime concern is your business problem I would really think twice of starting your own framework.
Very vague question, I'm not really sure it's ever a good idea to "write your own" at this point for a work project (unless writing your own, IS the project). If it's a learning exercise, fine, but otherwise go use one of the libraries written by people who have been doing it far longer. If you really want to get involved, read their code, try and contribute patches etc.
For .Net there is Sharp Architecture Which is a pretty popular framework for layered applications.
Here's some of the stuff I use (I don't use Sharp Architecture)
First, the infrastructure stuff
For Dependency Injection, I use StructureMap. I use it because it's way more robust and performant than anything I would or could write, and it's very well supported within the .Net community. It also sticks to being DI, and doesn't venture out into other things that I might want to use other libs for (AOP etc). The fluent configuration is fantastic (but many .Net DI Tools have that now)
For AOP, I use Linfu Dynamic Proxy. I know a lot of people that like the code weaver variety for performance reasons, but that's always seemed a bit like premature optimization to me.
For a DataMapper, I use AutoMapper. This is one where I'm on again off again. If you can do your mappings based just on convention, then great, I'll use it. Once I have to start tweaking the configuration to do special things.... to me that starts to get into the gray area where the code might be more clear with just some left=>right wrapped in a function.
Web/UI
Asp.Net MVC. Although to be quite honest, I'm having a falling out lately and may soon be moving to FubuMvc. Asp.Net MVC seems like it has split personalities in terms of API design (dynamic over here, static over there, using blocks to render forms, but System.Actions to render other things etc). Combine that with the fact that it's not really OSS (you can't submit a patch), and to me there's a compelling reason why the community should come up with something better that's OSS.
Persistence
NHibernate, Specifically Fluent NHibernate. Sure I'd love to write my own OR/M, but at the same time I'm certain that the hordes of developers who have worked on NHibernate are way smarter than me.
Services/Distribution etc
WCF for Synchronous calls
NServiceBus for Messaging and most async calls.
Most of this stuff is OSS, so how long will it be around, well, I would imagine a good long while.
This question doesn't work very well. Selecting frameworks is difficult, and very context specific. For each selection process you might end up with a simple shortlist and a simple list of questions to answer, but those lists do not transfer well to other selections.
The number of parameters and the parameter sensitivity influencing a decision is very large, and at enterprise level a lot of them are not technical.
Currently, there are no frameworks available that are ready to support these near-term enterprise needs:
the switch for most of the workforce from pc to tablet and phone;
the switch from web client and rdbms to p2p/disconnected based storage and distribution
I am trying to figure out if I should migrate my gwt-rpc calls to the new GWT2.1 RequestFactory cals.
Google documentation vaguely mentions that RequestFactory is a better client-server communication method for "data-oriented services"
What I can distill from the documentation is that there is a new Proxy class that simplifies the communication (you don't pass back and forth the actual entity but just the proxy, so it is lighter weight and easier to manage)
Is that the whole point or am I missing something else in the big picture?
The big difference between GWT RPC and RequestFactory is that the RPC system is "RPC-by-concrete-type" while RequestFactory is "RPC-by-interface".
RPC is more convenient to get started with, because you write fewer lines of code and use the same class on both the client and the server. You might create a Person class with a bunch of getters and setters and maybe some simple business logic for further slicing-and-dicing of the data in the Person object. This works quite well until you wind up wanting to have server-specific, non-GWT-compatible, code inside your class. Because the RPC system is based on having the same concrete type on both the client and the server, you can hit a complexity wall based on the capabilities of your GWT client.
To get around the use of incompatible code, many users wind up creating a peer PersonDTO that shadows the real Person object used on the server. The PersonDTO just has a subset of the getters and setters of the server-side, "domain", Person object. Now you have to write code that marshalls data between the Person and PersonDTO object and all other object types that you want to pass to the client.
RequestFactory starts off by assuming that your domain objects aren't going to be GWT-compatible. You simply declare the properties that should be read and written by the client code in a Proxy interface, and the RequestFactory server components take care of marshaling the data and invoking your service methods. For applications that have a well-defined concept of "Entities" or "Objects with identity and version", the EntityProxy type is used to expose the persistent identity semantics of your data to the client code. Simple objects are mapped using the ValueProxy type.
With RequestFactory, you pay an up-front startup cost to accommodate more complicated systems than GWT RPC easily supports. RequestFactory's ServiceLayer provides significantly more hooks to customize its behavior by adding ServiceLayerDecorator instances.
I went through a transition from RPC to RF. First I have to say my experience is limited in that, I used as many EntityProxies as 0.
Advantages of GWT RPC:
It's very easy to set-up, understand and to LEARN!
Same class-based objects are used on the client and on the server.
This approach saves tons of code.
Ideal, when the same model objects (and POJOS) are used on either client and server, POJOs == MODEL OBJECTs == DTOs
Easy to move stuff from the server to client.
Easy to share implementation of common logic between client and server (this can turn out as a critical disadvantage when you need a different logic).
Disadvatages of GWT RPC:
Impossible to have different implementation of some methods for server and client, e.g. you might need to use different logging framework on client and server, or different equals method.
REALLY BAD implementation that is not further extensible: most of the server functionality is implemented as static methods on a RPC class. THAT REALLY SUCKS.
e.g. It is impossible to add server-side errors obfuscation
Some security XSS concerns that are not quite elegantly solvable, see docs (I am not sure whether this is more elegant for RequestFactory)
Disadvantages of RequestFactory:
REALLY HARD to understand from the official doc, what's the merit of it! It starts right at completely misleading term PROXIES - these are actually DTOs of RF that are created by RF automatically. Proxies are defined by interfaces, e.g. #ProxyFor(Journal.class). IDE checks if there exists corresponding methods on Journal. So much for the mapping.
RF will not do much for you in terms of commonalities of client and server because
On the client you need to convert "PROXIES" to your client domain objects and vice-versa. This is completely ridiculous. It could be done in few lines of code declaratively, but there's NO SUPPORT FOR THAT! If only we could map our domain objects to proxies more elegantly, something like JavaScript method JSON.stringify(..,,) is MISSING in RF toolbox.
Don't forget you are also responsible for setting transferable properties of your domain objects to proxies, and so on recursively.
POOR ERROR HANDLING on the server and - Stack-traces are omitted by default on the server and you re getting empty useless exceptions on the client. Even when I set custom error handler, I was not able to get to low-level stack traces! Terrible.
Some minor bugs in IDE support and elsewhere. I filed two bug requests that were accepted. Not an Einstein was needed to figure out that those were actually bugs.
DOCUMENTATION SUCKS. As I mentioned proxies should be better explained, the term is MISLEADING. For the basic common problems, that I was solving, DOCS IS USELESS. Another example of misunderstanding from the DOC is connection of JPA annotations to RF. It looks from the succinct docs that they kinda play together, and yes, there is a corresponding question on StackOverflow. I recommend to forget any JPA 'connection' before understanding RF.
Advantages of RequestFactory
Excellent forum support.
IDE support is pretty good (but is not an advantage in contrast with RPC)
Flexibility of your client and server implementation (loose coupling)
Fancy stuff, connected to EntityProxies, beyond simple DTOs - caching, partial updates, very useful for mobile.
You can use ValueProxies as the simplest replacement for DTOs (but you have to do all not so fancy conversions yourself).
Support for Bean Validations JSR-303.
Considering other disadvantages of GWT in general:
Impossible to run integration tests (GWT client code + remote server) with provided JUnit support <= all JSNI has to be mocked (e.g. localStorage), SOP is an issue.
No support for testing setup - headless browser + remote server <= no simple headless testing for GWT, SOP.
Yes, it is possible to run selenium integration tests (but that's not what I want)
JSNI is very powerful, but at those shiny talks they give at conferences they do not talk much about that writing JSNI codes has some also some rules. Again, figuring out how to write a simple callback was a task worth of true researcher.
In summary, transition from GWT RPC to RequestFactory is far from WIN-WIN situation,
when RPC mostly fits your needs. You end up writing tons conversions from client domain objects to proxies and vice-versa. But you get some flexibility and robustness of your solution. And support on the forum is excellent, on Saturday as well!
Considering all advantages and disadvantages I just mentioned, it pays really well to think in advance whether any of these approaches actually brings improvement to your solution and to your development set-up without big trade-offs.
I find the idea of creating Proxy classes for all my entities quite annoying. My Hibernate/JPA pojos are auto-generated from the database model. Why do I now need to create a second mirror of those for RPC? We have a nice "estivation" framework that takes care of "de-hibernating" the pojos.
Also, the idea of defining service interfaces that don't quite implement the server side service as a java contract but do implement the methods - sounds very J2EE 1.x/2.x to me.
Unlike RequestFactory which has poor error handling and testing capabilities (since it processes most of the stuff under the hood of GWT), RPC allows you to use a more service oriented approach. RequestFactory implements a more modern dependency injection styled approach that can provide a useful approach if you need to invoke complex polymorphic data structures. When using RPC your data structures will need to be more flat, as this will allow your marshaling utilities to translate between your json/xml and java models. Using RPC also allows you to implement more robust architecture, as quoted from the gwt dev section on Google's website.
"Simple Client/Server Deployment
The first and most straightforward way to think of service definitions is to treat them as your application's entire back end. From this perspective, client-side code is your "front end" and all service code that runs on the server is "back end." If you take this approach, your service implementations would tend to be more general-purpose APIs that are not tightly coupled to one specific application. Your service definitions would likely directly access databases through JDBC or Hibernate or even files in the server's file system. For many applications, this view is appropriate, and it can be very efficient because it reduces the number of tiers.
Multi-Tier Deployment
In more complex, multi-tiered architectures, your GWT service definitions could simply be lightweight gateways that call through to back-end server environments such as J2EE servers. From this perspective, your services can be viewed as the "server half" of your application's user interface. Instead of being general-purpose, services are created for the specific needs of your user interface. Your services become the "front end" to the "back end" classes that are written by stitching together calls to a more general-purpose back-end layer of services, implemented, for example, as a cluster of J2EE servers. This kind of architecture is appropriate if you require your back-end services to run on a physically separate computer from your HTTP server."
Also note that setting up a single RequestFactory service requires creating around 6 or so java classes where as RPC only requires 3. More code == more errors and complexity in my book.
RequestFactory also has a little bit more overhead during the request processing, as it has to marshal serialization between the data proxies and actual java models. This added interface adds extra processing cycles which can really add up in an enterprise or production environment.
I also do not believe that RequestFactory services are serialization like RPC services.
All in all after using both for some time now, i always go with RPC as its more lightweight, easier to test and debug, and faster then using a RequestFactory. Although RequestFactory might be more elegant and extensible then its RPC counter part. The added complexity does not make it a better tool necessary.
My opinion is that the best architecture is to use two web apps , one client and one server. The server is a simple lightweight generic java webapp that uses the servlet.jar library. The client is GWT. You make RESTful request via GWT-RPC into the server side of the client web application. The server side of the client is just a pass though to apache http client which uses a persistant tunnel into the request handler you have running as a single servlet in your server servlet web application. The servlet web application should contain your database application layer (hibernate, cayenne, sql etc..) This allows you to fully divorce the database object models from the actual client providing a much more extensible and robust way to develop and unit test your application. Granted it requires a tad bit of initial setup time, but in the end allows you to create a dynamic request factory sitting outside of GWT. This allows you to leverage the best of both worlds. Not to mention being able to test and make changes to your server side without having to have the gwt client compiled or build.
I think it's really helpful if you have a heavy pojo on the client side, for example if you use Hibernate or JPA entities.
We adopted another solution, using a Django style persistence framework with very light entities.
The only caveat I would put in is that RequestFactory uses the binary data transport (deRPC maybe?) and not the normal GWT-RPC.
This only matters if you are doing heavy testing with SyncProxy, Jmeter, Fiddler, or any similar tool that can read/evaluate the contents of the HTTP request/response (like GWT-RPC), but would be more challenging with deRPC or RequestFactory.
We have have a very large implementation of GWT-RPC in our project.
Actually we have 50 Service interfaces with many methods each, and we have problems with the size of TypeSerializers generated by the compiler that turns our JS code huge.
So we are analizing to move towards RequestFactory.
I have been read for a couple of days digging into the web and trying to find what other people are doing.
The most important drawback I saw, and maybe I could be wrong, is that with RequestFactory your are no longer in control of the communication between your Server Domain objects and your client ones.
What we need is apply the load / save pattern in a controlled way. I mean, for example client receive the whole object graph of objects belonging to a specific transaction, do his updates and them send the whole back to the server. The server will be responsible for doing validation, compare old with new values and do persistance. If 2 users from different sites gets the same transaction and do some updates, the resulting transaction shouldn't be the merged one. One of the updates should fail in my scenario.
I don't see that RequestFactory helps supporting this kind of processing.
Regards
Daniel
Is it fair to say that when considering a limited MIS application, say with 10-20 CRUD'able business objects, and each with ~1-10 properties, that really it's down to personal preference which route to go with?
If so, then perhaps projecting how your application is going to scale could be the key in choosing your route GWT RPC or RequestFactory:
My application is expected to stay with that relatively limited number of entities but will massively increase in terms of their numbers. 10-20 objects * 100,000 records.
My application is going to increase significantly in the breadth of entities but the relative numbers involved of each will remain low. 5000 objects * 100 records.
My application is expected to stay with that relatively limited number of entities AND will stay in relatively low numbers of e.g. 10-20 objects * 100 records
In my case, I'm at the very starting point of trying to make this decision. Further complicated by having to change UI client side architecture as well as making the transport choice. My previous (significantly) large scale GWT UI used the Hmvc4Gwt library, which has been superseded by the GWT MVP facilities.