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
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.)
(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.
(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.
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.
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.
Thoughts?
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
