Hello,
I have been working on a small module which allows the developer to write services as simple POJO implementations, and then generates the following artefacts from the implementation:
1) Service interface (extracted from all public methods of the implementation, unless specifically marked
to be excluded).
2) Stateless Session Bean facade (which will then be processed by ejbdoclet)
3) Business Delegate which uses the local interface of the SLSB facade
4) Business Delegate which uses the remote interface of the SLSB
5) Business Delegate which uses the POJO directly (by spring tags to be later processed by springdoclet). If this option is used then developers will most likely need a different spring config grafting transactional behaviour on the POJOs).
The driver behind this is to support IOC style development, to facilitate coding to interfaces and POJOs, changing the role of EJB to an implementation decision, and increasing productivity by generating the majority of artefacts.
So the developers can choose whether they want to work in a remote EJB invocation environment, local EJB invocation environment (because they know it will be a single tier deployment), or POJO invocation (because they only want to deploy in a web container, not a full J2EE container).
Currently, this module contains a few hard-wired assumptions geared towards our particular scenarios, but they are fairly easy to remove.
The question is, do XDoclet developers see this as a worthwhile module for core XDoclet? Personally, I do, because this style of development is becoming mainstream.
If it is seen as worthwhile to be included, I would be happy to contribute / maintain it.
--
Simon Godden
