I've created a new diagram to illustrate the HiveMind framework stack:
I think this is a good, at-a-glance to what HiveMind is doing for you; the Application has pulled a couple of facade services out of the HiveMind Registry, but the implementations of those services are dependent on many other services and configurations inside HiveMind and even on external entities (such as an session EJB inside the J2EE area).
5 comments:
This diagram seems to imply that users of HiveMind have a dependency upon J2EE APIs. Is that accurate?
No that's optional, but as a common case, it is streamlined via the EJBProxyFactory service. Chances are you're going to use *something* from J2EE, at least transaction support and database connection pools. The framework itself doesn't have dependencies on J2EE, though some services in the library do.
In your example, your Tapestry applications (pages and components) would be in the Application layer. The code that constructs those pages and components would be one domain within the Registry; your back-end APIs would be another domain.
Basically put, an HTTP GET doesn't magically connect to the Registry; there's still a presentation layer. But the layer is thin, just marshaling data that is then passed into services defined within HiveMind. This is familiar, J2EE session beans *can* fill a similar role, but because of all the developer and runtime issues related to EJBS, they tend to keep the presentation layer from being thin enough.
Could Tapestry Pages and Components also be Hivemind Services?
No. They serve very different roles. HiveMind services are best when stateless (there are other options, but they have higher runtime costs). Tapestry pages and components are very very stateful, that's the whole point.
Certainly you could have services that implement IRender and can thus render as part of a Tapestry page.
Post a Comment