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