Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[cosmos-dev] Using JPA in COSMOS


Joel/Don et al,

I've been trolling around the web looking for more information on JPA.  As we are starting to understand this a bit more it will be important to make sure we articulate where/how we intend to use this in COSMOS, esp. in regards to the use cases it satisfies.  With that in mind, I wanted to try and get clarity on a few initial areas.  

From the point of view from the persistence layer, I'm assuming the contract between the Data Filter & Transformation layer and the Data Sink is a collection of POJOs.  
Will these POJOs require JPA annotations?  Does this require the Data Sink to be a JPA implementation?  
Many of our scenarios account for the incorporation of legacy data stores that will not cleanly map into these new POJOs.  This is actually the default case since COSMOS will not ship its own data store, but will rely on one provided by TPTP.  How does JPA help us in this scenario?
In some scenarios, we may not have an RDB, e.g. the repository for SML and the resource information may be a file system.  What advantages does JPA provide in this situation?

When we met in Toronto we spent some time talking about experience learned from TPTP, esp. regarding the use of the EMF in the APIs.  No one seemed to like this at all.  As I was looking at the JPA examples, they do not appear to be much different--both include metadata in the Java classes about the underlying model.  The JPA annotations work in the same way.  Here's an example...

@ManyToOne()
    @JoinColumn(name="CUSTOMER_ID")
    public Customer getCustomer() {
        return customer;
    }

This little bit of code has several implications, for example, it reveals the structure of the RDB behind the scenes the same way that EMF did.  
Also, it tightly couples the database shcema--something we did not want to do.  In addition to the db schema, it also reveals very specific data base structure (the exposure of CUSTOMER_ID as a foreign key).  Are we repeating the same API mistake of TPTP?   What is the real value of JPA given these trade offs?


The above issues are from the standpoint of writing data to the database, here's some thoughts on querying...
Does the use of JPA require/force a set of APIs (EntityManager) on the Data Sinks, e.g. do they need to implement or be JPA "Entity Managers"?  Here's another example:
// Create new EntityManager
    em = emf.createEntityManager();

    Query q = em.createQuery("select c from Customer c where c.name = :name");
    q.setParameter("name", "Joe Smith");


We need to determine where this falls in the COSMOS framework, but I'm hoping this would be buried deep within the DC layer b/c we did not want to expose SQL.  I'm assuming that this would be fronted by some other service like API that would be the external API cosmos would offer, e.g. customerService.getCutomersByName("Joe Smith").  

I need to look at the query interfaces a bit more, but right now, I'm not sure how we handle security or large data sets, what if we get 10,000 "Joe Smiths"?  
Please let me know your thoughts.  I'm interested in what other issues we need to consider, including non-functional requirements,  e.g. does the use of JPA foster/inhibit adoption, et.

-mw



Mark Weitzel | STSM | IBM Software Group | Tivoli | Autonomic Computing | (919) 543 0625 | weitzelm@xxxxxxxxxx

Back to the top