> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
