Jeremy,
I think it is important to have a realistic application that demostrates the
key capabilities of SCA as a technology. From, that perspectice focus should
be on how SCA can be an SOA enabler, in terms of integrating systems built
on disparate platforms using a variety of technologies and exposing existing
software assets though new channels.
If we can build an application with a coherent set of use cases that will
demonstrate a set of container types and bindings working together, it would
demostrate the capabilities of SCA as a technology and Tuscany as an
implementation. I don't know how much the big bank sample fits the bill,
however, if it is realistic enough, we can build a realistic sample using
the big bank scenarios. From that angle we can look at,
1. The components involved in realising the solution
2. Container types for each component. For example, some components will be
in Java, some other will use a scripting language, some will be realised as
database stored procedures etc.
3. Define the appropriate binding types for integrating these components
together and exposing their services to external clients.
The application should demonstrate the following capabilities,
1. Different container types working together
2. Different binding types
3. Ability to enforce policies to realise enterprise-level QoS aspects.
The application with proper documentation on the implementation architecture
and model would be a good demonstrator for using SCA as a technology
platform for realising SOA.
Ta
Meeraj
From: Jeremy Boynes <[EMAIL PROTECTED]>
Reply-To: [email protected]
To: [email protected]
Subject: Sample framework
Date: Wed, 16 Aug 2006 15:53:55 -0700
We have had a rapid increase in the number of samples recently many of
which do essentially the same thing. Some feedback from M1 also said that
we seemed to have invented the greatest number of varieties of HelloWorld
but that it was hard to tell if SCA could do anything else. I'd like to
propose a change in how we structure the samples so that we make it
clearer to illustrate the technology to users.
Rather than having separate projects for each technology variant, I'd like
to suggest we have just a couple of projects that provide a framework and
then have instructions in the documentation for each technology that
clearly show how to apply it.
For example, I can see two framework environments:
a) a client environment with a simple command line client wires together a
couple of local components
b) a webapp environment with a simple JSP client that also wires together
a couple of local components
Then, for example, the JavaScript extension could say:
To illustrate the use of JavaScript as a component, take the client a)
and
1) replace <implementation.java class="Foo"/> with
<implementation.javascript script="foo.js"/>
2) Install javascript extension
2) rebuild/run sample
Or, to illustrate the WebService binding:
Server
1) Take webapp and add <service><binding.ws ...>
2) Install Axis binding extension
3) Deploy server app to Tomcat
Client
1) Take client application and replace <component name="foo" ...> with
<reference><binding.ws ...>
2) Install Axis binding extension
3) Run client
The basic idea being, have a common framework and the instructions on how
to use the particular extension.
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
_________________________________________________________________
The new Windows Live Toolbar helps you guard against viruses
http://toolbar.live.com/?mkt=en-gb
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
