RuntimeInfo

[Meeraj Kunnumpurath <M....@voca.com>]

Hi,
 
I have been looking at adding runtime id to RuntimeInfo. I think there
may be some scope for refactoring the current classes and interfaces
used for realising runtime info. The core abstraction is the RuntimeInfo
interface in host-api with a specialized interface StandaloneRuntimeInfo
in standalone-host-api. The implementations include Standalone, Launcher
and Web runtime infos in addition to some of the mock ones used in
testing. Some of the methods defined in the RuntimeInfo interface is not
supported by the launcher and webapp runtime infos. Also, some of the
operations in the core abstractions like getInstallDirectory,
getBaseUrl, getApplicationDirectory can be refined further, I guess.
 
I think there are two broad categories of runtime info, client runtime
infos and server runtime infos. The server ones include any runtime that
stays up running and participate in a standalone or federated logical
assembly. These will include webapp, standalone tuscany server etc.
Properties like domain, runtime id etc are relavant to them. However,
for client runtimes like launcher that runs a specific application and
exits, some of these properties may not be relavant. However, there may
be common abstractions like profiles etc that are relavant for both
client and server runtimes.
 
I am planning to do some work around this area in conjunction with the
stuff I am doing on federation and discovery. It would be great to know
if others have any thoughts on refining the runtime info abstractions.
 
Many thanks
Meeraj


*****************************************************

    You can find us at www.voca.com

*****************************************************
This communication is confidential and intended for 
the exclusive use of the addressee only. You should 
not disclose its contents to any other person.
If you are not the intended recipient please notify 
the sender named above immediately.

Registered in England, No 1023742,
Registered Office: Voca Limited
Drake House, Three Rivers Court,
Homestead Road, Rickmansworth,
Hertfordshire, WD3 1FX


This message has been checked for all email viruses by MessageLabs.

Re: RuntimeInfo

[Jeremy Boynes <jb...@apache.org>]

I think there's a lot of history there and that we could do with a  
good cleanup. In particular I think the Launcher version should  
disappear all together. Also getApplicationDirectory is only there to  
support something in the Spring container and can probably be  
replaced as well. I've been trying to clean this up for a while and  
there are quite a few zombie methods (that throw UnsupportedOperation).

Rather than a client/server distinction though, my thinking here has  
been that the info would apply to an installation environment (such  
as "standalone" for "installed on disk" and "webapp" for "contained  
in a war"). Each environment would support client, server and other  
usage patterns. For example, a webapp may be a server application for  
users but to SCA it may be a pure client for business services. Or a  
client application may offer addressable services that are invoked  
when it is connected (via some async protocol).

The approach I took was to have a high level abstraction in  
RuntimeInfo for things that applied to every environment, with  
specializations for each installation environment for things that  
applied just to them. So, for example, every environment would  
support a baseURL for its installation for locating installation  
resources but it should not assume that mapped to a local directory;  
however, in the standlalone environment getProfileDirectory or  
getInstallDirectory would definitely map to local files.

--
Jeremy

On Jan 20, 2007, at 12:25 AM, Meeraj Kunnumpurath wrote:

> Hi,
>
> I have been looking at adding runtime id to RuntimeInfo. I think there
> may be some scope for refactoring the current classes and interfaces
> used for realising runtime info. The core abstraction is the  
> RuntimeInfo
> interface in host-api with a specialized interface  
> StandaloneRuntimeInfo
> in standalone-host-api. The implementations include Standalone,  
> Launcher
> and Web runtime infos in addition to some of the mock ones used in
> testing. Some of the methods defined in the RuntimeInfo interface  
> is not
> supported by the launcher and webapp runtime infos. Also, some of the
> operations in the core abstractions like getInstallDirectory,
> getBaseUrl, getApplicationDirectory can be refined further, I guess.
>
> I think there are two broad categories of runtime info, client runtime
> infos and server runtime infos. The server ones include any runtime  
> that
> stays up running and participate in a standalone or federated logical
> assembly. These will include webapp, standalone tuscany server etc.
> Properties like domain, runtime id etc are relavant to them. However,
> for client runtimes like launcher that runs a specific application and
> exits, some of these properties may not be relavant. However, there  
> may
> be common abstractions like profiles etc that are relavant for both
> client and server runtimes.
>
> I am planning to do some work around this area in conjunction with the
> stuff I am doing on federation and discovery. It would be great to  
> know
> if others have any thoughts on refining the runtime info abstractions.
>
> Many thanks
> Meeraj


---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org