Cart
[Home] [By Thread] [By Date] [Recent Entries]
> From: Leigh Dodds [mailto:ldodds@i...] <snip/> > In particular I think I think that a good worked example would be to > take the canonical "Java Pet Store" example used in the Sun Blueprints > and show how it can be made RESTful. Do you think thats something > worth working through? That sounds like it could be useful. > To start things off, I've been assuming that being RESTful would imply > changes to the presentation layer only. The business logic remains > untouched. I would agree. However, I think some additional abstractions would probably be necessary beyond the EJBObject interface. In some cases, a REST resource might map onto an EJBObject in a 1:1 fashion. I think there will be cases, though, where it is not that straightforward. For instance, a mutable resource might actually rely upon a StatelessSessionBean (which relies upon state encapsulated in the resource, and which may internally manipulate one or more EntityBeans) for the actual processing. I think you'd probably want one central dispatcher that is tied to a particular URL or set of URLs. Additional relative paths can be tacked onto that URL to reference particular resources. These resources would be actual components managed by the dispatcher in a fashion similar to how app servers manage EJBs. The dispatcher would use the full URL to identify the resource being addressed, rather than using criteria in a POST-ed message for this (which is the common case in current web apps). Alternatively, some resources might be modeled directly by an independent servlet or JSP. But it seems to me that this would not work for transient resources. You would need a central dispatcher/manager for transient resources, and these transient resources would typically be very lightweight components intended to manage one portion of a workflow.
|
