On 3/7/07, Pete Robbins <[EMAIL PROTECTED]> wrote:
On 07/03/07, Simon Laws <[EMAIL PROTECTED]> wrote:
>
> On 3/7/07, Pete Robbins <[EMAIL PROTECTED]> wrote:
> >
> > On 22/02/07, Simon Laws <[EMAIL PROTECTED]> wrote:
> > >
> > > On 2/22/07, Simon Laws <[EMAIL PROTECTED]> wrote:
> > > >
> > > >
> > > >
> > > > On 2/21/07, Pete Robbins <[EMAIL PROTECTED]> wrote:
> > > > >
> > > > > Thanks. The apache mailing list seems sensitive to attachments.
> The
> > > > > Jira is the right place for it anyway.
> > > > >
> > > > > Cheers,
> > > > >
> > > > > On 21/02/07, Caroline Maynard <[EMAIL PROTECTED] >
wrote:
> > > > > > I had attached it to my post, and it appeared to get through
OK
> > for
> > > > > me, but
> > > > > > perhaps not for others. So I've now raised
> > > > > > https://issues.apache.org/jira/browse/TUSCANY-1133 and
attached
> it
> > > to
> > > > > that.
> > > > > >
> > > > > > On 21/02/07, Simon Laws <[EMAIL PROTECTED]> wrote:
> > > > > > >
> > > > > > >
> > > > > > > I can't find the JIRA that you attached the patch to. Can
you
> > > point
> > > > > me in
> > > > > > > the right direction?
> > > > > > >
> > > > > >
> > > > > > --
> > > > > > Caroline
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Pete
> > > > >
> > > > >
> > ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > > > For additional commands, e-mail: [EMAIL PROTECTED]
> > > > >
> > > > > Thanks Caroline
> > > >
> > > OK, the patch improves the situation on windows somewhat so it's
> checked
> > > in
> > > now. I need to get it out and re-run on linux.
> > >
> > > Regards
> > >
> > > Simon
> > >
> >
> > I have been working on the PHP Extension on Linux and have got it into
a
> > "working" state but not without some changes in the code from pecl.
Here
> > is
> > what I have done (though this is not yet checked in to svn):
> >
> > a) I have created a separate build for the extesnion with it's own
> > build.sh.
> > It can be packaged and released separately from the rest of Tuscany.
> This
> > is
> > an experiment to see if this model works and whether we should do this
> for
> > other Tuscany Native extensions. I have included PHPCalculator sample
> with
> > the extension rather than in the sca/samples.
> >
> > b) I have simplified the PHPCalcualtor sample. Currently there is no
way
> > for
> > a PHP client to locate and call a Tuscany service as this code in the
> > PHP_SCA code is not yet written. I have replaced the C++ client to a
> > simple
> > Python client. This cleans up the build process significantly!
>
>
> My concern is that this may make life easier for us but still hides a
> problem that I have experienced on linux which means that using a C++
> client
> doesn't work with the C++ SCA automake system. I just haven't had the
time
> to go back and work out why. I'm not suggesting you have the time either
> btw.
I will go back and make this work someday! There should be nothing that a
C++ client will pull in to cause the problem you see. For this simple
sample
though I don't want to have to do all the scagen, compile stuff when I can
use a simple Python or Ruby client.
Next I have
> > changed the sample so that it demonstrates:
>
>
>
> > 1. Add and Subtract are simple services in Calculator.php that can
> be
> > called from the client. They do not reference any other service.
> > 2. Multiply service can be called form the client and then uses
> > a PHP_SCA injected reference to the multiply service (
> > Multiply.php). The resolution and calling of this referenced
> > service does not involve the Tuscany php extension (I think)
>
> 3. Divide service can be called from the client and then uses an
> > injected binding.tuscany that should go via a tuscany
> > proxy/wrapper to invoke the method in Divide.php
>
>
> Not sure without seeing what code you now have. The way it was set up in
> SVN
> is demonstrated in the diagram.
>
>
http://svn.apache.org/repos/asf/incubator/tuscany/cpp/sca/samples/PHPCalculator/phpcalculator.png
> .
> Only the CPP local client at the bottom was tested due, as you note, to
> PHP
> clients not being implemented yet. So
>
> 1. Add.php
> A basic PHP script that implements the component's "add" function and
> uses PHP SCA to find a PHP logging component. PHP SCA is running
embedded
> here so it should go out via the native runtime, and use the model built
> from SCDL, to find the log comoponent.
>
> 2 Subtract.php
> A basic PHP script with a PHP funtion implementing the component's "sub"
> function. Again finds a PHP logging components via the native runtime.
>
> 3 Multiple.php
> A PHP class which provides a class function to implement the
component's
> "mul" function. Again finds a PHP logging component via the native
> runtime
>
> 4 Divide.php
> A PHP SCA service (uses @services annotation) and provides a class
> function to implement the component's "div" function. Uses the native
> runtime to find a C++ Divide component and passes the message on.
>
> Because we don't have a PHP Client and because the C++ calculator
> component
> does add/subtract/multiply operations internally I also use the divide
> component (4) to call out to add/subtract/multiply temporarily. You will
> see
> some commented out lines in there.
>
>
> Currently 1. works with the Python client invoking locateService which
> > returns a PythonProxy that is wired to the PHPServiceWrapper around
> > Calculator.php.
>
>
> Cool
>
> 2 also works but I had to edit the pecl/sdo/sca/SCA.php
> > createInstanceAndFillInReferences method so that it does not always
> return
> > an SCA_TuscanyProxy if called when php is embedded. I changed this to
> test
> > for the binding type being 'tuscany' so that in case 2 a non-Tuscany
> proxy
> > gets returned.
>
>
> Unfortunately you find the SCA_SDO midst reorganization. The mechanism
for
> developing extensions is being generalized to make it plugable but the
> proxy
> side has not been done yet. creatInstanceAndFillInReferences really
needs
> to
> be removed altogether. Having said this in the long term I think the
> sentiment of your change is correct if you are trying to test whether a
> binding.php goes via PHP SCA while binding.tuscany goes via native SCA.
In
> the short term I decided to make everything to go via tuscany. Clearly
I'm
> really interested in testing whether the integration between PHP SCA and
> Native SCA works. I already know that PHP SCA - PHP SCA integration
buts.
> Maybe its a bit heavy handed to turn this off completely at the moment
so,
> as I say, I can see the logic in what you are trying to do here.
The main problem was that the binding.php should not go via Tuscany and it
keels over.
Ok, so what's the error it's giving?
3. Does not work as it gets a sementation violation when the
> > PHPServiceWrapper for the divide_service is called.
> > The PHPCalculator sample in svn currently has separate services for
Add,
> > Subtract, Multiply and Divide that show different ways of coding the
PHP
> > service. The only one of these that seems to work are the ones which
> have
> > a
> > class and function in the php. The Add.php is odd in that the code
gets
> > executed when the script is loaded and not when the service is
called???
> > The
> > Subtract.php has a function with no class and this also failed. In my
> > simplified sample I removed these as components and wrote them as
simple
> > service methods on Calculator.php.
>
>
> By its nature Add.php will get called when it is loaded. Its just a
> script.
> However we already have the parameter information to provide to it with
> the
> correct input and can capture its output. So this should work. Obviously
> it
> doesn't in your case for some reason.
I don't think you do have the parameter information as it appeared the
script was loaded while creating the proxy/wrapper and before the call to
the service.
The call to the service in this case just goes and gets the results as the
script will already have run.
I'm not convinced that the strategy of simplyfying the tests until something
> works
eh? I'm not trying do do this. I'm trying to simplify the tests to see
what
works rather then the big "it doesn't work" which is it's current state!
is a good justification for including PHP in the release. It seems you
> have changed a few things and are stuggling to get it to work. Doesn't
> that
> mean its not ready?
I agree... it's not yet ready ... that's why I'm working on it. Any help
would be appreciated ;-)
Ok, what do you need? Can you create a new SimplifiedPHPCalculator in SVN so
I can see it. Would be a shame to loose the more complex sample.
I will investigate the segv when calling a tuscany binding from the php
> component.
>
> One more thing that seems to fail, and I'm not sure how it is supposed
to
> work, but the calls from the php components to
> SCA::getService("log_service") can not resolve the reference. I'm not
sure
> how this is supposed to work but as the reference log_service is defined
> in
> the scdl I think the getService code in SCA.php would need to call
> something
> in the tuscany php extension to resolve this and I don't think it does.
As
> I
> say, I'm not sure how this style of call is supposed to work in php.
The reference is resolved via the SCA_TuscanyProxy.php. getService also
has
a test in it that forces a tuscany proxy to be created when running
embedded. Again this comes back to my decision to force all calls via
Native
SCA pending the completion of the PHP SCA_SDO reorg and some more thinking
about how best to deal with a model shared between PHP SCA_SDO and Native
SCA. I think we could make a simple change to testing the optional binding
type that you can pass into getService but I don't do this at the moment
(on
purpose:-).
I made that change to test for the tuscany binding type as well. I'm not
sure I like the name binding.tuscany. It doesn't seem quite right. I think
the "tuscany" binding should probaby be the binding for a named reference.
So... after you determine it's not a php (local) binding, or wsdl, or ???
then it must be a named reference and if this reference is unknown then
it's
off to find it in the scdl (i.e. via Tuscany).
Well this is the kind of thinking that we need to do, i.e. this is the bit
about how we share the model between PHP and Native runtimes. It's a matter
of expectations and who takes priority. I.e. we have instigated a binding so
that you can explicitly say when you cede control to the runtime to go and
find a named reference rather than using .php or .wsdl of .smd. Happy to see
the name changed to something more sensible but I think we need to do more
than this.
If you are enabling the PHP SCA bindings in embedded mode then the model is
split between PHP SCA and native SCA and so the picture, from a Native SCA
model pov, becomes fragmented. This is the least of our worries at the
moment but I imagine in the future we would want some way of consistently
managing all components and wires regarless of where the meta data is
specified (SCDL or annotations). The current solution takes us to the point
that we can prove that the integration works technically but it's not a
complete solution.
Cheers,
--
Pete
