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
