Simon Laws wrote:
On 12/8/06, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
Simon Laws wrote:
> On 12/8/06, Pete Robbins <[EMAIL PROTECTED]> wrote:
>>
>> On 08/12/06, Simon Laws <[EMAIL PROTECTED]> wrote:
>> >
>> > I've been thinking about the types of scripts that we might want to
>> > support
>> > in our PHP extension for the C++ SCA runtime. I've tried to extend
the
>> > calculator sample from the Ruby and Python extension and made notes
on
>> the
>> > PHP SOA web site (
>> >
>>
http://www.osoa.org/display/PHP/PHP+SCA+Extension+For+Tuscany+CPP+SCA).
>> An
>> > interesting question arises about who provides composite
>> information. As
>> > it
>> > stands the PHP SCA implementation does not support SCDL files
and all
>> > composite information is provided in annotations in the PHP
file. For
>> > example, a calculator component might look like:
>> >
>> > ...
>> >
>> > include 'SCA/SCA.php';
>> >
>> > /**
>> > * @service
>> > * @binding.ws
>> > */
>> > class Calculator {
>> >
>> > /**
>> > * @reference
>> > * @binding.php Add.php
>> > */
>> > public $add_service;
>> >
>> > /**
>> > * @reference
>> > * @binding.php Subtract.php
>> > */
>> > public $sub_service;
>> >
>> > /**
>> > * @reference
>> > * @binding.php Multiply.php
>> > */
>> > public $mul_service;
>> >
>> > /**
>> > * @reference
>> > * @binding.ws Divide.wsdl
>> > */
>> > public $div_service;
>> >
>> > /**
>> > * Addition
>> > *
>> > * @param float $num1 (the first number)
>> > * @param float $num2 (the second number)
>> > * @return float The result
>> > */
>> > function add($num1, $num2) {
>> > return $this->mul_service->add($num1, $num2);
>> > }
>> >
>> > /**
>> > * Subtraction
>> > *
>> > * @param float $num1 (the first number)
>> > * @param float $num2 (the second number)
>> > * @return float The result
>> > */
>> > function sub($num1, $num2) {
>> > return $this->mul_service->sub($num1, $num2);
>> > }
>> >
>> > /**
>> > * Multiplication
>> > *
>> > * @param float $num1 (the first number)
>> > * @param float $num2 (the second number)
>> > * @return float The result
>> > */
>> > function mul($num1, $num2) {
>> > return $this->mul_service->mul($num1, $num2);
>> > }
>> >
>> > /**
>> > * Division
>> > *
>> > * @param float $num1 (the first number)
>> > * @param float $num2 (the second number)
>> > * @return float The result
>> > */
>> > function div($num1, $num2) {
>> > return $this->div_service->div($num1, $num2);
>> > }
>> > }
>> > ?>
>> >
>> > Note that this contains enough binding information for the PHP SCA
>> runtime
>> > to operate without composite files (see
>> > http://www.osoa.org/display/PHP/SCA+Documentation for more detail
>> of the
>> > PHP
>> > SCA programming model). The ideal solution would be if we could
drop
>> these
>> > kinds of PHP files into an SCA application and have the C++ SCA
>> runtime
>> > pick
>> > them up, parse them, and wire them into the application
automatically.
>> > This
>> > would mean that the XML composite model of the application would be
>> > incomplete and consequently composite file writers (tools) would
>> have to
>> > look at the PHP script for service and reference information. To
>> make it
>> > work the C++ SCA runtime would need some work in the way that is
loads
>> > component implementations and to allow the model to be updated
>> after the
>> > composite files have been read.
>> >
>> > An intermediate step would be to ignore any binding information in
the
>> PHP
>> > file and rely on information provided in a composite file. This is
the
>> way
>> > that C++ SCA currently works and so provides a stepping stone to
the
>> fully
>> > featured solution with minimal changes to the C++ SCA runtime.
>> >
>> > Thoughts?
>> >
>> > Simon
>> >
>> >
>> Simon, the C++ core runtime needs to have an SPI for defining
meta-data
>> dynamically. Currently there is a once only loading of the scdl model
>> during
>> startup. With such an SPI an extension could add components etc. as
>> required. It may be less effort to develop this SPI than to develop
>> tools
>> for parsing the PHP and generating SCDL files.
>>
>> Cheers,
>>
>> --
>> Pete
>>
>> Hi Pete
>
> Apologies that I wasn't clear. I wasn't suggesting we develop tools
for
> parsing the PHP and for generating SCDL files. The PHP engine already
> parses the PHP files and annotations for us and provides a
programmatic
> mechanism for accessing the annotation information. What I was
suggesting
> was, I think, what you are talking about with an SPI, i.e. we could
> programmatically take the annotation information and introduce it into
> the
> SCA model when the component implementation is loaded. My real point
here
> though is that with the full blown PHP SCA programming model there
is no
> SCDL file that specifies which PHP to load. All the composite
> information is
> help in annotations. So the C++ runtime would have to find likely PHP
> files
> and load them in order to complete the description of the composites
> that it
> needs to form a complete and consistent system. The flip side is that,
on
> disc, the system wiring would be described by a combination of
> composite and
> php files.
>
> We could of course create a composite file manually as a way of
> introducing
> PHP components into the system. Either an partial/incomplete composite
> file:
>
> <composite xmlns="http://www.osoa.org/xmlns/sca/1.0";
> name="sample.calculator">
>
> <component name="CalculatorComponent">
> <implementation.php module="Calculator" scope="composite"/>
> </component>
>
> </composite>
>
>
> Or a complete(ish) one
>
> <composite xmlns="http://www.osoa.org/xmlns/sca/1.0";
> name="sample.calculator">
>
> <service name="CalculatorService">
> <interface.wsdl interface="
> http://sample/calculator#wsdl.interface(Calculator)"/>
> <binding.ws/>
> <reference>CalculatorComponent</reference>
> </service>
>
> <component name="CalculatorComponent">
> <implementation.php module="Calculator" scope="composite"/>
> <reference name="add_service">AddComponent</reference>
> <reference name="sub_service">SubtractComponent</reference>
> <reference name="mul_service">MultiplyComponent</reference>
> <reference name="div_service">DivideReference</reference>
> </component>
>
> <component name="AddComponent">
> <implementation.php module="Add" scope="composite"/>
> </component>
>
> <component name="SubtractComponent">
> <implementation.php module="Subtract" class="Subtract"
> scope="composite"/>
> </component>
>
> <component name="MultiplyComponent">
> <implementation.php module="Multiply" scope="composite"/>
> </component>
>
> <reference name="DivideReference">
> <interface.wsdl interface="
> http://sample/calculator#wsdl.interface(Divide)"/>
> <binding.ws endpoint="
> http://sample/calculator#wsdl.endpoint(DivideService/DividePort)"/>
> </reference>
> </composite>
>
> This will be attractive if we want to have an augmented model where
> information is taken from both annotations and composite files.
> However my
> main point is that the further down the route of specifying composite
> files
> we go the less value there is in the PHP SCA annotations.
>
> Having said this the easiest thing to do to get us started is work
with
> the C++ SCA implementation as it is and rely on the SCDL file
> approach and
> ignore any composite information in the PHP SCA annotations. This will
> get
> us quite a long way and give us a more complete running sample against
> which
> we can decide if/how to provide full annotation based support.
>
> Simon
>
Thanks Jean-Sebastien
This all sounds pretty good. Here's a few ideas:
(1) Start with an approach similar to the current Ruby and Python
support:
An SCDL file points to the script:
<composite xmlns="http://www.osoa.org/xmlns/sca/1.0";
name="sample.calculator">
<component name="CalculatorComponent">
<implementation.php module="Calculator"/>
</component>
</composite>
The script gets loaded into a PHPImplementation model object. The PHP
extension introspects the script and creates ServiceTypes and
ReferencesTypes from what it sees in it (annotations etc.)
I agree this is the right thing to do to start with. We can leverage
what is
there already and I'll take a look at the trail you and Andy have blazed
with Ruby and Python.
(2) Augment that with the automatic creation of the CompositeService,
CompositeReference and Binding model objects connected to the PHP
component, again from the info in the script and without SCDL. I think
that this could be done in the initializeComponent() method of the
PHPImplementation class for example.
Ok, I think that this is where Pete is talking about doing some API
work. It
sounds though like you might have done this already. Can you point me
in the
right direction? Is this the initializeComponent() for Ruby and Python
(I'll
go look :-)
Yes, RubyImplementation::RubyImplementation() triggers the loading of
the Ruby script and its introspection, which creates ServiceTypes and
ReferenceTypes on the ComponentType representing the script.
RubyImplementation::initializeComponent() is invoked for a Component, is
responsible for creating Services and References for that Component...
and could create additional CompositeServices and CompositeReferences in
the containing Composite, wired to the Services and References of the
Component, from the annotations in your script...
I just looked and you already implement
PHPImplementation::initializeComponent to create Services :) so it's a
matter of expanding the code in this method.
We also have to build an extension layer on the PHP side to get the model
information out and the service, reference and binding information in. We
also need to be able to trap any calls coming from the script of
course. All
of the infrastructure is already there in PHP userspace to do this as you
might expect but we need a mediator to convert this in and out of C/C++.
Yes, you just need to implement a C++ ServiceWrapper to dispatch calls
to your PHP script, and hook your PHP proxy (used for references) with
an implementation of a C++ ServiceProxy.
(3) Add support for discovering PHP scripts under your SCA System root
directory, removing the requirement to write the SCDL shown in (1).
I think that (1) and (2) can be achieved without any change in the model
SPIs. For (3) we'll need to add a hook to the ModelLoader to allow an
extension to participate in the discovery of artifacts.
The script discovery is really an ease of use thing. I think of the
script
replacing (some of) the SCDL files. Having to write them just to load the
script is a bit of a pain but a perfectly workable way to start off. I'm
also interested in what we can do with the SCDL files further down the
line.
We don't support SCDL files at all which is great from the usability
point
of view but It may be useful to have SCDL files augment our annotations.
Don't really have a good use case in my mind but I need to get my head
around how we apply policy, for example. This augmentation piece it
not a
high priority but an interesting possibility that C++ SCA gives us.
This being said, I agree with you that the easiest is probably to start
with everything defined in SCDL and get an end to end scenario working
this way first.
Ok, i'll start pushing that direction.
Cool. Yes, I agree this is an ease of use case. It should be easy to add
the hook to allow your extension to participate in the discovery /
loading phase, when you get to that point.
We'll need to figure out what information to pass to your discover/load
method. So here's a little bit of brainstorming to start with... Which
approach would you prefer:
- a hook that gives you a few pointers like the root of the SCA system,
the search path for implementation artifacts, and then you scan this
yourself?
- you register file types, and the ModelLoader looks for them and
invokes you to process each one?
Pete, did you have anything in mind for this?
Since you brought up generation of SCDL from an annotated script... I
think we may have to support this at some point to allow a user to reuse
an existing annotated PHP component and reconfigure/rewire it, but this
can come later I guess.
Interesting. Had not thought of doing this (Pete brought this up :-) It
would be a nice to have over and above the augmentation scenario I guess.
Based on the "script as a component" idea I'm also quite interested in
the
ability of scripts to be distributed to any old node for execution.
Often a
benefit in high load scenarios particularly where you want the
processing to
follow the data rather than the other way round. Here there is likely
to be
some overhead in ensuring that the script retains its role in the
context of
the SCA application and having the SCDL as the configuration mechanism
could
well be handy. A bit of a complicated scenario and not well thought
through
but there you go.
I'm not sure I understand what you mean "the ability of scripts to be
distributed to any old node for execution", but it sounds interesting.
What about starting another email thread to cover this part?
Thoughts?
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
