Re: Component replacement and random thoughts....

[Daniel Kulp <da...@kulp.com>]

Just a quick question: has any actions been taken on this issue yet?   
Anymore thoughts or suggestions?  

Thanks!
Dan


On Friday 17 March 2006 16:51, Jeremy Boynes wrote:
> Daniel Kulp wrote:
> > (I apologize in advance for the length of this email...   After
> > meeting with Jim and Sebastien for the last two days, there are a LOT
> > of thoughts swirling around in my head....)
> >
> > One of the questions that came up in the discussions was something
> > along the lines of "if a user wants to replace the Axis 2 ws
> > implementation with Celtix, how would they do it?"    Or, more
> > generally:  "In tuscany, if I want to replace XXXX with YYYY where
> > YYYY is functionally equivalent, how can I do it?"   (XXXX being a
> > binding.*, container.*, etc...)
> >
> > The "simple" answer is something along the lines of: delete the XXXX
> > jars, add the YYYY jars, muck with the classpath, done.    However,
> > that really sucks.   Telling users to muck with things down on that
> > level is usually not a good idea and can generally result in bad
> > things happening.    The other problem with this approach is that
> > there is no way that a user could use BOTH XXXX and YYYY in the same
> > system since XXXX is completely deleted.
>
> This has been an area I have been wondering about as well as we start
> to increase the number of system services included in the runtime.
>
> In the SCA specification a module can be built up from multiple
> fragments which "magically" get combined together. In Java this is done
> by merging all "sca.fragment" files found on the classpath, coupling
> together the concepts of assembly with the provision of code.
>
> To be blunt, I think this sucks. It means that, as you describe, users
> end up mixing mucking with the classpath to perform SCA assembly, and
> potentially means they end up adding components to their application
> just because they needed a class from some jar file.
>
> It also does not deal with how configuration is done at the module
> level. Yes, one way is to include it in a subsystem definition but
> there is not consistency on how it is done for a bare module. For
> example, when a WAR file is deployed with an sca.module file in it then
> in Tuscany our approach is to define the module component name and URI
> from the webapps context path and leave all configuration properties as
> defaults.
>
> I would prefer to see a solution where we treated a module file as a
> type (which it is) and had configuration information in some other
> artifact - like a module component configuration file. This file would
> allow us to specify values for that module and would also allow us to
> define the location of the type (e.g. as the URL of the sca.module
> file).
>
> I know the argument has been that this requires the user to have a
> configuration file for the component. But, as a user, I actually prefer
> a model like that where I remain in control of what is running than one
> where things get configured by "magic."
>
> > One idea I came up with is a concept of "aliasing".    All components
> > would always register with a very specific name.   Instead of
> > binding.ws, it would be binding.axis2; instead of container.js, it
> > would be container.rhino, etc...      Tuscany would then have some
> > configuration that would "bind" the specific name to the "generic"
> > name.   This could come from a config file, a system property,
> > etc....     If the user want to change the underlying implementation
> > of one of the generic
> >
> > One advantage of this that the user then has more control in their
> > assembly.    If they want to use a more "portable" form and allow the
> > sca/tuscany runtime to use the default, they can do something like
> > "implementation.js" or "binding.ws" and the tuscany runtime would use
> > the appropriate one that is configured.    However, if the user wants
> > the specific version (using some advanced feature of axis or
> > something...), they can specifically use "binding.axis2" or
> > "implementation.rhino".   It allows complete coexistence.   In a
> > module, you could actually use both "binding.axis2" and
> > "binding.celtix" as well as the default "binding.ws" that may or may
> > not point to one of them.
>
> I think we need to extend this concept to the general level, applying
> to both user components and system services (like containers, bindings,
> etc). Any service provider must declare metadata about the services
> that it offers and any service consumer similarly declare what services
> it is willing to consume.
>
> For example, a JavaScipt service provider could declare that it
> provides "implementation.js", "implementation.rhino",
> "implementation.rhino.1R6" containers. Similarly, when deploying a
> component implementation the user could declare that it requires a
> "implementation.rhino" container environment. The deployment system
> would then be able to deploy that component to any runtime where
> "implementation.rhino" was available but not where some other
> implementation of .js was used.
>
> One idea I have floated before (but perhaps not on this list) is that
> the user can provide alternative implementations of a component. For
> example, they may choose to provide both Java and C++ implementations.
> This would allow the deployment system to select the most appropriate
> for the selected runtime (e.g. Java if deployed to a J2EE environment,
> C++ if front-end deployment to Apache HTTPD was selected).
>
> The key thing is that providers and consumers provider sufficient
> metadata about the service they are using to interact. This is not jsut
> functional (i.e. the API) but also non-function requirements like
> implementation language, version, quality of service, licensing, ...
>
> > The next "issue" this brings up is how to provide a usable system if
> > the user HASN'T configured anything (zero config) as well as validate
> > that a user that has configured something hasn't shot themself in the
> > foot.    On thought with this is that when something registers with
> > the system, it not only registers it's name, but also can return a
> > list of services it can provide.    Example:    Name: binding.axis2,
> > Provides: binding.ws
> >
> > With that additional bit of information, the runtime could
> > automatically wire stuff up with no configuration as well as validate
> > configuration. (example: I alias "binding.ws" to "binding.jsonrpc".  
> > That shouldn't work since jsonrpc doesn't provide that service.)    
> > In the case where there are two or more implementations that provide
> > a service, it could be a "first one registered" or "undetermined" or
> > anything.     The other thing about this is that a single "thing"
> > could possibly provide multiple services.    Example:    Name:
> > binding.celtix  Provides: binding.ws, binding.corba, binding.blah)
>
> I think this is a good direction to move in. We want as rich a metadata
> environment as possible, ideally one that captures all the criteria
> users use to determine which provider any consumer will use. I hope
> that if we have a rich enough model we don't end up with those kind of
> ambiguities, or if we do then it is because the user really doesn't
> care and so any of the available choices are valid.
>
> --
> Jeremy

-- 
J. Daniel Kulp
dan@kulp.com

Re: Component replacement and random thoughts....

[Jim Marino <jm...@bea.com>]

The following info may be somewhat related to this discussion....

For the recursive proposal under consideration in the spec, there is  
a way to specify a composite property which can be a complex type.   
Child components may have properties configured using an XPath  
expression that point to a property on their parent.  If we support  
some form of inclusion for properties, the composite property can  
actually be another xml file. This would allow us to define a  
"complex configuration" type that is edited by administrators in  
another xml file and then have runtime system services configured  
using xpath expressions pointing to parts of that complex type.  This  
will allow us to avoid having admins mess when SCDL of system  
composites.


Thoughts?

Jim

On Apr 13, 2006, at 10:54 AM, Jean-Sebastien Delfino wrote:

> Jeremy Boynes wrote:
>
>> Jean-Sebastien Delfino wrote:
>>
>>> Daniel Kulp wrote:
>>>
>>>> Just a quick question: has any actions been taken on this issue  
>>>> yet?   Anymore thoughts or suggestions? Thanks!
>>>> Dan
>>>>
>>>>
>>>>
>>>
>>> If we want to have a solution for this in our first release  
>>> before JavaOne, given the time we have left I think we need to  
>>> take a very simple approach. So here's what I'd like to suggest:
>>> - We do not change the programming model, an application  
>>> developer just says <binding.ws> to declare a web service binding
>>> - We probably don't have time to augment the programming model  
>>> with enough metadata and policies or profiles that will allow us  
>>> to dynamically pick a particular binding extension implementation
>>> - We just allow multiple implementations of a particular binding  
>>> (<binding.ws> for example) to exist on the classpath of the server.
>>> - We allow the system administrator to configure the binding  
>>> extensions that he wants active in a particular server
>>> - We could invent a new configuration file listing the binding  
>>> extensions to activate, or we can just say that the system  
>>> administrator can configure the extensions in a system.fragment  
>>> file under tomcat/conf.
>>>
>>>
>>
>> I would be concerned here about putting all the implementation  
>> details for all the extensions in a single file. The existing  
>> implementations already use multiple components and as they get  
>> more sophisticated they are only going to use more.
>>
>> I do like the idea though of having one file where the  
>> administrator can tweak the system configuration.
>>
>> I'd suggest therefore that we have one file in the tomcat conf  
>> tree (perhaps conf/tuscany/system.conf) which uses the proposed  
>> recursive model to declare each of the extensions as a sub- 
>> component. Something like:
>>
>> <composite name="tuscany.system">
>>    <component name="axis2 extension">
>>       <implementation name="axis2.module"/>
>>    </component>
>> <!--
>>    <component name="celtix extension">
>>       <implementation name="celtix.module"/>
>>    </component>
>> -->
>> </composite>
>>
>> where "axis2.module" and "celtix.module" are the names of  
>> composites that are defined by each extension.
>>
>>
>>> In other words, instead of having fixed system.fragment files  
>>> buried in the binding extension jars, we have one system.fragment  
>>> file under tomcat/conf, where the system administrator can  
>>> configure which binding extension implementations he wants to  
>>> activate. We could also use the same approach to configure which  
>>> component implementation / container types to activate on a  
>>> particular server.
>>>
>>>
>>
>> I agree we should move away from merging together system.fragment  
>> files. I think the proposal above moves in the direction you  
>> proposed but hides the internals of the extensions from the  
>> administrator.
>>
>>
>>> We could also extend this to activate binding and container  
>>> extensions on an application basis, but I'm not even sure we need  
>>> this right away. I think we can live with a per server config for  
>>> now, and revisit the approach later in June.
>>>
>>>
>> Agreed.
>>
>> -- 
>> Jeremy
>>
>>
>>
> +1 from me, I like that. Shifting the configuration of the  
> composite level is a (better) extension of what I was proposing,  
> although it requires us to get support for composites in place, but  
> it's a good move as well :) so if other people agree then I'd like  
> to see this implemented for our May release.
>
> -- 
> Jean-Sebastien
>
>

Re: Component replacement and random thoughts....

[Jean-Sebastien Delfino <js...@apache.org>]

Jeremy Boynes wrote:
> Jean-Sebastien Delfino wrote:
>> Daniel Kulp wrote:
>>> Just a quick question: has any actions been taken on this issue 
>>> yet?   Anymore thoughts or suggestions? Thanks!
>>> Dan
>>>
>>>   
>>
>> If we want to have a solution for this in our first release before 
>> JavaOne, given the time we have left I think we need to take a very 
>> simple approach. So here's what I'd like to suggest:
>> - We do not change the programming model, an application developer 
>> just says <binding.ws> to declare a web service binding
>> - We probably don't have time to augment the programming model with 
>> enough metadata and policies or profiles that will allow us to 
>> dynamically pick a particular binding extension implementation
>> - We just allow multiple implementations of a particular binding 
>> (<binding.ws> for example) to exist on the classpath of the server.
>> - We allow the system administrator to configure the binding 
>> extensions that he wants active in a particular server
>> - We could invent a new configuration file listing the binding 
>> extensions to activate, or we can just say that the system 
>> administrator can configure the extensions in a system.fragment file 
>> under tomcat/conf.
>>
>
> I would be concerned here about putting all the implementation details 
> for all the extensions in a single file. The existing implementations 
> already use multiple components and as they get more sophisticated 
> they are only going to use more.
>
> I do like the idea though of having one file where the administrator 
> can tweak the system configuration.
>
> I'd suggest therefore that we have one file in the tomcat conf tree 
> (perhaps conf/tuscany/system.conf) which uses the proposed recursive 
> model to declare each of the extensions as a sub-component. Something 
> like:
>
> <composite name="tuscany.system">
>    <component name="axis2 extension">
>       <implementation name="axis2.module"/>
>    </component>
> <!--
>    <component name="celtix extension">
>       <implementation name="celtix.module"/>
>    </component>
> -->
> </composite>
>
> where "axis2.module" and "celtix.module" are the names of composites 
> that are defined by each extension.
>
>> In other words, instead of having fixed system.fragment files buried 
>> in the binding extension jars, we have one system.fragment file under 
>> tomcat/conf, where the system administrator can configure which 
>> binding extension implementations he wants to activate. We could also 
>> use the same approach to configure which component implementation / 
>> container types to activate on a particular server.
>>
>
> I agree we should move away from merging together system.fragment 
> files. I think the proposal above moves in the direction you proposed 
> but hides the internals of the extensions from the administrator.
>
>> We could also extend this to activate binding and container 
>> extensions on an application basis, but I'm not even sure we need 
>> this right away. I think we can live with a per server config for 
>> now, and revisit the approach later in June.
>>
> Agreed.
>
> -- 
> Jeremy
>
>
+1 from me, I like that. Shifting the configuration of the composite 
level is a (better) extension of what I was proposing, although it 
requires us to get support for composites in place, but it's a good move 
as well :) so if other people agree then I'd like to see this 
implemented for our May release.

-- 
Jean-Sebastien

Re: Component replacement and random thoughts....

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

Jean-Sebastien Delfino wrote:
> Daniel Kulp wrote:
>> Just a quick question: has any actions been taken on this issue yet?   
>> Anymore thoughts or suggestions? 
>> Thanks!
>> Dan
>>
>>   
> 
> If we want to have a solution for this in our first release before 
> JavaOne, given the time we have left I think we need to take a very 
> simple approach. So here's what I'd like to suggest:
> - We do not change the programming model, an application developer just 
> says <binding.ws> to declare a web service binding
> - We probably don't have time to augment the programming model with 
> enough metadata and policies or profiles that will allow us to 
> dynamically pick a particular binding extension implementation
> - We just allow multiple implementations of a particular binding 
> (<binding.ws> for example) to exist on the classpath of the server.
> - We allow the system administrator to configure the binding extensions 
> that he wants active in a particular server
> - We could invent a new configuration file listing the binding 
> extensions to activate, or we can just say that the system administrator 
> can configure the extensions in a system.fragment file under tomcat/conf.
> 

I would be concerned here about putting all the implementation details 
for all the extensions in a single file. The existing implementations 
already use multiple components and as they get more sophisticated they 
are only going to use more.

I do like the idea though of having one file where the administrator can 
tweak the system configuration.

I'd suggest therefore that we have one file in the tomcat conf tree 
(perhaps conf/tuscany/system.conf) which uses the proposed recursive 
model to declare each of the extensions as a sub-component. Something like:

<composite name="tuscany.system">
    <component name="axis2 extension">
       <implementation name="axis2.module"/>
    </component>
<!--
    <component name="celtix extension">
       <implementation name="celtix.module"/>
    </component>
-->
</composite>

where "axis2.module" and "celtix.module" are the names of composites 
that are defined by each extension.

> In other words, instead of having fixed system.fragment files buried in 
> the binding extension jars, we have one system.fragment file under 
> tomcat/conf, where the system administrator can configure which binding 
> extension implementations he wants to activate. We could also use the 
> same approach to configure which component implementation / container 
> types to activate on a particular server.
> 

I agree we should move away from merging together system.fragment files. 
I think the proposal above moves in the direction you proposed but hides 
the internals of the extensions from the administrator.

> We could also extend this to activate binding and container extensions 
> on an application basis, but I'm not even sure we need this right away. 
> I think we can live with a per server config for now, and revisit the 
> approach later in June.
> 
Agreed.

--
Jeremy

Re: Component replacement and random thoughts....

[Jean-Sebastien Delfino <js...@apache.org>]

Daniel Kulp wrote:
> Just a quick question: has any actions been taken on this issue yet?   
> Anymore thoughts or suggestions?  
>
> Thanks!
> Dan
>
>   

If we want to have a solution for this in our first release before 
JavaOne, given the time we have left I think we need to take a very 
simple approach. So here's what I'd like to suggest:
- We do not change the programming model, an application developer just 
says <binding.ws> to declare a web service binding
- We probably don't have time to augment the programming model with 
enough metadata and policies or profiles that will allow us to 
dynamically pick a particular binding extension implementation
- We just allow multiple implementations of a particular binding 
(<binding.ws> for example) to exist on the classpath of the server.
- We allow the system administrator to configure the binding extensions 
that he wants active in a particular server
- We could invent a new configuration file listing the binding 
extensions to activate, or we can just say that the system administrator 
can configure the extensions in a system.fragment file under tomcat/conf.

In other words, instead of having fixed system.fragment files buried in 
the binding extension jars, we have one system.fragment file under 
tomcat/conf, where the system administrator can configure which binding 
extension implementations he wants to activate. We could also use the 
same approach to configure which component implementation / container 
types to activate on a particular server.

We could also extend this to activate binding and container extensions 
on an application basis, but I'm not even sure we need this right away. 
I think we can live with a per server config for now, and revisit the 
approach later in June.

Any opinions?

-- 
Jean-Sebastien