Tapestry Training -- From The Source

Let me help you get your team up to speed in Tapestry ... fast. Visit howardlewisship.com for details on training, mentoring and support!

Tuesday, June 15, 2004

HiveMind Framework Stack

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).


Mike S. said...

This diagram seems to imply that users of HiveMind have a dependency upon J2EE APIs. Is that accurate?

Howard said...

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.

sprint said...

If "Application" is implemented as a group of services (which live in the Registry) then what's left in "Application" proper?

For example, suppose you have an app fully implemented with HiveMind and the forecoming Tapestry 3.1+ where *everything* is a component/service that lives in the Registry, then you don't have an "Application" outside the Registry.

What I mean is that the "Application" is just a bunch of components/services.

Howard said...

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.

James said...

Could Tapestry Pages and Components also be Hivemind Services?

Howard said...

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.