Geoff, I think you are right on to my thinking w.r.t. threaded services. Technically, HiveMind isn't SOA because services can have some state. However, I think this is OK. One of the problems with traditional SOAs is that (due to location and language transparency), they must have complex parameters to pass and client-specific state.
HiveMind service interfaces are simple because a lot of "conversation" can go on, behind the scenes, via threaded/pooled services and event notifications. The public face is simple, the implementation involves a lot of collaboration. The use of proxies ensures that collaboration occurs properly, in accordance with the service model, without any imposition on the client code (or collaborating service). Things just lock together. > Create a service called HttpSessionService that is "pooled" > and has two > methods > Again, this is just the kind of thing I'm picturing for Tapestry 3.1 ... a central infrastructure service that "knows" about the current request. -- Howard M. Lewis Ship Independent J2EE / Open-Source Java Consultant Creator, Tapestry: Java Web Components http://howardlewisship.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
