We are now doing SOA migration and our old system's architecture is based on spring and hibernate. We use PO (persistence object) across all the layers.
When facing SOA migration, if we use DTO for remote procedure call, we have to create so many DTOs.
What are some suggestions on how to avoid this?
Develop a Canonical Model, probably the most important SOA pattern there is.
- Define a representation using an XML Schema for that model.
- Use jaxb to create the Java POJO representations.
Once you have these you 'could' map these to your existing Persistent Objects and then round-trip until they are equivalent.
Alternatively given you already use persistent object you could work bottom up with Jaxb, but in my experience that is more difficult/work intensive approach.
Related
I have built a proof of concept for a webapp I've been working on for the last year. My app already has a well defined set of operations that are reused by the business to interact with orientDB. The interactions start from simple insert/queries to objects, to complex object inheritance creation, and new relationship types creation.
Right now I'm moving my POC Architecture to a formal model, and I want to migrate what I did using only the orientDB java API, to a more formal JPA model; So far I have checked the code and examples for spring-data-orientdb and spring-data-gremlin, which seems to provide a JPA approach. My question is the following; If my model has no more than 5 queries, does it make sense to add the JPA model? and also, from this jpa model, can I still have transactionality for direct db operations like new type of vertex creation among data insertions? has anybody has experienced the use of this API, their pros an cons?
I understand that both are still in dev (Is Spring Data OrientDB production-ready?) but want to know if anyone has any advice on where to move forward, or if it's better to wait until the projects are mature and keep working with document/graph API?
Which is better when using JPA, especially when starting a new project?
Start with designing entities and then let JPA generate the database or
Start with the database schema and let tools generate entity classes?
im part of a small company. im both the software developer and DBA. i have complete freedom for the application and db design
im just starting the project
If you want to design a database, then start with the schema. If you want to write software, then start with the entities. The point of an ORM is to let you think about an object model without having to worry about the database that stores it, so questions of this type actually confuse the issue somewhat by insinuating crossover between the realms. Are you a software developer or a DBA? That, much more than the fact that you're using JPA, is what will determine the correct answer for you.
Um - neither? The power of JPA is that you don't have to generate one from the other! Generation of entities or database schema might be a good starting place if you have one already in place; but the generated stuff is not something you will want to use long term.
You cannot simply design one side of the mapping without any consideration of the other. If you will share the database with other applications, you will need to give more weight to the database schema. If your application has a complex model, you will want to focus on the object model first, allowing it to be driven by the use cases you uncover as you develop your application.
I tend to start with the object model first (even without a backing database to start) because that allows me to see the application in action earlier and get a feel for what we really want to build. But integration with the database must happen earlier rather than later; as its constraints will quickly impose themselves on your object model. :-)
It depends on one's needs . Usually in a product development environment , there are different teams which work on database design , interface design and implementation . So in that case , you have no option than generating the JPA entities from the already database design.
Secondly , if you are starting from the scratch and you know what are you upto then you can probably start writing your own entities (java class) and then generate the database from that.
Better go for database Scheme. Because some of the features r not available in JPA generated database.In JPA We cant give default values for our column. Check HERE for the allowable attributes in JPA.
Its upto you. whether to go top-down or bottom up approach. In case this schema would be exclusive to your application, see how your team members and analysts understand ORM or DB. In my experience analysts are better understand in terms of tables. But if they are good to discuss in terms of classes or UML diagrams go with JPA. Also, take into consideration views of your DBA and build engineer.
If you have complete flexibility and are not restricted to a DB schema and want a clean object model in your java application then start with with the model first and generate the schema from the model. This also allows you to generate clean JSON representations from the clean model to serve as on-the-wire format for your objects using technologies like Jackson (or GSON).
Doing DB Schema first and reverse engineering model classes from it will result in relational concepts seeping into your model classes resulting in poor (polluted) model.
In summary do model first unless your hands are tied and you must map to some existing schema.
Currently I am working on a project with Spring web-service, hibernate and JAXb.
1) I have generated hibernate beans using IDE 'hibernate code generation,
2) also, I have generated the jaxb beans using maven compiler.
..
Now, my question is,
1) Is this the right approach? (to have so many beans).
2) Shall I use JAXb beans for processing into the service layer? How can I keep layers decoupled?
3) Or, do I need to create another set of beans ie. map (JAXb beans) to (new beans) to (hibernate beans)?
.
Please tell your views?
Thanks,
adi
You know, you cannot have everything fully decoupled. There will be always a layer that will know the other two layers.
Usually when I design 3 layers architecture, like:
Service Layer - the one that probably uses JAXB, exposes web services or other APIs
Business Layer - any real logic
Persistence Layer - hibernate
I allow the Business layer to know about the Service Layer (JAXB) and about the Persistence Layer (hibernate beans). But I don't allow the Service Layer and the Persistence Layer to know about each other.
Note: I'm the EclipseLink JAXB (MOXy) lead and a member of the JAXB 2 (JSR-222) expert group. EclipseLink also provides an excellent JPA implementation (open sourced from TopLink).
There are costs to maintaining multiple models. Each model you add introduces a bean-to-bean conversion that must be written, tested, and maintained.
Another approach is to use the same beans for both the JPA and JAXB bindings. For this use case it will be easier to start with domain model and add JAXB & JPA metadata to apply mappings to XML and the database. Below is example of where a single model is leveraged to create a RESTful web service:
http://blog.bdoughan.com/2010/08/creating-restful-web-service-part-35.html
Since EclipseLink provides both JAXB and JPA implementations we provide a number of extensions to make this easier:
http://wiki.eclipse.org/EclipseLink/Examples/MOXy/JPA
http://blog.bdoughan.com/2010/07/jpa-entities-to-xml-bidirectional.html
UPDATE
In response to:
Agree to what you are saying. However, using same beans will couple
the code very tightly and will be highly dependent. Change in one
layer will need changes elsewhere as well. What you say?
It all depends how you look at things. My preference for building data access services is to design and build a solid domain model. Then use JPA and JAXB to solve the impedance mismatches between object-relational and object-XML.
One Model Approach
Using one model for both JPA and JAXB means that when you make a change to the model you need to decide at that time how it will be handled for both JPA and JAXB (this can be good or bad). If you don't want every new addition to the model to affect the JAXB mapping you can leverage JAXB concepts like #XmlAccessorType(XmlAccessType.NONE).
http://blog.bdoughan.com/2011/06/using-jaxbs-xmlaccessortype-to.html
Two (or More) Models Approach
When you want to add a field that is mapped to both relational and XML you need to add it to two models and add the necessary conversion logic. In this case there is a cost to keeping the models de-coupled.
I'm currently searching for a really easy way to get simple Java Objects persistent in Databases and/or XML and/or other types of data stores.
For big projects in the company i would use hibernate, ibatis, datanucleus or something like that. But with small private projects this will take over 80% of the worktime.
I also found "simpleORM" but this one requires to code data-related stuff pretty hardly into the data-model classes. I don't really like that style so this is no option for me.
Do you have a suggestion for some library which simply takes my objects and saves / loads them as they are or with very little configuration?
You could try my ORMLite library, which was designed as a simple replacement for hibernate and iBatis. I'm the main author. It supports a number of JDBC databases and has an Android backend. Here is the getting started section of the manual which has some code examples. Here also are working examples of simple usage patterns.
Try Norm. It's a lightweight layer over JDBC. It adds almost zero overhead to JDBC calls and is very easy to learn.
You could just serialize your objects into a file/database whatsoever.
If you want to define the mapping then you'd have to go for more configuration and the standard OR mappers out there (like Hibernate) don't really add that much on top.
You could try xstream. It's really simple OXM library working without upfront configuration.
Sample code:
XStream xstream = new XStream();
// marshalling
String xml = xstream.toXML(domainObject);
// unmarshalling
domainObject = xstream.fromXML(xml);
For relational database persistence try one of the JPA implementations, such as OpenJPA.
The setup overhead is minimal. You can let JPA to create your schema & tables for your from your object definitions, so you don't need to hand crank any sql. All you need to supply is some annotations on your entities and a single config file, persistence.xml.
You can also use jEasyORM (http://jeasyorm.sourceforge.net/).
In most cases it automatically maps objects to database tables with no need for configuration.
You may want to consider www.sormula.org. Minimal programming/annotations and simple learning curve. It uses standard SQL and JDBC so will work with any relational db.
U could try SnakeORM http://sourceforge.net/p/selibs/wiki/Home/
It doesnt have many runtime dependencies, uses JPA annotations and follows DAO pattern.
Disclosure: I am the author of this project
Well if you want an ORM, then that implies that you want to map objects to tables, columns to fields etc. In this case, if you want to avoid the hassle of bigger ORM implementations, you could just use plain old JDBC, with simple DataAccessor patterns. But then this does not translated to XML directly.
If you want to just persist the object somewhere, and only care about "understanding" the object in Java, then serialization is a simple effective method, as Thomas mentioned earlier.
You could also try my little ORM library, Java2DB. I created it specifically for small projects that just want quick and easy access to their database. Check it out on GitHub.
Onyx Database is a very feature rich Java NoSQL database alternative. It's pure java with several persisting modes (caching, embedded-database, save-to-remote, and save-to-remote-cluster. It has an embedded ORM, and is probably the easiest persistence API I've used.
How does ORM work? Are objects serialized into BLOBs?
In Java, is JDO still the way to go for this? What else is available? Seems like there was a lot of talk of EJB, direct object serialization, and JDO.
To answer your first question, here is an extract from Hibernate in Action, that says that there are various ways to implement ORM:
Pure relational
The whole application, including the
user interface, is designed around the
relational model and SQL-based
relational operations. This approach,
despite its deficiencies for large
systems, can be an excellent solution
for simple applications where a low
level of code reuse is tolerable.
Direct SQL can be fine-tuned in every
aspect, but the drawbacks, such as
lack of portability and
maintainability, are significant,
especially in the long run.
Applications in this category often
make heavy use of stored procedures,
shifting some of the work out of the
business layer and into the database.
Light object mapping
Entities are represented as classes
that are mapped manually to the
relational tables. Hand-coded SQL/JDBC
is hidden from the business logic
using well-known design patterns.
This approach is extremely widespread
and is successful for applications
with a small number of entities, or
applications with generic,
metadata-driven data models. Stored
procedures might have a place in this
kind of application.
Medium object mapping
The application is designed around an
object model. SQL is generated at
build time using a code generation
tool, or at runtime by framework code.
Associations between objects are
supported by the persistence
mechanism, and queries may be
specified using an object-oriented
expression language. Objects are
cached by the persistence layer. A
great many ORM products and homegrown
persistence layers support at least
this level of functionality. It’s well
suited to medium-sized applications
with some complex transactions,
particularly when portability between
different database products is
important. These applications usually
don’t use stored procedures.
Full object mapping
Full object mapping supports
sophisticated object modeling:
composition, inheritance,
polymorphism, and “persistence by
reachability.” The persistence layer
implements transparent persistence;
persistent classes do not inherit any
special base class or have to
implement a special interface.
Efficient fetching strategies (lazy
and eager fetching) and caching
strategies are implemented
transparently to the application. This
level of functionality can hardly be
achieved by a homegrown persistence
layer—it’s equivalent to months or
years of development time. A number
of commercial and open source Java ORM
tools have achieved this level of
quality. This level meets the
definition of ORM we’re using in this
book. Let’s look at the problems we
expect to be solved by a tool that
achieves full object mapping.
ORM = Object Relational Mapping, attributes of the objects are mapped to columns in the realational database. That mapping is arbitrary, so that could be done to blobs, in practise what is most useful tends to natural mappings - Strings to Varchars, int to integers etc.
JPA is the place to look for a standard for ORM. JPA replaces the EJB CMP approach, which was found to be cumbersome. JPA allows you to express the mapping as Java annotations and also allows the mappings to be specified in configutration files, when supporting multip[le databases the latter can be useful.
JPA has a query language so that you can construct queries against object attributes.
JPA is supported by the major App Server vendors and also by products such as Hibernate.
I found JPA pretty nice to work with, more so than EJB CMP.
I would recommend still using EJB Session Beans facades for transaction mamangement and security - the annotation-based approach makes EJB 3 way easier to use than EJB 2, minimal coding overhead.
JDO is actually standard ORM too, and provides a more complete a specification than JPA (1 + 2). JPQL is more focussed on RDBMS concepts and hence mimics SQL. JDOQL follows Java syntax so is more object based. Depends if your app is ever considered to go away from RDBMS. If so then JPA is not the way to go. If it is solely for RDBMS then JPA is definitely a consideration.
Whether objects are serialized into BLOBs depends on your configuration. You can do that for complex object types if you wish, but then they won't be queryable. If you instead persist them in a native form then you can also query them, leading to more efficient apps.
--Andy (DataNucleus - JDO and JPA persistence)