"[EMAIL PROTECTED]" wrote : 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?"... View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4057903#4057903 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4057903 _______________________________________________ jboss-user mailing list [email protected] https://lists.jboss.org/mailman/listinfo/jboss-user
