Re: Standard Deployment Container [was:] Re: Jini Community Projects on Java.net WAS: Re: java.net

[MICHAEL MCGRADY]

There is a list of quality control criteria (QCC and commonly called the "Ilities") that is helpful to keep in mind when integrating into the networking mix.   Usability, not out of importance but out of alphabet, is last on the list.  ;-) MG 1a. accessibility, 1b. accountability, 1c. adaptability, 1d. administrability 1. affordability,  2. agility,  3. availability,  4. composability,  5. configurability,  5a. customizability, 5b. degradeability, 5c. demonstrability, 5d. dependability, 5e. distributability, 6. durability,  7. embedability,  8. evolvability,  9. extensibility,  10. failover,  10a.  flexibility, 11.    installability, 12. integrability,  13. interoperability,  14. maintainability,  15. manageability,  15a. mobility, 16. modifiability,  17. modularity,   17a. nomadicity, 17b. openness, 18. performance,  19. platform independence,  20. portability,  20a. predictability, 20b. recoverability, 21. reliability,  22. retractability,  23. reusability,  24. robustness,  25. scalability,  25a. seamlessness, 26. security,  27. servicability (supportability),   27a. simplicity, 27b. stability, 27c. survivability, 27d. tailorability, 28. testability,  29. understandability, and  30. usability On Dec 9, 2010, at 10:39 AM, Greg Trasuk wrote: On Wed, 2010-12-08 at 21:37, Peter Firmstone wrote: Usability is a tough problem we need to solve, I recall Dan Creswell highlighted some relevant issues.    If your looking at all the different down stream projects and want to get their cooperation for some common functionality, we'll need to get some community buy in.   These people are probably more aware of the pitfalls and I think we need their insight. There's all the different containers too.  Perhaps it's time we have a standardised deployment container?  So users can choose and migrate among any of the downstream projects or our own in house simple version (that supports what you're working on) without lock in. So, I've been working on a clean-room implementation of the Surrogate spec.  The work so far (mainly some building blocks) is in Subversion under jtsk/skunk/surrogate. I concluded early on that hosting Surrogates was really a subset of hosting plain old services.  As a result, the emerging architecture is that of a container that manages the classloaders and codebase servers, but that has a pluggable deployment architecture that can support surrogate packages, "starter-style" packages or other deployment units. To some extent, this container is "Harvester 2.0"; it reflects my unease with going through and restructuring the Harvester code for Apache release (I had thought about contributing Harvester, but decided to do this new surrogate container instead). I am envisioning a deployer that would support definition of services using annotations, much like EJB3 supports,  e.g. public interface HelloInterface {    public String sayHello(String name) throws IOException; } @Service public HelloService implements HelloInterface {    public String sayHello(String name) { return "Hi there " + name); }    /* @Proxy says "Inject my exported proxy here, please!" */    @Proxy    HelloInterface myProxy=null; } You would create your services, pack them into a jar file (with an appropriate manifest) and copy the jar file into the deployment directory.  The deployer then goes through the jar file looking for @Service annotations and exports them. The container will also host (with all the codebase crap handled!) instances of the River infrastructure services (Reggie, Mahalo, Outrigger, etc).  Plus it appears that enabling it for JMX monitoring and management will not be awfully difficult. The goal, much like Harvester, is one-shot deployment, with a programming model that will not seem alien to servlet or EJB programmers. So, stand by, the container is starting to come together.  Once it's in a form that can host Reggie and deploy a service or two, I'll let you know.  At that point, I suppose we'll want a catchy name... Cheers, Greg. -- Greg Trasuk, President StratusCom Manufacturing Systems Inc. - We use information technology to solve business problems on your plant floor. http://stratuscom.com Michael McGrady Chief Architect Topia Technology, Inc. Cel 1.253.720.3365 Work 1.253.572.9712 extension 2037 mmcgr...@topiatechnology.com

image001-2.pdf
Description: Adobe PDF document