Hi All,

I have uploaded the proposed version of our site at
http://people.apache.org/~svkrish/tuscanySite/site-publish/.

Please take a look and give your feed back on things that needs changes.  At
the present moment here are somethings that yet need to be addressed: -
- The Release page for each of SCA, SDO and DAS is yet to be done.  I
imagine this page to list out the releases that we are making and against
each release information such as the specs version compatibility, the
features offered, known issues and so on. There is this sort of info for DAS
that is a part of the
http://people.apache.org/~svkrish/tuscanySite/site-publish/java_das_overview.html.

- The FAQs also need to be filled up.

Jean-Sebastien, could you please check if the site continues to have the
wrapping problem.  Could others help in testing the site on different
browsers?  Thanks

- Venkat


On 12/20/06, Simon Nash <[EMAIL PROTECTED]> wrote:

Jeremy Boynes wrote:

> On Dec 19, 2006, at 9:40 AM, Simon Nash wrote:
>
>> Jim Marino wrote:
>>
>>>
>> <cut>...</cut>
>>
>>>>
>>>>> Tuscany SCA allows services to be implemented in variety of
>>>>> languages  such as Java, JavaScript and C++. Tuscany SCA  runtime
>>>>> is implemented  in Java and C++ and can easily be  extended to
>>>>> support any  communication transport, qualities of  service or
>>>>> programming model  and can be used in conjunction  with other
>>>>> technologies such as  Spring, Axis and Celtix.
>>>>> [JFM the above sentence combines two separate things.  I would
>>>>> re-  word as:
>>>>> There are Java and C++ SCA runtimes that support services
>>>>> implemented  in variety of languages such as Java, JavaScript  and
>>>>> C ++. Both  runtimes and can easily be extended to support
>>>>> additional  communication transports, qualities of service or
>>>>> programming  models.  In addition, they can be used in
>>>>> conjunction  with other  technologies such as Spring, Axis and
>>>>> Celtix.]
>>>>
>>>>
>>>> Today we have two separate runtimes for Java and C++.  I'd like  to
>>>> see us
>>>> move towards what Venkat is describing, i.e., an integrated
>>>> runtime  that
>>>> supports components written in Java, C++ and other languages.
>>>>
>>> It depends on what you mean by "integrated". For me "federated"  may
>>> be a way to describe it as the runtime architectures are  fairly
>>> distinct as well as the capabilities of the two  implementations.
>>
>> "Federated" would be a good first step.  There could be further steps
>> beyond this into "integrated" territory, though I suspect that these
>> terms may have different interpretations for different people.  I'd
>> like to think this through a bit more and come back with some thoughts
>> on how this could work (whatever we call it).
>
>
> I don't see these as mutually exclusive - we should be able to  federate
> integrated runtimes :-)
>
> The languages supported by a runtime should not depend on the
> technology used to implement the runtime - for example, both Java and
> C++ runtimes already support components in non-native languages such  as
> Ruby or as SCA Composites. There's nothing stopping the Java  runtime
> from supporting C++ components or vice versa and work in that  area
> could be quite interesting.
>
> I think federation is at a larger scale - it's about making runtimes
> work together irrespective of implementation technology and author.  We
> can start that with one runtime (say C++ or Java) and extend  through
> Tuscany implementations to others' - although the more  general cases
> probably require specification.
>
This use of the terms "federated" and "integrated" makes sense to me.
In these terms I was thinking integrated, i.e., the ability of the
Tuscany Java and Tuscany C++ runtimes to know wbout each other and
work together in a seamless way to deploy and invoke components
written in a number of languages, some with a native runtime and others
hosted in a JVM environment.

As Jeremy says, this doesn't exclude federating multiple instances
of this integrated runtime.

   Simon


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Reply via email to