river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From MICHAEL MCGRADY <mmcgr...@topiatechnology.com>
Subject Re: Standard Deployment Container [was:] Re: Jini Community Projects on Java.net WAS: Re: java.net
Date Thu, 09 Dec 2010 19:29:33 GMT
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
mmcgrady@topiatechnology.com




Mime
View raw message