I am new to SPRING and was assigned to work on project currently under development. Unfortunately development of the project has been slow so people have come and gone so I cant ask them why some things were done a certain way.
The project is a web service using SPRING.
They are using a View - Controller - Service (interface & implementation) - DAO (interface & implementation) - POJO (class used to transport data structure across layers).
Every POJO I have checked implementations serialization. On closer examination and search of the code, none of the POJO's are ever written or read, either in the POJO itself or any other file. Which has lead me to ask why its being done.
The POJO's are populated from Oracle statements in the DAO, which bubble upto the view, and then will bubble back down to the DAO where they information from them are written to the database using Oracle statements. The POJO itself is not written into the database.
Does SPRING MVC or java web applications require serialization and it is being used in the background? Is it needed to transmit the data between server and client connections? Is there a good reason that all the POJO's are using it that someone new would not recognize?
Depends on technologies used in the layers as well as implementation details.
If persistence is done using JPA/Hibernate then POJOs most likely will need to be Serializable.
In case if the POJO is passed to view via servlet session and session replication is on then you need to have your POJOs Serializable.
Use of Java's default serialization is a normal way for regular POJOs.
Java specifies a default way in which objects can be serialized. Java classes can override this default behavior. Custom serialization can be particularly useful when trying to serialize an object that has some unserializable attributes.
This might not be the correct answer, but so far in my case it matches and explains what I am seeing. I have not seen this information mentioned else where, but the answer is well upvoted, has been around for awhile, and is from a high reputation user, so I am inclined to trust it.
There is an answer from another question where they mention something important.
As to the why you need to worry about serialization, this is because most Java servlet containers like Tomcat require classes to implement Serializable whenever instances of those classes are been stored as an attribute of the HttpSession. That is because the HttpSession may need to be saved on the local disk file system or even transferred over network when the servlet container needs to shutdown/restart or is being placed in a cluster of servers wherein the session has to be synchronized.
The application Im working on DOES use Tomcat, so if this is a restriction or behavior, then I can easily see why all the POJO's are created in this fashion, simply to avoid issues that might develop later, and is a result of experience having worked with this all before, and its that experience that I am lacking.
Related
We are a complete SOA workshop(Java only) and we use SOAP for the data transfer. Currently we are in a process of centralizing the database work for a specific component so the other components can fetch data from one application using SOAP.
My argument is that it is good to centralize but it adds a lot of latency when adding soap between database calls. I want a RMI/EJB type of implementation so we get serialized object and it reduces the marshaling overhead. I like the way the Ejbs are implemented and would like to use it. But the data that we return is not at all from one table, so, I cannot return a database table entity, the data might be from 20 other tables or more.
So, in our current system we have custom entities which are created to map to heavy sql queries. (not related to one table)
Can ejbs be used for this type of environment? If so, are there libraries that are readily available to map the result of a query to entities?
Unfortunately our in-house system is very old, we use java 1.4.
This can be done, but it is going to be painful. There was a reason EJB 3.0 entity beans were created. It's because dealing with these sorts of complex requirements is really quite difficult to map via the old 2.x entity beans xml files.
If you are really building a new SOA layer to represent your database content, why would you do this with a technology that has been obsolete for almost 10 years?
Worse, building this with EJB 2.x and then using RMI/EJB will bind all of your other applications to this same outdated technology. Very few people would choose to start a new EJB 2.1 project.
I honestly believe that you are better off using SOAP for your service instead of EJB, at least it won't couple you to an obsolete platform. Current best practices prefer REST for entity transfer, and save SOAP for things RPC-style interactions, but there are lots of good libraries for doing your database tables to SOAP mappings, many of which are out-of-the-box for RDMS's.
Finally, if you are determined to do this, I'd suggest you first do a test. Build a test framework to actually see if the SOAP deserialization is a significant cost component. Compare it to the cost of the network transport. Unless these entities are in the megabyte range, deserialization will be a tiny fraction of your overall application time.
I'm currently stuck between two options:
1) Store the object's information in the file.xml that is returned to my application at initialization to be displayed when the GUI is loaded and then perform asynchronous calls to my backend whenever the object is edited via the GUI (saving to the file.xml in the process).
-or-
2) Make the whole thing asynchronous so that when my custom object is brought up for editing by the end-user it queries the backend for the object, returns the xml to be displayed in the GUI, and then do another asynchronous call for if something was changed.
Either way I see many cons to both of these approaches. I really only need one representation of the object (on the backend) and would not like to manage the front-end version of the object as well as the conversion of my object to an xml representation and then breaking that out into another object on the flex front-end to be used in datagrids.
Is there a better way to do this that allows me to only manage my backend java object and create the interface to it on the front-end without worrying about the asynchronous nature of it and multiple representations of the same object?
You should look at Granite Data Services: http://www.graniteds.org If you are using Hibernate: it should be your first choice, as BlazeDS is not so advanced. Granite implements a great facade in Flex to access backend java objects with custom serialization in AMF, support for lazy-loading, an entity cache on the flex-side with bean validation. Globally, it is a top-down approach with generation of AS3 classes from your java classes.
If you need real-time features you can push data changes on flex client (Gravity module) and solve conflicts on the front side or implement conflict resolvers on the backend.
Still you will eventually have to deal with advanced conflicts (with some "deprecated" flex objects to work with on the server: you don't want to deal with that), a basic feature for instance is to add a version field and reject manipulation of such objects on the backend automatically (many ways to do that): you will have to implement a custom way for a flex client to update itself to the current changes implying that some work could be dropped (data lost) on the flex client.
If not so many people work on the same objects on your flex application, this will not happen a lot, like in a distributed VCS.
Depending on your real-time needs (what is the frequency of changes of your java object? This is the most important question), you can choose to "cache" changes in the flex side then updating the whole thing once (but you'll get troublesome conflicts if changes have happened) or you can check everytime the server-side (granite enables this) with less conflicts (and if one happens: it is simpler) but you'll generate probably more code to synchronize objects and more network traffic.
In a complete Java EE application that's clustered is the DTO pattern still a valid option? The application in question uses EJBs Hibernate and Struts with Spring etc. Is there anything wrong with transferring domain objects in such a scenario?
EDIT: Just to clarify my question, with modern day resources and improvements in Java EE is there a reason not to just use domain objects? If there is not then isn't DTO pattern sort of fading out and shouldn't be used in new applications?
Is not deprecated. It depends on the application architecture if the DTO pattern should be used or not. For example, when you develop Web Services (using JAX-WS or JAX-RS), you should send DTO's over your web methods so a C# or Python client application may consume it, and your web method should not return an object which class has Hibernate annotations, remember than in other languages the Entity won´t be created with those annotations or other business logic inside.
EDIT (Based in your comment): That depends on the software architecture. For example, I'm working on a SOA project and we use DTO's for the Services Layer and the Presentation Layer. More deeper inside, we even use DTO's to handle database communication inside the services, we use only SP's to communicate with DB, so no Hibernate or any other ORM tools can work there, we could use Spring DAO and that framework uses DTO's too. You can find lots of DTO pattern in many applications nowadays.
More info that would be great for this question:
Difference between DTO, VO, POJO, JavaBeans? (where basically, any DTO is a POJO).
Core J2EE Patterns - Transfer Object
EDIT 2: Another source of information that will explain the main reason for using DTO's design, explained by Martin Fowler
LocalDTO
Conclusion: DTO's are not an anti pattern. DTO's are meant to be used only when you need to pass data from one subsystem to another and they don't have a default or standar way to communicate.
It is a very useful pattern in Java EE.
I use a DTO to transfer related entity objects from EJB beans to the UI layer. The entity objects are fetched from DB in one transaction (see TransactionAttributeType.REQUIRED) and stored in the DTO object. The DTO is consumed in the UI layer.
A pattern is pure design. There is no "deprecation" of pattern, but less usage over time (or over-usage).
Personally, I don't see why not to use DTOs.
For example - at oVirt open source project we have entities representing business logic entities in the domain of Virtualization.
These entities should be either annotated by Hibernate annotations (actually, they are today, as we started working on hibernate POCs) and serve as the DTOs , and then have clean from annotations objects that will mapped to them (let's say, using dozer framework) and used by client
(I don't like have at client side code with unnecessary annotations), or the entities should serve as the client objects (value objects) passed to the client and we should have other classes serve as the DTO entities
The minus in the above approach is that you might have 2 parallel class diagrams - one for DTOs and one for value objects (that are used by clients) - but , in many cases in design , there is a trade-off.
You must understand the advantages and disadvantages and pick what is best for you (In our case, since the client side is GWT, it will be easier for us to go for separation to two class hierarchies, one that is DTO/server side and can be also annotated with more server side only annotations, and the other sent to the GWT client code).
Hi everybody: let me do a bit of "concept mining" here: I am involved in mantaining/extending an application whose functionality is distributed across several servers. For example, we have a machine running the ApplicationServer, another running the DataServer and so on.
This application has a Web Interface. The current UI is totally implemented in Java, and in a way that makes adding new functionality hard. One of my goals is extending this interface, and we're considering shifting the whole thing to another platform, like Rails, for example.
Problem being, the database that is manipulated by the UI (possibly Rails in the future) is also manipulated by ApplicationServer (Java).
So, my main question is: both Rails and Java can access databases through their own ORM (ActiveRecord for Rails and Hibernate or similar for Java). Is there any way to guarantee that the mappings are consistent?*
Even if the answer is a hard "no", I'd also like to hear your thoughts on how you'd approach this scenario.
I hope the question is clear enough, but warn me if it isn't and I'll edit accordingly. =D
*Edit: per request, I'm extending this explanation: what I mean is, how to make sure things don't break when someone needs to add a new field to the database and edits the Hibernate mapping because of it? I know that Rails "guesses" the entity attributes pretty much by itself (making things easier), but I was wondering if there was some "magical way" to "connect" the ActiveRecord directly to the Hibernate mapping.
Depends on your case and how important it is to actually ensure that things won't break. I would probably code the Rails app to do its best, and then write a good set of db integration test cases for Rails to test against breakage.
Because Hibernate needs a mapping conf whereas Rails uses the database layout directly, it's best to do the db changes on Hibernate/mapped Java class side and then run the test suite on Rails side after changes.
this might be coming too late to the party, but ActiveJDBC is an ActiveRecord- like implementation in Java which reads metadata and configures self pretty much the same as ActiveRecord: http://code.google.com/p/activejdbc/
You should look at using DataMapper instead of ActiveRecord. DataMapper and Hibernate following roughly the same pattern so the mappings would be similar. Also, DataMapper defines the mapping in the class itself rather than figuring it out from the model. This is much closer to Hibernate and you could probably write a simple hbm to dm converter and just eval the output at the top of your model classes. If you didn't design your original data model with Rails in mind, none of the convention over configuration standards are likely to be there; with DataMapper, the default seems to be to map properties and relationships like Hibernate.
Another idea: if you use the Hibernate annotations instead of xml mapping, maybe you could JRuby as the bridge to build the Ruby model from the Java one.
But either way, if you have good tests, it should be obvious when a data model change break something.
I'm looking for a comprehensive setup that you've successfully used already. I've already loads of hints as to what building bricks I might use, but I'm not sure how to put it all together. Tools that need to be bought are OK, too.
Details:
I'm developing a Flex front end client for a Java server application and I have a set of model classes that represent objects in my business logic and should have the same properties and exhibit the same behaviour throughout all layers. These objects
have form validation logic for user input
are displayed in various forms (lists, detail views ...) throughout the UI
are retrieved from and sent to the server using XML or AMF
are validated again on the server
are stored in a RDBM with tables and fields corresponding to the classes and fields
This is a very common application structure, I guess. I'm already using:
ORM for the Java backend (Eclipse persistency package)
automatic mapping from XML to Action Script, using XML schema and the classes in mx.rpc.xml, as described here.
Now, what I'd really like to do is define the objects once (I already have them in XSD) and have tools set up class stubs for the whole chain. What can I use?
I've already heard of (but not evaluated):
XMLBeans to generate Java classes from XML Schema
Granite DS to generate AS classes from Java classes
I don't think your Flex UI should know or care about Java objects.
Take a "contract first", XML schema-drive approach and come up with the messages that you need to exchange between the Flex client and your service tier. Once you have that in place, the two are completely decoupled. That's a good start.
I'd also recommend not buying into a generation scheme. You'll only have to pay that price once during development.
I'm a Spring user, so I'd recommend Spring's "contract first" web services, using the Spring OXM interfaces. That will keep your UI and service tiers nicely decoupled. Use the org.springframework.oxm interfaces to do your mappings.
You can use Spring/BlazeDS to integrate your Flex UI with the Spring back end.
You have the full power of Spring IoC and AOP to create the back end.
I think you'll find it's a good approach for this problem.