How best to leverage Seam when you've got a HUGE domain?

[grettke_spdr]

Hi folks,

It looks like we will end up using a very large domain model, IBM's Insurance Application Architecture:

http://www-03.ibm.com/industries/financialservices/doc/content/solution/278918103.html

In a perfect world, we will not expose this complexity to the folks working on the UI. We thought about how to do this.

One thought was to provide sort of a component as facade, inject the entitymanager into that component, and make it responsible for doing the persistence itself rather than delegating it to another component (action) like we see in most of the examples.

Another thought was to implement the "service" model where all of the persistence work is delegated to DAOs or services. This *seems* conceptually easier for the majority of folks to understand, but I'm not sure. At the very least this is how folks seemed to use Struts type systems. Sort of backwards, but I think we can still leverage the power of Seam minus one big sweet spot.

What are your thoughts on this?

[gavin.king]

I don't fully understand what the difference between the two approaches is. By "DAO or service" you mean something in a different process?

[grettke_spdr]

I don't fully understand what the difference between the two approaches is. By "DAO or service" you mean something in a different process?

Hi Gavin,

My post was a bit vague, now I hope to clear that up.

IAA is very, very large. There are so many classes in the domain, and on top of that the "dream" is that you will use SOA to get information about different parts of the domain. Quite literally they envision you using lots of services that get you domain objects. Out of the box there is not a notion of getting complex objects, instead you go to each service to get what you need. How do the services make sense of references to other domain objects? Using the ObjectReference class of course, which is basically a numeric Id an some kind of a description.

Our goal is not to have folks worry about this complexity, and instead access a few services that "do the complicated work" behind the scenes. For example if we want to search for customers on address, the object graph behind the scenes may involve fourteen objects. We would like to provide a service "customer search" that shields the clients from this complexity. In particular the clients right now are the folks implementing the web application built around this domain. (As as aside, we won't use the full domain for the first rev of the app, nonetheless it is irrelevant to the client). This service model feels very much like the DTO approach to development, included is the "unique ID" in whatever form the "ObjectReference" takes. This seems in line with the spirit of IAA.

Behind the scenes we will use JPA to persist the domain. However, since it won't make sense to access that domain directly and make those entities components, we end up missing a big sweet spot of Seam: the notion of telling the UI folks to work with "these components" and then use the entity manager directly.

All of this leads us to questions like "Is Seam the right tool for this job?" (I think yes, we can still leverage the rest of its features), and "How can we make it easy for the developers?".

Right now it seems like there are two approaches:

1. Use a "service" based approach that returns DTOs. The DTOs populate the Seam components, users modify them, and those updated DTOs get sent back to the service to handle the persistence. (This is exactly what Seam sets out to avoid).

2. Use a component "facade" where we delegate all of the work to the component. The notion that the component is responsible for persisting itself, so the developer can utilize its features. How it fulfills those responsibilities is not important to the developer.

Perhaps my question should be "How best to leverage Seam in a strict SOA architecture?"...

[gavin.king]

I don't think its strange to use Seam in such a system. And you're exactly right to think along the lines of DTOs. For a simple application I hate DTOs, but if we are building services you are going to have to flatten your model at *some* point, and its just a question of doing it in Java vs. doing it in XML rendering. If you're using something like JAXB for getting stuff out of your services, then you should do it in Java. My preference is for a more rest-like approach where I would render XML using a template (facelets, perhaps) and the template s responsible for flattening the data in the entities.

Still not sure what a "component" is. More like a remote EJB?

[grettke_spdr]

Still not sure what a "component" is. More like a remote EJB?

Because my focus was so heavily on the UI, I keep thinking about Seam components and how best to leverage them. Those are the components of which I was thinking.

Thanks Gavin.