On 11/9/06, Simon Laws <[EMAIL PROTECTED]> wrote:
On 11/8/06, Andrew Borley <[EMAIL PROTECTED]> wrote:
>
> Hi everyone,
>
> Now M2 is finally available, we should start thinking about what we'd
> like to do next in Tuscany C++. There were quite a few items that were
> suggested for M2 that we ended up leaving out for time reasons and it
> would be good to progress the function we have in M2.
>
> Things I would like to do/see:
> - Add initial support for SDO handling in the Python extension (as an
> XML serialization)
> - Remove requirement for componentType side-files for Python components
> - Get the PHP extension up to the level of the Ruby/Python extensions
> - perhaps by using the SCA for PHP stuff
> (http://www.osoa.org/display/PHP/SCA+with+PHP )
> - Improve the samples for the scripting languages (nebulous! does
> anyone have any good ideas?)
> - A sample showing the different languages working together.
> - A standalone REST binding - we can do a limited REST via the
> support in Axis2C, but I think it would be cool to have a real
> binding.rest that we can host in HTTPD.
>
> Please join in with your own thoughts/plans!
>
> Cheers
>
> Andy
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
> Hi Andy
I like the idea of extending the PHP extension and it would be pretty
interesting to see if we can make the PHP extension use the SCA for PHP work
we have in the PECL SCA_PHP project (see the homepage at
http://www.osoa.org/display/PHP/SOA+PHP+Homepage). I do of course have a
vested interest here ;-) In PHP SCA we don't use component type files
instead we rely on annotations and we also have SDO integration. The thing
about this is that we have a set of APIs that are, to some extent, an
interpretation of SCA and SDO as we thought they should be presented in a
scripting language. Now it may very well be that our interpretation needs
adjusting so this exercise of looking at PHP, Python, Ruby extensions to C++
SCA together will be really useful.
Of particular interest is how we push down the model from the scripting
language into the C++ model. So I imagine a set of APIs that allow us to
extend/complete the SCA C++ model by adding components type, components,
services, references, wires etc. as a result of parsing the information in a
supplied script. There is an interesting crossover point when it comes to
bindings, i.e. we have the oppotunity to leverage scripted or native
bindings.
+1 it would be good to re-jig the tuscany::sca::model::ModelLoader
class so that the loading/initialisation/wiring of composites can be
done either via files (as it is now) or programmatically. This would
allow extensions to define their composites via annotations, etc.
From a samples point of view, the likes of PHP and Ruby get used a lot to
implement web applications and particulary now as the service providers for
AJAX applications. In particuar we now have JSON-RPC/SMD support in PHP SCA
(just about to be checked into PECL). So we could do something there showing
how SCA describes integration through multiple application tiers.
The big question for me is how langauge specific do the sample have to be.
It's useful to have a single sample that shows how you do SCA stuff in all
of the different extensions. Calculator? But I think it would also be useful
to show the extensions operating in some more systematic sample. I'm a
little sceptical about just using the extensions arbitrarily in samples like
big bank but would rather use them where they are appropriate. So using a
PHP or Ruby component to provide the GUI experience for Big Bank makes
perfect sense. Just implementing the account service in Ruby or PHP is less
compelling.
I don't have that much experience of Python. The one time I have come across
it we were using it for infrastructure scripting I.e. we were using it in
place of a shell script so it would be interesting to have some SCA
components that play this role. In my particular case we we were providing a
job execution service so we had a number of scripts, e.g. assess job,
provision servers, provision data, run jobs, retrieve results etc.
We could pick any process where scritps are often use, e,g, ETL/data
processing pipelines or batch control. Perhaps we could invent some
data/document processing pipeline that has various scripted components that
can be wired in in different ways to change the end effect, for example, you
can imagine todays application developers being familir with scripting in
data integration scenarios where they have to build service which go and
pull answers from lots of web sites and data resources. A script being
required to handle the peculiarities of each web site's particluar API.
Typically a problems in the "tell me all the houses for sale in my area"
type of question. SCA script components would be good here because you can
use the environment most appropriate for the peculiaries of the particular
data source in question and then use SCA to stitch it together. Anyhow just
some thoughts.
This sounds like a good idea. These mash-up type applications would
fit pretty well with SCA I'd say (should actually make them easier).
In doing all this scripting stuff we need to think about how SCA is hosted.
Currently we have Axis and local hosting IIRC. We need to think about more
direct HTTPD hosting. This is not the same as, but fits alongside, the REST
binding thoughts.
Don't quite understand this - we can be hosted in Axis on HTTPD, and
create a REST binding to be hosted on HTTPD. Does direct HTTPD hosting
mean that SCA components can return HTML (or some other browser-usable
data) that is returned by the HTTP call? Kind of a less-formal REST?
Invoked via a call to
http://server/sca/compositeName/componentName/methodName or something
like that?
Are we maintaining the tasks link (
http://wiki.apache.org/ws/Tuscany/TuscanyCpp/Tasks)?
Not yet! Feel free to update it!
Thanks
Andy
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
