Requiremets -- was:Java kernel release

[Francesco Furfari <fr...@isti.cnr.it>]

 > If you are interested in getting involved in helping implement some of
 > this or other parts of Tuscany, let us know and I am sure people will be
 > able to give you pointers to help get you started. Also, we're always
 > interested in hearing about your requirements, particularly since it
 > sounds as if you have several projects that may be able to make use of
 > these capabilities.

not several projects :-) just one, I'm currently involved in CASPAR 
project (http://www.casparpreserves.eu/) about the preservation of 
digital artefacts over time. Basically the objective is to implement, 
validate and extend the OAIS reference model 
(http://public.ccsds.org/publications/archive/650x0b1.pdf), so the main 
research interest is about metadata management of digital information 
objects, not s/w engineering per se.
You can get a top level view of the model at page 4-1, while the last 
page (F-1) give you a composite view of the functional entities.
Obviously I cannot state anything on behalf of the Project management, 
I'm reporting just my opinion. An effective software development should 
implies many of the aspects addressed by the SCA spec, I'm referring to 
the security, policy, transaction, conversational services and so on.
At the moment I haven't specific requirements, I can tell you my 
expectations.
The work will be developed among different partners developing specific 
components/subsystems and sharing them in a common source repository. I 
guess we should be able to build and deploy the whole system in a single 
host machine (one/multiple processes) for debugging purpose, but also 
set up a production network, as well as a network for testing the 
various releases.
Thus, for example, I appreciate in SCA the @AllowsPassbyReference in the 
data exchange semantic, because useful when deploying on a single 
process and, I think, to tune the system by grouping parts of it for 
performance reasons. I expect to administer nodes of the "test" network 
in which to deploy new versions, but also nodes in which are running 
components that I cannot install on my development node (e.g. different 
platform)

that's all so far.
regards
francesco



Jim Marino wrote:
> 
> On Jan 3, 2007, at 7:54 AM, Francesco Furfari wrote:
> 
>> Hi Jim,
>>
>> as you know my vision about Tuscany architecture is still limited, but 
>> I was wondering whether one of the JMX implementation at the Felix 
>> project could help you. Take a look at 
>> http://cwiki.apache.org/FELIX/mosgi-managed-osgi-framework.html
>>
>> This solution is tied to adopt an OSGi container. I thought that 
>> assemblies could be deployed as bundles, and the SCA system controlled 
>> using an OSGi-based JMX console.
>>
> Hi Francesco,
> 
> Meeraj has been leading the JMX integration so I'll let him talk about 
> what his plans are for it...
> 
> In terms of deploying assemblies as bundles, yes, we want to be able to 
> support that but we also have plans to do more. The SCA collaboration is 
> currently working on deployment (it is one of the big missing pieces 
> prior to releasing the specs as "1.0" versions). It is still very much a 
> work in progress but the idea behind SCA deployment is that we want to 
> support a variety of "packaging" formats as well as the ability to 
> contribute resources (e.g. Java classes, XSDs, WSDL port types, etc.) 
> that an assembly may reference. They key thing we want to do is decouple 
> how resources are referenced in an assembly and how they are physically 
> contributed to the SCA "domain". Another key thing is we want the 
> end-user experience to be very simple.
> 
> Some specific examples may help to explain this further. Say I have the 
> following component definition:
> 
> <component name="FooService">
>     <implemenation.java class="com.acme.Foo">
> </component>
> 
> How the com.acme.Foo service is contributed to the SCA runtime should 
> not be evident from the assembly SCDL, as shown above. It could have 
> been contributed through any of the following means:
> 
> 1. The class file was placed in a directory
> 2. A jar containing the class file was contributed to a "deployment" 
> service
> 3. An OSGi bundle containing the class file was contributed to a 
> "deployment" service
> 
> ..etc..
> 
> Similarly, the same mechanism could be used for WSDLs, XSDs, etc.
> 
> More specifically, two steps take place in this process. The first is 
> the resource is contributed to the SCA domain. The second step is the 
> assembly is mutated, for example, a component is instantiated using the 
> SCDL above. This allows for reuse. Sometimes these steps may be combined 
> from an end-user perspective. For example, I should be able to drop a 
> Java class in a directory and have the runtime introspect and deploy it 
> as a component. The runtime should also be smart enough to be able to 
> figure out how to provision components to various nodes in the service 
> network. For example, if I have a component that requires high 
> availability, it may deploy to a J2EE host environment running Tuscany. 
> Or, it may provision it to an OSGi container running Tuscany. Ditto for 
> the Standalone server.
> 
> By the time we are done defining the deployment API, I suspect we will 
> have something similar to Subversion.
> 
> If you are interested in getting involved in helping implement some of 
> this or other parts of Tuscany, let us know and I am sure people will be 
> able to give you pointers to help get you started. Also, we're always 
> interested in hearing about your requirements, particularly since it 
> sounds as if you have several projects that may be able to make use of 
> these capabilities.
> 
> Jim
> 
> 
>> Is this approach feasible for you or you prefer to add JMX support 
>> directly to the kernel?
>>
>> francesco
>>
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> 

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