[phpsoa] Re: New eBay Soap binding in HEAD
Hi Simon, yes I did. I had been assured that this would be ok because the 'development in a branch' approach is really only necessary for native extension code (because pecl4win always pulls this from HEAD). Let me know if you think the binding should go elsewhere. On 11 May, 14:48, [EMAIL PROTECTED] wrote: Nice Graham. Don't have any feedback yet but a quick question. Did you mean to check it into HEAD rather than the branch? Simon --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups phpsoa group. To post to this group, send email to phpsoa@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.co.uk/group/phpsoa?hl=en -~--~~~~--~~--~--~---
[phpsoa] Re: 4 phpt test failures
Hi Simon, I've seen this kind of thing happen due to firewall problems. When you run the tests from the commandline the firewall might block php.exe, but when you run samples in the browser it lets apache.exe through. Might be a red herring. On 11 May, 13:06, [EMAIL PROTECTED] wrote: php004.phpt seems to be failing trying to resolve xs:import namespace = http://schemas.xmlsoap.org/wsdl/; / Which is part of soap/soap/2003-02-11.xsd However all the examples work OK so I can only guess this is being resolved successfully in other scenarios. Is anyone else who has CURLEW checked out also seeing php004.phpt failing. I.e. I'm trying to work out if its a fault in the code or a fault with the environment in which I'm running phpt tests. Simon --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups phpsoa group. To post to this group, send email to phpsoa@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.co.uk/group/phpsoa?hl=en -~--~~~~--~~--~--~---
[phpsoa] Re: 4 phpt test failures
No, I'm using HEAD, but 004 fails for me too, and with the same error. On 11 May, 15:02, Simon Laws [EMAIL PROTECTED] wrote: Graham Thanks for the suggestion. I did try turning my firewall of but still got the same effect. Does php004 pass for you? Simon --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups phpsoa group. To post to this group, send email to phpsoa@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.co.uk/group/phpsoa?hl=en -~--~~~~--~~--~--~---
[phpsoa] New eBay Soap binding in HEAD
I've just checked the ebaysoap binding into HEAD. I've also checked
in a couple of samples into the examples directory. There's a readme
in the examples directory that briefly describes how to get started.
The binding's pretty easy to use, removing the need for the coder to
work with soap headers and url query string parameters. The following
is a short example showing how to call the GetSearchResults operation:
// Get a proxy to the eBay soap API
$ebay = SCA::getService('eBaySvc.wsdl', 'ebaysoap', array('config' =
'./config/ebay.ini'));
// Create the query input parameters
$request = $ebay-createDataObject('urn:ebay:apis:eBLBaseComponents',
'GetSearchResultsRequestType');
$request-Version = 495;
$request-Query = 'ipod';
$request-createDataObject('Pagination');
$request-Pagination-EntriesPerPage = 10;
// Make the call
$results = $ebay-GetSearchResults($request);
// Iterate through the results
foreach ($results-SearchResultItemArray as $search_result_items) {
foreach ($search_result_items as $search_result_item) {
foreach ($search_result_item-Item as $name = $value)
echo b{$name}/b $valuebr/;
}
}
I've excluded the code from the packaging, so it shouldn't go into
1.2.1. Any feedback, good or bad, would be appreciated.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
phpsoa group.
To post to this group, send email to phpsoa@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.co.uk/group/phpsoa?hl=en
-~--~~~~--~~--~--~---
[phpsoa] Re: nillable
Hi Mike,
Thanks for clarifying the use of pipe with the phpDocumentor
developer.
Yes, the # notation was simply an alternative way to identify a
complex type in a schema. It's largely orthogonal to nillable but I
mentioned it for a few reasons:
1. To raise the idea of us making both changes together since they
will be in the same area of code.
2. As an example where we could improve preserving the phpDocumentor
generation (at the moment the namespace gets generated into the
description :-( ).
3. To solicit more feedback.
My apologies if I caused some confusion. I hope this helps clarify my
intentions.
Graham.
On 15 May, 18:14, Caplan, Michael [EMAIL PROTECTED]
wrote:
Hi Matthew,
I guess I am a little confused about the # notation that Graham outlined
(and wondered if that was just a slightly different way to handle the
problem). Am I correct that Graham is getting at a new notation for
specifying elements from a schema?
IE:
@return elementhttp://Schema_NameSpaceDescription
Becomes:
@returnhttp://Schema_NameSpace#elementDescription
As for implementing pipe support in types, I spent some time in the code
thinking through what this could programmatically look like. But, I'm
not so sure about the structural changes I came up with and possible
side effects. Also, I wouldn't want to interfere with an architecture
choices that may be tied to future initiatives. This said, I could
submit a patch if it would be of assistance, but I wouldn't be able to
get to it for at least a week. The sort of it, yes please implement it.
Let me know if I can help in any way.
Best,
Mike
-Original Message-
From: phpsoa@googlegroups.com [mailto:[EMAIL PROTECTED] On
Behalf Of Matthew Peters
Sent: May 15, 2007 1:47 PM
To: phpsoa
Subject: [phpsoa] Re: nillable
(Joining this thread a week late :-))
Mike, you have done a fantastic job of researching the options. I'm
puzzled why you say _two_ options: isn't there just one surviving
idea, which is what you and Graham have converged upon, the use of the
pipe symbol for both @param and @return, as in:
* @returnhttp://example.org/contacts#contact|null The full
contact details
I agree that this is a fine idea. Would you like me to go ahead and
implement it? The parsing of the annotations is a bit of a rough area
of the code so it does not seem fair that you should have to implement
it as well, especially as you have made several other contributions in
quick succession recently. But you would however be very welcome to do
so if you wanted :-)
Matthew
On May 14, 2:37 pm, Caplan, Michael [EMAIL PROTECTED]
wrote:
Hi Graham,
FYI, I just got word back from a PHPDocumentor developer re: @param
support for multiple types:
Hello Mike,
That functionality is both in there and supported, though it looks
like
we could improve on how we demonstrate it in our manual. I've
opened
PEAR bug #11032
(http://pear.php.net/bugs/bug.php?id=11032) to get the manual
updated
with better examples showing that param type1|type2 usage, and
will
also add more detail to the return tag's doc.
Thanks for the posting...
Chuck
Now that we know that this is supported behavior, any thoughts on
the
two outlined methods for supporting nillable parameters?
Best,
Mike
-Original Message-
From: phpsoa@googlegroups.com [mailto:[EMAIL PROTECTED] On
Behalf Of Graham Charters
Sent: May 12, 2007 6:16 PM
To: phpsoa
Subject: [phpsoa] Re: nillable
Hi Mike,
One of the goals of the SCA annotations has been to try to
preserve
phpDocumentor generation, so I like your suggestion a lot. I took
a
look at the phpDocumentor documentation and could only see mention
of
the pipe for multiple function returns, but not for parameters. I
gave it a whirl for both and phpDocumentor 1.3.0 doesn't appear to
do
anything special with the pipe and doesn't care if it's included
in
an
@param.
If we include the modification suggested in another thread where
we
would change the way complex types are specified to use the #
character (will improve the quality of the phpDocumentor
generation),
then an example SCA component might look like this:
/**
* Service for managing email contacts
*
* @service
* @binding.soap
* @typeshttp://example.org/contactscontacts.xsd
*
*/
class ContactService {
/**
* Retrieve contact details
*
* @param string|null $shortname The short name of the contact
* @returnhttp://example.org/contacts#contact|null The full
contact details
*/
public function retrieve($shortname) {
}
}
Let me know if I've misunderstood your proposal.
The only reason I can think for the generation of nillable all the
time would be to support as many calling options
[phpsoa] Re: How much data should flow back from a business exception?
I think Mike is right that we shouldn't always flow this information. It is a potential security hole as it could divulge more information than we would like. I had similar concerns about the information we flow back in http responses for things like Atompub and the conclusion was to not give any implementation details away. I think we have two scenarios here, which are potentially conflicting. 1. I want to expose a service to a thirdparty and only want to flow back information relation to the integration of our businesses (business exceptions without any implementation detail). 2. I want to be able to define 'module' boundaries which can be running on the same server or potentially remote. I want the same semantics and details to flow across the interfaces, including exception details when remote using Web services (this is within my organisation). I can think of a couple ways to resolve this: 1. We give the developer more control over what flows (either through a config setting or through the exceptions they throw (perhaps one class of exception (e.g business) does not flow backtrace, and another class (e.g. system) does. It's then up to the developer to define which services are business boundaries and which are module boundaries. 2. We create another binding (there is this concept of binding.sca in the specifications), whos purpose is to be used for scenario 2. This binding would flow the backtrace, and we would remove the backtrace for binding.soap. Graham. On 15 May, 18:08, Matthew Peters [EMAIL PROTECTED] wrote: Mike Caplan (in pecl bug #10994) has raised the question of whether, when a business exception is raised in a component that has been called remotely - through a web service, say - the exception should be serialised and flowed back, then deserialised and rethrown in its entirety on the calling end. At the moment the exception is recreated in loving detail, with the same backtrace, line number, file name, that it had on the remote end. This makes the exception identical regardless of whether the components are local or remote. Mike suggests that that is too much information and it would be better to keep just the text and number. I can see his point. Perhaps it was a step too far to flow back the backtrace. One possibility is to put the behaviour under control of a config setting somewhere. What do other people think? Matthew --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups phpsoa group. To post to this group, send email to phpsoa@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.co.uk/group/phpsoa?hl=en -~--~~~~--~~--~--~---
[phpsoa] Re: How much data should flow back from a business exception?
Hi Simon, thanks for your 2c - it's always worth more than that :-) I've inlined some questions/responses below. On 18 May, 12:29, [EMAIL PROTECTED] wrote: Graham I like both of these suggestions and think they both have a place in the runtime. We should have a separation between Business and System exceptions. We expect the calling component to care about Business exceptions as the problem is likely to be their fault. They should be phrased in business terns and I wouldn't expect that a stack trace is required or even useful. If you tell me the number I entered is out of range I don't care which class trapped the problem. They care about System exceptions too but they can't do anything about it so much less detail is required in response. Some note that it has happened and an indication whether it's terminal or trying again might succeed. Contact details may also be useful. Again a stack trace is not required but the exception mush be logged with full info so the admin can fix it. I agree that some indication that something has happened and whether it's worth retrying is important. Http has a similar concept with status codes for things like Internal Server Error or Not Implemented vs Service Unavailable. I'm not sure how best to enable this without becoming too prescriptive (e.g. requiring all exceptions to inherit from common base SCA exception. We do have an SCA_RuntimeException but I don't think it's heavily relied upon in our current bindings). Bindings give us some flexibility to control levels of detail but I think in the majority of cases the level of detail will be low (in terms of stack traces). Not sure we should look to binding.sca as a control point on this as in the full SCA world binding.sca can work remotely too. It's possible that the default php binding would provide more info but not sure it's worth the effort of making an exceptional case. I was actually meaning for binding.sca to be a remote binding. The remote equivalent to binding.php. In other words, if you want to define a 'module' boundary where the full exception information flows, then you use binding.php for local and binding.sca for remote (probably using soap as it's implementation). If you want to define a business service interface then you use the other bindings (soap, json- rpc, and so on). Does that make sense? My 2c Simon --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups phpsoa group. To post to this group, send email to phpsoa@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.co.uk/group/phpsoa?hl=en -~--~~~~--~~--~--~---
[phpsoa] eBay soap binding documentation on osoa.org
Hi All, I've just put some documentation up on the osoa.org wiki describing how to use the eBay SOAP binding (see http://osoa.org/display/PHP/eBay+SOAP+Binding+Documentation). If you spot any problems or have suggestions for improvements, please post them as comments to this post. This is a convenient staging post for binding documentation. I presume we should link to this from the PHP Manual docs and ultimately pull this into those docs (the DocBook output looks much nicer that the osoa wiki). Does that make sense? Regards, Graham. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups phpsoa group. To post to this group, send email to phpsoa@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.co.uk/group/phpsoa?hl=en -~--~~~~--~~--~--~---
[phpsoa] Re: SDO_DAS_Relational + SCA soap binding?
Hi Simon, thanks for your thoughts. My comment are below. On 23 May, 14:12, [EMAIL PROTECTED] wrote: Graham I was just thinking about this part of your issue... snip I wrote an XML schema to match the schema used by the relational DAS (i.e. using the urn:app_namespace, and all primitives were strings). This got me nearly all the way there, but then I hit the main snag which I hadn't foreseen. The XML which was produced did not follow that of the XML schema. It was basically using the default SDO serialization, where all primitives are attributes (the schema defined them as elements). This meant that on the client side the result came back as empty (did not deserialize properly). How about writing your schema so that it matches the default serialization of SDO? Doh! That would work. I got hung up on trying to match the existing contacts schema so I didn't consider that. I think what is happening is the SDO's type still ties back to the Relational DAS, rather than the XML, during serialization. The equivalent XML type has some additional information which enables it to be serialized according to the XML schema. Because the SDO type is the relational one, this information is not available so the default XML serialization rules are used. This tricky issue you raise here is what the technology specifc schema is going to look like. In your situation what you did is hand generate it. In fact what you did is introduce a transformation based on how you though the output XML should look. There are many ways that XML schema can be constructed to represent, in this case, relational schema. To cater for this variability we would have to introduce some sort of transformation step to ensure that the SDO model can be converted to the required schema and ensure that that it is output in that form. ALternatively we could instigate a default transformation that determines how relational models will be represented in XML. I guess the output you see now is the default rule. I think there are probably three classes of transformation: 1. Default SDO serialization (primitives as attributes, complex types as elements). 2. Serialization following an XML schema whose model is logically equivalent to the SDO model (this is what I was trying to do with the contact example (e.g. primitives as elements)). 3. Transformation where the SDO model (types an hierarchy) are not preserved (e.g. remove properties, add properties, change types). Class 1 we should, and do, get for free, although I've not tried this without a schema (do the APIs support this?). Class 2 is what I think should be enabled in SDO as it makes sense to follow a schema during serialization if there is one. Class 3 is where I think people need to write some code :-) . Regards Simon --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups phpsoa group. To post to this group, send email to phpsoa@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.co.uk/group/phpsoa?hl=en -~--~~~~--~~--~--~---
[phpsoa] Re: Suggest we cache the SDO model somehow
On 5 Jun, 10:36, Caroline Maynard [EMAIL PROTECTED] wrote: Graham Charters wrote: One *real* comment: I think we should be getting into the habit of using magic method-style things which appear on the SDO interface (and also our proxy interfaces) to reduce the risk of clashes with the business interfaces (in this case the properties of an SDO, and in the case of our proxies it would be the service methods). Graham, I quite agree that the SCA proxies should not be cluttered up with service methods, but I'm not quite sure why you mentioned this in this particular thread - are you unhappy with the interface Matthew proposed? I mentioned the proxies as one of the two areas where we need to keep the interface clean (the other was SDO). I mentioned SDO because the cache appears to be on the SDO interface in Matthew's example code (unless I've misunderstood). --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups phpsoa group. To post to this group, send email to phpsoa@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.co.uk/group/phpsoa?hl=en -~--~~~~--~~--~--~---
[phpsoa] Simpledb binding
Hi All,
There have been a few occasions where I've wanted a quick and easy way
to access a single database table as part of an SCA component
implementation. I'm just adding the finishing touches (at least to
the point where it might do something useful) to a binding called
simpledb. This gives you a CRUD (create, retrieve, update and delete)
service interface over a database table. It's a bit Active Record
like, but more simplistic. Here's how it is used...
The code below shows how to do CRUD against a table called 'contact'.
?php
require 'SCA/SCA.php';
$dbservice = SCA::getService('contact', 'simpledb',
array('config' = 'config/
mysql_config.ini'));
$contact = $dbservice-createDataObject('http://example.org',
'contact');
$contact-shortname = 'bertie';
$contact-fullname = 'Bertie Example';
$contact-email = '[EMAIL PROTECTED]';
$id = $dbservice-create($contact);
echo Created: $id;
$contact = $dbservice-retrieve('bertie');
echo Retrieved: . $contact-fullname;
$contact-fullname = 'Bertie B Example';
$dbservice-update($contact-shortname, $contact);
$dbservice-delete($contact-shortname);
?
The ini file can contain the following:
dsn = mysql:host=localhost;dbname=email
namespace = http://example.org;
username =xxx
password = xxx
use_lower_case = 1
All but the dsn are optional. The namespace becomes the namespace of
any SDOs created for the table. The use_lower_case value lets you
configure how the SDO property names will appear (The property names
are derived directly from the live database so don't have to be
specified). If set to false, then what the database uses will be used
for the SDO properties (e.g. DB2 will be uppercase).
An SCA reference example would look something like:
/**
* The database service
*
* @reference
* @binding.simpledb contact
*
* @config mysql_config.ini
*/
public $dbservice;
I'd be interested in any feedback, thoughts on how this might be
extended, and so on. My hope is this could be used to simplify
creating Web services backed by a database (it is a better fit than
the SDO relational DAS). I think we could also add optimistic
concurrency quite easily, but using an identifier tag generated by the
binding, rather than SDO change summaries.
If folks are happy with this, then I'll check it into DUNLIN once I've
got the main capabilities up and running.
Regards, Graham
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
phpsoa group.
To post to this group, send email to phpsoa@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.co.uk/group/phpsoa?hl=en
-~--~~~~--~~--~--~---
[phpsoa] Re: Simpledb binding
On 5 Jun, 13:39, Caroline Maynard [EMAIL PROTECTED] wrote: Graham Charters wrote: There have been a few occasions where I've wanted a quick and easy way to access a single database table as part of an SCA component implementation. I'm just adding the finishing touches (at least to the point where it might do something useful) to a binding called simpledb. This gives you a CRUD (create, retrieve, update and delete) service interface over a database table. It's a bit Active Record like, but more simplistic. Sounds interesting. So, this works with just a single table, with the ORM being a 1-1 correspondence between columns and properties? And does it depend on PDO, or ..? (Or I could just wait for the code :-)). Yes, your summary of the ORM is correct. And, yes, it depends on PDO. It's been written to support MySQL and DB2 (need to test I haven't broken this with my latest changes). It's not particularly well factored at the moment for adding support for other databases :- ( . --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups phpsoa group. To post to this group, send email to phpsoa@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.co.uk/group/phpsoa?hl=en -~--~~~~--~~--~--~---
[phpsoa] Are the DASs experimental
The XML and Relational DAS docs have 'experimental' banners. I'd be inclined to remove this from the XML DAS (I think it's stable), but am not sure about the Relational DAS. Any thoughts? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups phpsoa group. To post to this group, send email to phpsoa@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.co.uk/group/phpsoa?hl=en -~--~~~~--~~--~--~---
[phpsoa] Re: Are the DASs experimental
On 7 Jun, 10:29, Caroline Maynard [EMAIL PROTECTED] wrote: Simon Laws wrote: I agree with you assessment, i.e. that the XMLDAS is stable but that the relational DAS is still not well used enough to decide that it has settled down. What he said. (I should have removed it from the XML DAS at the same time as the core, sorry if I didn't. Note that all the individual function doc files need fixing up too :-)) Sounds like agreement. I'll make these edits when I get a bit of free time... :-) To summarize: - XML DAS (no longer experimental - must also remember to edit the individual function files) - Relational DAS (thinking still evolving so should remain experimental). Regards, Graham --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups phpsoa group. To post to this group, send email to phpsoa@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.co.uk/group/phpsoa?hl=en -~--~~~~--~~--~--~---
[phpsoa] Re: rest resource binding?
On 7 Jun, 16:10, Matthew Peters [EMAIL PROTECTED] wrote: I'm glad you like the idea, and you ask a good question. It has always seemed to me that right at the bottom we have service-oriented components and resource-oriented components, and that the service oriented ones can all be totally different but that at one level the resource-oriented ones are all the same - there should be a CRUD component at the top/bottom from which they all inherit, and rest.resource inherit from that. What useful shared logic it could have I don't know - perhaps it is just an interface i.e. method signatures and constants. I mostly agree with this, and for basic resource-oriented services CRUD (should probably be CRUDE because we typically need an Enumerate (aka list) capability) would suffice. Atompub is a good example here. Also, a basic REST CRUDE could be used to provide simple REST access to databases. However, I think in many REST scenarios, there are more capabilities we need to support. I find the REST presentation by Joe Gregorio (see http://bitworking.org/projects/rest/) very enlightening. The example he shows at the end (slide 50 http://bitworking.org/projects/rest/50.html) has quite an elaborate set of URIs the likes of which we will probably need to be able to support. The resource in this example is Accounts for a review service. It would be good to start with an example like this and see how it would map down to an SCA component with a REST binding. I think chances are we will end up with more methods than CRUDE. Regards, Graham. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups phpsoa group. To post to this group, send email to phpsoa@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.co.uk/group/phpsoa?hl=en -~--~~~~--~~--~--~---
[phpsoa] Re: rest resource binding?
I referred to two approaches because I felt that the two 'interfaces' might not be progressive (i.e. steps down the same road). I suppose in some abstract way I could be wrong in that the path info in the URIs is an 'identity' in both cases (e.g. http:///Collection.php/12 versus http:///Collection.php/part/5/subpart/15). If the first case the identity passed to a retrieve, say, could be 12 and in the second it could be part/5/subpart/15. +1 for doing the simple CRUDE first :-) On 11 Jun, 11:01, [EMAIL PROTECTED] wrote: I agree with Matthew's sentiment. I think we have enough ideas here to have a crack at the simple CRUDE case. I view the second case as being similar to the first case but with more complex URIs. I think it is useful to point out that this extra complexity is required in reall applications (which Joes presentation that Graham references makes clear) but I think it's something we should consider as an extension to the simple case. Regards Simon --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups phpsoa group. To post to this group, send email to phpsoa@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.co.uk/group/phpsoa?hl=en -~--~~~~--~~--~--~---
[phpsoa] Re: Simpledb binding
I've just committed the code to DUNLIN for simpledb, along which some DB2 and MySql 'contact' examples. The TODO list is: - unit tests - documentation - fix problem with id returned on MySql create being the row number rather than the primary key (not worked out how to do this yet). - could do with a refactor to separate out the database differences into separate components. - would be nice to have optimistic concurrency. I've updated MakePackage.php to exclude simpledb from the next release (for reasons which should be clear from the above list :-) ). Design change since original post. Instead of use_lower_case in the ini file, you can state case = xxx , where xxx is one of upper, lower or mixed. Mixed just makes the first letter of each property a capital and the rest lowercase. Graham. On 5 Jun, 16:51, Graham Charters [EMAIL PROTECTED] wrote: On 5 Jun, 13:39, Caroline Maynard [EMAIL PROTECTED] wrote: Graham Charters wrote: There have been a few occasions where I've wanted a quick and easy way to access a single database table as part of an SCA component implementation. I'm just adding the finishing touches (at least to the point where it might do something useful) to a binding called simpledb. This gives you a CRUD (create, retrieve, update and delete) service interface over a database table. It's a bit Active Record like, but more simplistic. Sounds interesting. So, this works with just a single table, with the ORM being a 1-1 correspondence between columns and properties? And does it depend on PDO, or ..? (Or I could just wait for the code :-)). Yes, your summary of the ORM is correct. And, yes, it depends on PDO. It's been written to support MySQL and DB2 (need to test I haven't broken this with my latest changes). It's not particularly well factored at the moment for adding support for other databases :- ( . --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups phpsoa group. To post to this group, send email to phpsoa@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.co.uk/group/phpsoa?hl=en -~--~~~~--~~--~--~---
[phpsoa] Re: DUNLIN RC1 testing
Hi Simon,
Yes, I see the same problem. When run with run-tests I get the
following error (I've not had chance to investigate further):
ACTUAL OUTPUT
Warning: SDO_DAS_XML::create(): php_network_getaddresses: getaddrinfo
failed: No such host is known. in C:\php\PEAR\SCA\Bindings\soap
\ServiceDescriptionGenerator.php on line 65
Warning: SDO_DAS_XML::create(http://schemas.xmlsoap.org/wsdl/): failed
to open stream: No such file or directory in C:\php\PEAR\SCA\Bindings
\soap\ServiceDescriptionGenerator.php on line 65
Warning: SDO_DAS_XML::create(): I/O warning : failed to load external
entity http://schemas.xmlsoap.org/wsdl/; in C:\php\PEAR\SCA\Bindings
\soap\ServiceDescriptionGenerator.php on line 65
Fatal error: Uncaught exception 'SDO_DAS_XML_ParserException' with
message 'SDO_DAS_XML::create - Unable to parse the supplied xsd file
1 parse error(s) occurred when parsing the file 'C:\php\PEAR\SCA
\Bindings\soap/soap/2003-02-11.xsd':
1. xmlSAXUserParseFile returned an error -1
' in C:\php\PEAR\SCA\Bindings\soap\ServiceDescriptionGenerator.php:65
Stack trace:
#0 C:\php\PEAR\SCA\Bindings\soap\ServiceDescriptionGenerator.php(65):
SDO_DAS_XML::create(Array)
#1 C:\php5.2\pecl\sdo\tests\SCA\phpt\004.php(7):
SCA_Bindings_soap_ServiceDescriptionGenerator::generateDocumentLiteralWrappedWsdl(Object(SCA_ServiceDescription))
#2 {main}
thrown in C:\php\PEAR\SCA\Bindings\soap
\ServiceDescriptionGenerator.php on line 65
On 18 Jun, 16:59, [EMAIL PROTECTED] wrote:
php04.php works fine if I run it from the command line fbut fails if I
run the phpt test case using run-tests?
Anyone else seeing this behaviour?
Simon
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
phpsoa group.
To post to this group, send email to phpsoa@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.co.uk/group/phpsoa?hl=en
-~--~~~~--~~--~--~---
[phpsoa] Re: DUNLIN RC1 testing
I've just done 'pear run-tests' instead of 'php run-tests.php ...' and 004 passes, so I think the failure is due to running the phpt tests in an inappropriate way. Graham. On 19 Jun, 15:16, Matthew Peters [EMAIL PROTECTED] wrote: Simon, the index.php did contain a reference to helloworldscajsonrpc/ Helloworld.php which did not exist - it should have been helloworld.php. Thanks for spotting - I have fixed. Matthew On 18 Jun, 16:12, [EMAIL PROTECTED] wrote: Things left to do If any one fancies taking a look 1/ examples/SCA/helloworldscajsonrpc/ there is a issue with the case of Helloworld.php. For some reason I can't spot what I thought was wrong with this one. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups phpsoa group. To post to this group, send email to phpsoa@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.co.uk/group/phpsoa?hl=en -~--~~~~--~~--~--~---
[phpsoa] Re: DUNLIN RC2
Hi Simon, can you post what you're seeing for one of the failing unit
test for comparison?
Graham.
On 22 Jun, 09:08, [EMAIL PROTECTED] wrote:
On 22 Jun, 08:39, [EMAIL PROTECTED] wrote:
On 21 Jun, 22:40, Graham Charters [EMAIL PROTECTED] wrote:
Hi Matthew,
Thanks for fixing the wsdl schema fetching problem and spinning RC2.
It all looks good to me on Windows. Unit tests all pass (phpt and
phpunit). Service generation for wsdl, xmlrpc and jsonrpc all work.
Json-rpc mail example runs. Ebay soap example runs and caching works.
Regards,
Graham.
On 21 Jun, 16:24, Simon Laws [EMAIL PROTECTED] wrote:
On 6/21/07, Matthew Peters [EMAIL PROTECTED] wrote:
I just uploaded a new release candidate for DUNLIN (1.2.2) into the
files section of this google group. I deleted the previous one, so the
one that is there, and says it was uploaded at 8:10, is the one to
try.
wrt to the going out on the web for no schemalocation problem, I
went for the following compromise:
if (strstr(file_name,2003-02-11.xsd)) {
xmldas-xsdHelperPtr-defineFile(file_name, false);
} else {
xmldas-xsdHelperPtr-defineFile(file_name, true);
}
i.e., for our soap and wsdl xsds, don't go out, for others, do.
Ok, Matthew, pragmatic as ever. It looks like the real fix is going to
take a little time. Thanks for respinning the RC.
Simon
On FC6 I see 5 unit test failures and 1 phpt failure. They seem to be
to do with modification of the order of namespace definitions on
generated XML, for example,
5) testGETForm(SCA_RestRpcTest)
Failed asserting that text is equal to text.
--- Expected
+++ Actual
@@ -1,2 +1,2 @@
?xml version=1.0 encoding=UTF-8?
-HelloType xsi:type=HelloType xmlns:tns=http://www.example.org/
Hello xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xmlns=http://www.example.org/Hello;namename/namegreetingHello
Fred/greetingreversedderF olleH/reversed/HelloType
+HelloType xmlns=http://www.example.org/Hello; xsi:type=HelloType
xmlns:tns=http://www.example.org/Hello; xmlns:xsi=http://www.w3.org/
2001/XMLSchema-instancenamename/namegreetingHello Fred/
greetingreversedderF olleH/reversed/HelloType
/usr/local/lib/php/test/SCA_SDO/tests/SCA/phpunit/RestRpc/
RestRpcTest.php:95
/usr/local/lib/php/test/SCA_SDO/tests/TestSuite.php:41
/usr/local/lib/php/test/SCA_SDO/tests/TestSuite.php:58
/usr/local/lib/php/test/SCA_SDO/tests/AllTests.php:28
I'm assuming this is to do with the WSDL validation changes but I
thought the test expect results had caught up with this. They don't
stop the samples running though.
I also have a problem running one of the JSONRPC samples which I think
is a configuration problem. Give me a little time to investigate this.
Simon
So I have all the examples running ok now (was a curl config issue) so
there can't be much wrong with it. Unit tests still fail. I can't just
go fix the expected output for the tests though if you are not seeing
these failures so I would like to know why our platforms are producing
different output. Here's what I'm running.
Fedora Core 6
PHP 5.2.0
libxml 2.6.29
Simon
Simon
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
phpsoa group.
To post to this group, send email to phpsoa@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.co.uk/group/phpsoa?hl=en
-~--~~~~--~~--~--~---
[phpsoa] Re: DUNLIN RC2
So there is :-) . Strange this it's just the order in which the
xsi:type and xmlns:tns are written out. Given that, I would say it's
good to go, but we need to get to the bottom of why the order is
different between Windows and Linux to avoid this in future releases.
Agree? Disagree?
Graham.
On 22 Jun, 09:42, [EMAIL PROTECTED] wrote:
On 22 Jun, 09:14, Graham Charters [EMAIL PROTECTED] wrote:
Hi Simon, can you post what you're seeing for one of the failing unit
test for comparison?
Graham.
On 22 Jun, 09:08, [EMAIL PROTECTED] wrote:
On 22 Jun, 08:39, [EMAIL PROTECTED] wrote:
On 21 Jun, 22:40, Graham Charters [EMAIL PROTECTED] wrote:
Hi Matthew,
Thanks for fixing the wsdl schema fetching problem and spinning RC2.
It all looks good to me on Windows. Unit tests all pass (phpt and
phpunit). Service generation for wsdl, xmlrpc and jsonrpc all work.
Json-rpc mail example runs. Ebay soap example runs and caching works.
Regards,
Graham.
On 21 Jun, 16:24, Simon Laws [EMAIL PROTECTED] wrote:
On 6/21/07, Matthew Peters [EMAIL PROTECTED] wrote:
I just uploaded a new release candidate for DUNLIN (1.2.2) into
the
files section of this google group. I deleted the previous one,
so the
one that is there, and says it was uploaded at 8:10, is the one to
try.
wrt to the going out on the web for no schemalocation problem, I
went for the following compromise:
if (strstr(file_name,2003-02-11.xsd)) {
xmldas-xsdHelperPtr-defineFile(file_name, false);
} else {
xmldas-xsdHelperPtr-defineFile(file_name, true);
}
i.e., for our soap and wsdl xsds, don't go out, for others, do.
Ok, Matthew, pragmatic as ever. It looks like the real fix is
going to
take a little time. Thanks for respinning the RC.
Simon
On FC6 I see 5 unit test failures and 1 phpt failure. They seem to be
to do with modification of the order of namespace definitions on
generated XML, for example,
5) testGETForm(SCA_RestRpcTest)
Failed asserting that text is equal to text.
--- Expected
+++ Actual
@@ -1,2 +1,2 @@
?xml version=1.0 encoding=UTF-8?
-HelloType xsi:type=HelloType xmlns:tns=http://www.example.org/
Hello xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xmlns=http://www.example.org/Hello;namename/namegreetingHello
Fred/greetingreversedderF olleH/reversed/HelloType
+HelloType xmlns=http://www.example.org/Hello; xsi:type=HelloType
xmlns:tns=http://www.example.org/Hello; xmlns:xsi=http://www.w3.org/
2001/XMLSchema-instancenamename/namegreetingHello Fred/
greetingreversedderF olleH/reversed/HelloType
/usr/local/lib/php/test/SCA_SDO/tests/SCA/phpunit/RestRpc/
RestRpcTest.php:95
/usr/local/lib/php/test/SCA_SDO/tests/TestSuite.php:41
/usr/local/lib/php/test/SCA_SDO/tests/TestSuite.php:58
/usr/local/lib/php/test/SCA_SDO/tests/AllTests.php:28
I'm assuming this is to do with the WSDL validation changes but I
thought the test expect results had caught up with this. They don't
stop the samples running though.
I also have a problem running one of the JSONRPC samples which I think
is a configuration problem. Give me a little time to investigate this.
Simon
So I have all the examples running ok now (was a curl config issue) so
there can't be much wrong with it. Unit tests still fail. I can't just
go fix the expected output for the tests though if you are not seeing
these failures so I would like to know why our platforms are producing
different output. Here's what I'm running.
Fedora Core 6
PHP 5.2.0
libxml 2.6.29
Simon
Simon
There is one in my original post
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
phpsoa group.
To post to this group, send email to phpsoa@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.co.uk/group/phpsoa?hl=en
-~--~~~~--~~--~--~---
[phpsoa] Re: Release Announcements
The other place would be developerWorks' phpblog, which is syndicated onto planet-php. On 2 Jul, 15:31, [EMAIL PROTECTED] wrote: I've just been doing a Tuscany blog post about the 1.2.2. release. I notice that the release announce didn't go out on the PECL dev list. There appears to be a problem with the process. Wez is looking into it see [1]. Where else can we make the release annouce so that people see it as they aren't getting the info through PECL dev at the moment? Regards Simon [1]http://www.nabble.com/PECL-release-announcements-tf3996552.html --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups phpsoa group. To post to this group, send email to phpsoa@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.co.uk/group/phpsoa?hl=en -~--~~~~--~~--~--~---
[phpsoa] Re: Time for DUNLIN to peck its way out?
Hi Caroline, Sorry for my silence (other project activities have taken over my life at the moment). I would like to see this. As someone who commits less that others and whose brain seems to flush information all to readily, having the documented processes to refer to would be very helpful. Regards, Graham. On 10 Jul, 14:23, cem [EMAIL PROTECTED] wrote: On Jun 14, 4:58 pm, Caroline Maynard [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: Caroline, would you be prepared to commit what you think the various important things to get right are to a page up on the web site a osoa.org? If you don't have time to do this I could extract thoughts from the email archive and document but would be good to get a brain dump. What we're talking about here is not really release process but development process. I'm certainly not intending to stand up for big cumbersome processes. To my mind, prompt management of Tuscany defects according to their rules is a basic courtesy to the Tuscany developers who are kind enough to to help us, that's all. OTOH, this test-driven development thing was my personal response to the confused state that I alone had let the bug tracker get into, which took me a few days to disentangle. I would really like the team to stick with it even now that Matthew is working on SDO as well as SCA, because I do believe that a smaller amount of work earlier will save us more time later, and reduce the number of unwanted side-effects that we see. Documenting how the project is run is a big undertaking. I think it would be a Good Thing, and to be authoritative, one that all the projects leads would need to take part in. It just so happens that I have on my desk right now a copy of Karl Fogel(my hero)'s book Producing Open Source Software, and he points to the Hacker's Guide to Subversion (http://svn.collab.net/repos/svn/trunk/www/hacking.html) as a good example of project guidelines (well he would say that, wouldn't he?). Would you like me to create a wiki page with the subheadings defined in that document? If everyone likes that idea, then I promise to contribute some stuff under some of the subheadings. (For more, see http://producingoss.com/en/written-rules.html-I love that man). I had a positive response from Simon on this, but between us we only represent half of the current committers :-( I think I would be wasting my time starting a project charter unless there is more buy-in - I would just be insert vulgar expression here/. Not sure how to interpret silence, but indifference will kill it as effectively as hostility. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups phpsoa group. To post to this group, send email to phpsoa@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.co.uk/group/phpsoa?hl=en -~--~~~~--~~--~--~---
[phpsoa] Re: Experiences with the ATOMPUB binding #5
I meant to ask. Of the options to improve the API, which would people
prefer, or are there any other suggestions?
My current preference is for the building up of the SDO Atom model
programmatically because this will not require the developer to
specify they want to use something other than SDO. I think the PHP
class approach might need a new annotation to say they want classes
(POPO - Plain Old PHP Objects) rather than SDO.
On 30 Aug, 09:29, Graham Charters [EMAIL PROTECTED] wrote:
The many-valued nature of a lot of the properties is unfortunately due
to the inability of XML schema to accurately describe the Atom
Syndication Format. It's a while since I wrote the schema, but I seem
to recall it was to do with the use of choice maxOccurs=unbounded /. The
Atom XML is defined in terms of Relax NG which does a far
better job. On the plus side, the SDO model could do quite a good job
of representing Atom, so one thought I had was to programmatically
build up an SDO Atom model in the binding. Applications could work
with this cleaner version and then in the binding we would use the XML
schema-based version to handle the serialization/deserialization.
Another thought was to define PHP classes to represent the Atom format
and again use the XML schema-based SDO to do the serialization/
deserialization.
I quite like the heredoc approach as an alternative, which is why I
write the sample code to do that :-D
For the XML serialization using the default namespace, would we want
this to be determined from the XML schema? So for example, our
Atom1.0.xsd has the default namespace being that of Atom, so the
instance documents could do the same.
Graham.
On 23 Aug, 20:45, Caroline Maynard [EMAIL PROTECTED] wrote:
Matthew Peters wrote:
Thank you. The mistake I was making was putting
$entry_author-name = $author;
when I should have had
$entry_author-name[] = $author;
Isn't it all horrid. When you try to write it from scratch, and if you
do not know what you are doing (that was me) it's baffling.
It is quite horrid, but there is a way you can examine the structures -
if you create an SDO_Model_ReflectionDataObject from the sdo
representing the atom entry, it will show you the details. For example,
the author property is described as:
http://www.w3.org/2005/Atom#personConstruct$author[] {
commonj.sdo#String $name[];
commonj.sdo#String $uri[];
http://www.w3.org/2005/Atom#emailType$email[];
http://www.w3.org/2005/Atom#extensionType$extension[] {
}
}
which was how I knew that $author-name must be many-valued.
The code I
had (i.e. without the []) executes, but nothing comes out in the
generated xml, or var_dump, so where the author value goes in that
case I don't know.
Hmm, neither do I. Sounds like an sdo bug.
And as far as I know there is not an example of it in the examples.
The only places I could see where content was being built up, the code
was using heredocs instead. It looks like our examples need a
considerable overhaul (I am remembering your point 1. above also.)
Agreed, I only found examples that sent pre-canned xml from heredocs,
which seems to miss one of the benefits of using SCA.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
phpsoa group.
To post to this group, send email to phpsoa@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.co.uk/group/phpsoa?hl=en
-~--~~~~--~~--~--~---
[phpsoa] Re: Finer-grained control over service methods (Pecl Request #11944)
Comments inlined below...
On 31 Aug, 11:35, [EMAIL PROTECTED] wrote:
Hi Graham
Some more comments in line...
On 31 Aug, 11:26, Graham Charters [EMAIL PROTECTED] wrote:
Hi Simon, thanks for the rapid comments. Here's my thoughts on the
two issues you identified:
1/ What should SCA do if it finds a method without annotations, i.e.
no type information
This probably depends on the type of service. Service types which
don't have a service description (e.g. local, REST and Atom), don't
require this information to be specified. Service types which do have
service descriptions (soap, json-rpc, xml-rpc), do (to varying
degrees).
I think if the binding type requires documentation then we should warn
and not generate (rather than generating something which is of no
use). If the binding type doesn't require documentation then it's
included.
2/ How can methods be omitted from the service interface, i.e. we just
don't want to expose the method
I don't think the absence of comments should be used as a control
mechanism for the reason you and Matt have already highlighted (might
want to document something but still not have it on the service
interface).
I quite like the idea of using interfaces to add this level of
control. It would also be consistent with SCA (SCA Java does this and
also supports the same class implementation approach we use (i.e.
where there is no interface)). How about something like:
/**
* Scaffold implementation for a remote StockQuote Web service.
*
* @service StockQuoteInterface
* @binding.soap
*
*/
StockQuoteImpl implements StockQuoteInterface, ANOtherInterface {
...
}
So I like @service StokeQuoteInterface
If you are suggesting that we can parse the StockQuoteInterface to
pull out the method names which should be provided as service
interfaces (without the need for further annotation on the interface
itself) then this could work. My approach was a contraction of this by
just providing the method names after the interface name in the
annotation but your approach is more forward thinking.
We should be able to update this in SCA_AnnotationReader.php. I
believe all the information is available through Reflection. You can
call getInterfaces() on the ReflectionClass, which returns an array of
ReflectionClass objects, one for each interface. I don't think we
would require further annotations in the interface, but we will need
to decided whether to use annotations/documentation in an interface if
it is provided.
Presumably the default would be to provide all methods if no interface
is described.
Yes, so this would be backwards compatible.
This would be taken to mean that only those methods defined on
StockQuoteInterface are part of the soap service. Those in
ANOtherInterface or just in StockQuoteImpl would be excluded. I'd
prefer to pursue this approach rather than creating a new annotations
which may go away in the near future.
Does this make sense and seem sensible?
On 31 Aug, 09:30, [EMAIL PROTECTED] wrote:
On 31 Aug, 08:42, Graham Charters [EMAIL PROTECTED] wrote:
Pecl Request #11944 (http://pecl.php.net/bugs/bug.php?id=11944) is
asking for finer-grained control over the methods which are surfaced
on a service interface. We currently just use class visibility (i.e.
all public methods) to control this.
There's a small amount of discussion in the request, but I thought it
would be good to raise it here to get greater visibility and gather
more options/opinions.
Graham.
Following up on the comments made in the feature request...
It is true that in the Java SCA implementation the @Service
information is associated with interfaces so a class will implementat
one, or more, interfaces and this tells the runtime which methods of
the class should be treated as service methods.
This is not currently how the PHP SCA implementation works. All
annotations are placed on the class itself. This leads to a level of
simplicity in service construction but we pay for this in lack of
flexibility, for example, in excluding some methods from the service
interface. At least given the set of annotations we have at the
moment.
Having said this I'm not convinced that the use of unannotated (is
that a word?) methods as part of the service interface makes a lot of
sense give the way that the implementation works at the moment. If you
look at what is actually generated in the WSDL in the case of the
method function foo($bar) in the feature request it doesn't seem to
be that useful. I.e. it defines null input and output types. I assume
this is because there are no annotations for SCA to use for typing the
interface. Fine for PHP but not so great for a service interface.
So there are two issues here
1/ What should SCA do if it finds a method without annotations, i.e.
no type
[phpsoa] Re: Finer-grained control over service methods (Pecl Request #11944)
It sounds like we may have consensus. To summarise:
1. We should add the ability to specify an optional interface for the
service on the @service annotation (e.g. @service
MyServiceInterface). This would only be used to limit the methods
exposed by the service, so we would not look for any other metadata in
the interface (we could support this later).
2. We should not include methods in service descriptions which have
not been appropriately documented (this is to avoid generating duff
services descriptions, and is not meant to be used as a means of
controlling the service interface).
Hopefully I'll be able to take a look at 1 sometime towards the end of
this week, unless someone else is itching to do it :-D
Graham.
On 31 Aug, 15:03, Matthew Schultz [EMAIL PROTECTED] wrote:
Actually after a second glance, I see all annotations are still set in
the class. It probably wouldn't make any sense to have SCA parse
annotations in the interface.
Matt
On 31 Aug, 06:20, Graham Charters [EMAIL PROTECTED] wrote: Comments
inlined below...
On 31 Aug, 11:35, [EMAIL PROTECTED] wrote:
Hi Graham
Some more comments in line...
On 31 Aug, 11:26, Graham Charters [EMAIL PROTECTED] wrote:
Hi Simon, thanks for the rapid comments. Here's my thoughts on the
two issues you identified:
1/ What should SCA do if it finds a method without annotations, i.e.
no type information
This probably depends on the type of service. Service types which
don't have a service description (e.g. local, REST and Atom), don't
require this information to be specified. Service types which do have
service descriptions (soap, json-rpc, xml-rpc), do (to varying
degrees).
I think if the binding type requires documentation then we should warn
and not generate (rather than generating something which is of no
use). If the binding type doesn't require documentation then it's
included.
2/ How can methods be omitted from the service interface, i.e. we just
don't want to expose the method
I don't think the absence of comments should be used as a control
mechanism for the reason you and Matt have already highlighted (might
want to document something but still not have it on the service
interface).
I quite like the idea of using interfaces to add this level of
control. It would also be consistent with SCA (SCA Java does this and
also supports the same class implementation approach we use (i.e.
where there is no interface)). How about something like:
/**
* Scaffold implementation for a remote StockQuote Web service.
*
* @service StockQuoteInterface
* @binding.soap
*
*/
StockQuoteImpl implements StockQuoteInterface, ANOtherInterface {
...
}
So I like @service StokeQuoteInterface
If you are suggesting that we can parse the StockQuoteInterface to
pull out the method names which should be provided as service
interfaces (without the need for further annotation on the interface
itself) then this could work. My approach was a contraction of this by
just providing the method names after the interface name in the
annotation but your approach is more forward thinking.
We should be able to update this in SCA_AnnotationReader.php. I
believe all the information is available through Reflection. You can
call getInterfaces() on the ReflectionClass, which returns an array of
ReflectionClass objects, one for each interface. I don't think we
would require further annotations in the interface, but we will need
to decided whether to use annotations/documentation in an interface if
it is provided.
Presumably the default would be to provide all methods if no interface
is described.
Yes, so this would be backwards compatible.
This would be taken to mean that only those methods defined on
StockQuoteInterface are part of the soap service. Those in
ANOtherInterface or just in StockQuoteImpl would be excluded. I'd
prefer to pursue this approach rather than creating a new annotations
which may go away in the near future.
Does this make sense and seem sensible?
On 31 Aug, 09:30, [EMAIL PROTECTED] wrote:
On 31 Aug, 08:42, Graham Charters [EMAIL PROTECTED] wrote:
Pecl Request #11944 (http://pecl.php.net/bugs/bug.php?id=11944) is
asking for finer-grained control over the methods which are surfaced
on a service interface. We currently just use class visibility
(i.e.
all public methods) to control this.
There's a small amount of discussion in the request, but I thought
it
would be good to raise it here to get greater visibility and gather
more options/opinions.
Graham.
Following up on the comments made in the feature request...
It is true that in the Java SCA implementation the @Service
information is associated with interfaces so a class
[phpsoa] Re: Finer-grained control over service methods (Pecl Request #11944)
Just a quick status update...
I've done the code to optionally allow an interface to be specified
and tested this independent of a protocol binding and all works fine.
Unfortunately, when called from a remote invocation, the classexists
tests for the service implementation fails. Get_declared_classes()
confirms that it does not have the definition and
get_declared_interfaces() confirms that it knows about the
interfaces. Removing the interfaces makes everything work as before,
so it appears to be a PHP nit.
I'm going to try to create a little test case to reproduce this
outside SCA. If anyone has heard of anything which might be relevant,
please let me know.
Graham.
On 3 Sep, 13:18, Graham Charters [EMAIL PROTECTED] wrote:
It sounds like we may have consensus. To summarise:
1. We should add the ability to specify an optional interface for the
service on the @service annotation (e.g. @service
MyServiceInterface). This would only be used to limit the methods
exposed by the service, so we would not look for any other metadata in
the interface (we could support this later).
2. We should not include methods in service descriptions which have
not been appropriately documented (this is to avoid generating duff
services descriptions, and is not meant to be used as a means of
controlling the service interface).
Hopefully I'll be able to take a look at 1 sometime towards the end of
this week, unless someone else is itching to do it :-D
Graham.
On 31 Aug, 15:03, Matthew Schultz [EMAIL PROTECTED] wrote: Actually after
a second glance, I see all annotations are still set in
the class. It probably wouldn't make any sense to have SCA parse
annotations in the interface.
Matt
On 31 Aug, 06:20, Graham Charters [EMAIL PROTECTED] wrote: Comments
inlined below...
On 31 Aug, 11:35, [EMAIL PROTECTED] wrote:
Hi Graham
Some more comments in line...
On 31 Aug, 11:26, Graham Charters [EMAIL PROTECTED] wrote:
Hi Simon, thanks for the rapid comments. Here's my thoughts on the
two issues you identified:
1/ What should SCA do if it finds a method without annotations, i.e.
no type information
This probably depends on the type of service. Service types which
don't have a service description (e.g. local, REST and Atom), don't
require this information to be specified. Service types which do have
service descriptions (soap, json-rpc, xml-rpc), do (to varying
degrees).
I think if the binding type requires documentation then we should warn
and not generate (rather than generating something which is of no
use). If the binding type doesn't require documentation then it's
included.
2/ How can methods be omitted from the service interface, i.e. we
just
don't want to expose the method
I don't think the absence of comments should be used as a control
mechanism for the reason you and Matt have already highlighted (might
want to document something but still not have it on the service
interface).
I quite like the idea of using interfaces to add this level of
control. It would also be consistent with SCA (SCA Java does this and
also supports the same class implementation approach we use (i.e.
where there is no interface)). How about something like:
/**
* Scaffold implementation for a remote StockQuote Web service.
*
* @service StockQuoteInterface
* @binding.soap
*
*/
StockQuoteImpl implements StockQuoteInterface, ANOtherInterface {
...
}
So I like @service StokeQuoteInterface
If you are suggesting that we can parse the StockQuoteInterface to
pull out the method names which should be provided as service
interfaces (without the need for further annotation on the interface
itself) then this could work. My approach was a contraction of this by
just providing the method names after the interface name in the
annotation but your approach is more forward thinking.
We should be able to update this in SCA_AnnotationReader.php. I
believe all the information is available through Reflection. You can
call getInterfaces() on the ReflectionClass, which returns an array of
ReflectionClass objects, one for each interface. I don't think we
would require further annotations in the interface, but we will need
to decided whether to use annotations/documentation in an interface if
it is provided.
Presumably the default would be to provide all methods if no interface
is described.
Yes, so this would be backwards compatible.
This would be taken to mean that only those methods defined on
StockQuoteInterface are part of the soap service. Those in
ANOtherInterface or just in StockQuoteImpl would be excluded. I'd
prefer to pursue this approach rather than creating a new annotations
which may go away in the near future
[phpsoa] Re: Finer-grained control over service methods (Pecl Request #11944)
I've just created the test case and reproduced the behaviour (I won't
say problem because I think perhaps what we recommend today might be
the real problem). I tried something which I thought I'd already
attempted and it worked. So here's the explanation.
It seems having interfaces changes when the class gets defined. We
currently suggest the following code layout for a service
implementation:
/* includes for anything the service impl requires */
include 'stuff.php';
// this must be the last include
include 'SCA/SCA.php';
class MyService {}
This all works fine. SCA::initComponent(...) runs in the include of
SCA.php and it tests for classexists('MyService'); and finds that it
does exist.
The problem comes when we add an interface, as shown below:
/* includes for anything the service impl requires */
include 'stuff.php';
// this must be the last include
include 'SCA/SCA.php';
interface MyServiceInterface {}
class MyService implements MyServiceInterface {}
In the above example, the test for classexists('MyService') fails.
Get_declared_classes() confirms it doesn't exist and
get_declared_interfaces() shows that the interface does exist. The
simple/obvious fix, which I thought I'd tried last week, but clearly
hadn't is to move the include after the class declaration, as follows:
/* includes for anything the service impl requires */
include 'stuff.php';
interface MyServiceInterface {}
class MyService implements MyServiceInterface {}
// this must be the last include
include 'SCA/SCA.php';
I need to turn my tests into phpunit tests and merge with the latest
in pecl. I'm hoping I'll be able to do that tonight.
Graham.
On 10 Sep, 16:14, Caroline Maynard [EMAIL PROTECTED] wrote:
Graham Charters wrote:
Just a quick status update...
I've done the code to optionally allow an interface to be specified
and tested this independent of a protocol binding and all works fine.
Unfortunately, when called from a remote invocation, the classexists
tests for the service implementation fails. Get_declared_classes()
confirms that it does not have the definition and
get_declared_interfaces() confirms that it knows about the
interfaces. Removing the interfaces makes everything work as before,
so it appears to be a PHP nit.
There are some peculiarities in this area, and people familiar with
inheritance from other languages are likely to have expectations which
are not satisfied by PHP. For example, there are restrictions on how you
can use inherited interfaces in type hints, which result in fatal errors
for code you might reasonably expect to work. It doesn't sound as if
that's the problem here, but it may be something similar.
I'm going to try to create a little test case to reproduce this
outside SCA.
That would help.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
phpsoa group.
To post to this group, send email to phpsoa@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.co.uk/group/phpsoa?hl=en
-~--~~~~--~~--~--~---
[phpsoa] Re: passing parameters by reference
Hi M, Passing by-value is what the SCA specifications (see http://osoa.org/display/Main/Service+Component+Architecture+Specifications) say should be the calling semantics for remote services. SCA in PHP treats all services as remote and assumes local by-reference calls will just be done using the normal features of PHP. Passing by-value is a good practice for remote service calls because it helps with decoupling the two environments by not relying on sharing instance data. I'm afraid I don't fully understand the scenario you're describing. Would it be possible for you to post an example WSDL and a description of what you think needs to be supported? Regards, Graham. On 18 Sep, 16:59, mbertazz [EMAIL PROTECTED] wrote: Hi all, i've a question about passing parameters by reference and not by value. I'm using WS binding to talk with a remote service. I can't change or ask to change that remote service and it use a by reference approach. Is there some way to use SCA impl. in this particular case? I think it's not a useful way to force access to private attribute of returned object... I read this sentence in SCA documentation: How parameters are always passed by value (and not by reference) between components, even when the calls are local. This ensures that the semantics of a call do not change depending on the location of a component. I can agree, but can you explain me deeply WHY passing by reference is not supported so i can be more strong defending it? Thank you in advence M --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups phpsoa group. To post to this group, send email to phpsoa@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.co.uk/group/phpsoa?hl=en -~--~~~~--~~--~--~---
[phpsoa] Re: How to access HTTPS Webservice
Hi Rob,
What you describe is really interesting from a general SCA
perspective. There is an SCA Policy specification which describes
something called Intents. These are labels describing Quality of
Service requirements. Example are things like integrity (typically
equates to signing), confidentiality (typically equates to
encryption) and authentication. How these intents are implemented
is often binding specific, so the runtime needs to be configured with
information that says how the intent is implementation for each
binding. This is done using policies (typically WS-Policy). The
following is one such example for configuring confidentiality for
soap (encrypting the body):
?xml version=1.0 encoding=UTF-8?
policySet name=SecurePolicy provides=confidentiality
appliesTo=sca:binding.soap xmlns=http://www.osoa.org/xmlns/sca/
1.0
xmlns:wsp=http://schemas.xmlsoap.org/ws/2004/09/policy;
xmlns:wssp=http://www.bea.com/wls90/security/policy;
wsp:Policy
wssp:Confidentiality
wssp:KeyWrappingAlgorithm
URI=http://www.w3.org/2001/04/xmlenc#rsa-1_5; /
wssp:Target
wssp:EncryptionAlgorithm
URI=http://www.w3.org/2001/04/xmlenc#tripledes-cbc; /
wssp:MessageParts
Dialect=http://schemas.xmlsoap.org/2002/12/wsse#part;
wsp:Body()
/wssp:MessageParts
/wssp:Target
wssp:KeyInfo /
/wssp:Confidentiality
/wsp:Policy
/policySet
So the service definition which would use this might look like
/**
* @service
* @binding.soap
* @requires confidentiality
*
*/
Is this the sort of thing you were thinking of, or have I completely
lost the plot? :-D
Graham.
On 11 Dec, 10:14, Rob [EMAIL PROTECTED] wrote:
Hi Graham,
On 10 Dec, 10:25, Graham Charters [EMAIL PROTECTED] wrote:
Disclaimer: I've never done this...
Looking at the docs for the Soap Extension it seems you need to
specify two entries in the options on the soap client constructor.
These could be added as annotations that the binding understands:
/**
* @reference
* @binding.soap
* @local_cert location of the certificate
* @passphrase the passphrase
*/
public $the_secure_service;
Extensions I made to support the ebaysoap binding mean that these
values would get passed through to the soap binding, so we could
extend the soap support to pass them through to the SoapClient. We
could do this for all the extra configuration of the soap client. The
down side would be that these annotation names would be determined by
the soap client, and might not be as we would like.
A slightly different approach would be to use an ini file, as is done
by the ebaysoap support (actually, it supports both). We could just
read all the name value pairs out of the ini, validate them and put
them into the SoapClient. Ebaysoap does this and then uses the
annotations as a way to override the values in the ini.
Unfortuantely, I don't have the time at the moment to do this, but if
anyone is interested, the ebaysoap binding code would be a good place
to start.
I have been thinking about this for a long time with respect to
security but the issue seems to be broader than that.
The first option is not really good imo. There are a lot of options
and it also means it is SOAP specific. Using ini files is flexible,
but also not ideal (for the simple fact that you need an ini file).
What about the possibility of being able to set specific containers
within SCA? I started thinking along this line when thinking about how
to apply WS-* or even authentication for REST and thought of some sort
of policy bucket. Either an array or object is passed to a static
method of SCA and set as a static variable. An annotation could
possibly be used indicating that it had policy which causes SCA to
grab and use the data that was set. This allows it to be flexible
where additional buckets/annoatiation flags can be added so that it is
not specific to just the use case I mention here.
i.e.
$policy = array('local_cert'='/usr/...', 'passphrase'='123');
SCA::setPolicy($policy);
/**
* @reference
* @binding.soap
* @policy True // or some other indicator (maybe policy name if
multiple policies are allowed)
*/
The same idea could be used to provide different information for
different bindings. Instead of being so generic could also make the
annotation @security and pass a security object instead. Just ideas I
thought I'd toss out.
Rob
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
phpsoa group.
To post to this group, send email to phpsoa@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.co.uk/group/phpsoa?hl=en
-~--~~~~--~~--~--~---
[phpsoa] Re: How to access HTTPS Webservice
Hi Rob, I like your ideas very much. The only thing I would like to
see is something at the annotation level which could be related to the
broader SCA (i.e. the Intents). I think this would then give us the
flexibility to specify some QoS requirements and then have it
configured via the associative array approach or the SCA policySet
approach.
So, perhaps an annotation might look like:
/**
* @reference
* @binding.soap
* @requires authentication
*
*/
We could then specify a policy array that defines what
authentication means for the soap binding. Maybe something like:
$policy =
array('soap'=array('authentication'=array('local_cert'=...,
'passphrase'=...)));
The actual intents can be named whatever the developer likes, although
the SCA specs do define the meaning of a small set.
I'm not sure where the developer would provide the options, and that
may also affect flexibility - ie. would all uses of soap have to share
the same configuration?
Does something like this make sense?
Regards, Graham.
Rob wrote:
Hi Graham,
I was trying to stay away form the WS-Policy/SecurityPolicy words :).
That is in-line with my thoughts, but think (at least to start off)
that something simpler should be implemented.
The WS-* tends to be a bit complicated for developers and PHP is meant
to be simple. That doesn't mean looking at the SCA Policy
implementation is out of the question, just something that probably
should be held off until at least there is some simple mechanism in
place that should be able to handle many of the common cases. This is
where I was going with the:
$policy = array('local_cert'='/usr/...', 'passphrase'='123');
SCA::setPolicy($policy);
/**
* @service
* @binding.soap
* @options True
*/
If options is true then the service would check and use any options
that were set via the setPolicy (or whatever name given) method. It
might also be good to make them binding specific, so the array would
be something like:
$policy = array('soap'=array('local_cert'=..., 'passphrase'=...));
so that options for multiple bindings can be set and leveraged.
Similar functionality could also be used for the confidentiality
example you had laid out. *HOWEVER*, this would not be as flexbile as
dealing with WS-Policy/SecurityPolicy and be limited to specific
functionality. (i.e. if signing a document, you can specify body,
headers, but not target specific subsets).
An implementation like this should solve at least 80%-90% of the use
cases and still be simple enough for the average developer to use
without having to learn all the WS-* intricacies.
Another example: adding username token - implementation really
dependant upon wether this would be its own annotation or if a single
annotation is used and they are grouped by binding.
i.e structure:
array(bindingname=array(optionname=array(options)));
bindingname - binding that uses the options (maps to the
@binding.bindingname annotation)
optionname - something that SCA understands and uses that to set the
options for
options - name/value pairs that SCA uses within the context of
optionname
exmaple:
$token = array('soap'=array('usernametoken'=array('username'='rob',
'password'='123456')));
SCA::setPolicy($token);
this would mean that for the soap binding, send a username token with
the username/password combination.
re-writing my origional case:
$policy = array('soap'=array('options'=array('local_cert'=...,
'passphrase'=...)));
for the soap binding, set the soap constructor options with the
following name/value pairs..
Now going forward after something like the above is implemented,
depending upon need, then something more robust can be implemented,
although might not really be needed just for the sake of the few who
might actually have use for rich policies.
What do you think about something along those lines? I know there are
details that would need to be hashed out, but this is the basic idea
of how I could see it working without getting overly complex.
Rob
On 11 Dec, 16:16, Graham Charters [EMAIL PROTECTED] wrote:
Hi Rob,
What you describe is really interesting from a general SCA
perspective. There is an SCA Policy specification which describes
something called Intents. These are labels describing Quality of
Service requirements. Example are things like integrity (typically
equates to signing), confidentiality (typically equates to
encryption) and authentication. How these intents are implemented
is often binding specific, so the runtime needs to be configured with
information that says how the intent is implementation for each
binding. This is done using policies (typically WS-Policy). The
following is one such example for configuring confidentiality for
soap (encrypting the body):
?xml version=1.0 encoding=UTF-8?
policySet name=SecurePolicy provides=confidentiality
appliesTo=sca:binding.soap xmlns=http://www.osoa.org/xmlns/sca/
1.0
xmlns:wsp
[phpsoa] Re: WSDL and extends
Hi,
Sorry for not getting back to you sooner. Extends is not something
I'm aware of being supported. The SCA_AnnotationReader uses
get_class_methods to return the methods which the class may expose
(depends on whether they're public or are restricted using an
interface). I haven't tried it yet, but my guess is this doesn't
return methods defined by the parent class. If this is the case, then
this code would need updating to include parent classes when
determining the candidate methods to be exposed.
I hope this helps.
Graham.
On 21 Dec 2007, 15:24, aouriques [EMAIL PROTECTED] wrote:
Hello,
I would like to know how can I use the extends for services.
I have a Customer service that extends the User service.
/**
* @service
* @binding.soap
* @locationhttp://mydomain.com/SOA/Customer.php
*/
class Customer extends User {
...
}
What should I add into the comments or what should I to do when using
an extension?
When I use the Customer alone it works fine, but when I use the
Customer with the extension the WSDL is not generated.
Thank you!
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
phpsoa group.
To post to this group, send email to phpsoa@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.co.uk/group/phpsoa?hl=en
-~--~~~~--~~--~--~---
[phpsoa] Re: WSDL and extends
OK, so I should have tried it before responding
Get_class_methods does include methods from parent classes. I've just
tried the following example:
filename: DerivedClass.php
?php
include 'SCA/SCA.php';
class ParentClass {
public function method1() {}
}
/**
* My service using extension
*
* @service
* @binding.soap
*/
class DerivedClass extends ParentClass {
public function method2() {}
}
?
When I point my browser at http://./DerivedClass.php?wsdl, it
returns the following, which includes both methods.
?xml version=1.0 encoding=UTF-8?
wsdl:definitions xmlns:tns2=http://DerivedClass; xmlns:wsdl=http://
schemas.xmlsoap.org/wsdl/ xmlns:soap=http://schemas.xmlsoap.org/wsdl/
soap/ xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
targetNamespace=http://DerivedClass;
types
xs:schema xmlns:xs=http://www.w3.org/2001/XMLSchema;
targetNamespace=http://DerivedClass;
elementFormDefault=qualified
xs:element name=method2
xs:complexType
xs:sequence
/xs:sequence
/xs:complexType
/xs:element
xs:element name=method2Response
xs:complexType
xs:sequence
/xs:sequence
/xs:complexType
/xs:element
xs:element name=method1
xs:complexType
xs:sequence
/xs:sequence
/xs:complexType
/xs:element
xs:element name=method1Response
xs:complexType
xs:sequence
/xs:sequence
/xs:complexType
/xs:element
/xs:schema
/types
wsdl:message name=method2Request
wsdl:part name=method2Request element=tns2:method2/
/wsdl:message
wsdl:message name=method2Response
wsdl:part name=return element=tns2:method2Response/
/wsdl:message
wsdl:message name=method1Request
wsdl:part name=method1Request element=tns2:method1/
/wsdl:message
wsdl:message name=method1Response
wsdl:part name=return element=tns2:method1Response/
/wsdl:message
wsdl:portType name=DerivedClassPortType
wsdl:operation name=method2
wsdl:input message=tns2:method2Request/
wsdl:output message=tns2:method2Response/
/wsdl:operation
wsdl:operation name=method1
wsdl:input message=tns2:method1Request/
wsdl:output message=tns2:method1Response/
/wsdl:operation
/wsdl:portType
wsdl:binding name=DerivedClassBinding
type=tns2:DerivedClassPortType
soap:binding transport=http://schemas.xmlsoap.org/soap/http;
style=document/
wsdl:operation name=method2
soap:operation soapAction=/
wsdl:input
soap:body use=literal/
/wsdl:input
wsdl:output
soap:body use=literal/
/wsdl:output
/wsdl:operation
wsdl:operation name=method1
soap:operation soapAction=/
wsdl:input
soap:body use=literal/
/wsdl:input
wsdl:output
soap:body use=literal/
/wsdl:output
/wsdl:operation
/wsdl:binding
wsdl:service name=DerivedClassService
wsdl:port name=DerivedClassPort
binding=tns2:DerivedClassBinding
soap:address location=http://localhost/bugs/extends/
DerivedClass.php/
/wsdl:port
/wsdl:service
/wsdl:definitions
!-- this line identifies this file as WSDL generated by SCA for PHP.
Do not remove --
Can you give this example a try and see what happens?
Regards,
Graham.
On 2 Jan, 17:07, Graham Charters [EMAIL PROTECTED] wrote:
Hi,
Sorry for not getting back to you sooner. Extends is not something
I'm aware of being supported. The SCA_AnnotationReader uses
get_class_methods to return the methods which the class may expose
(depends on whether they're public or are restricted using an
interface). I haven't tried it yet, but my guess is this doesn't
return methods defined by the parent class. If this is the case, then
this code would need updating to include parent classes when
determining the candidate methods to be exposed.
I hope this helps.
Graham.
On 21 Dec 2007, 15:24, aouriques [EMAIL PROTECTED] wrote:
Hello,
I would like to know how can I use the extends for services.
I have a Customer service that extends the User service.
/**
* @service
* @binding.soap
* @locationhttp://mydomain.com/SOA/Customer.php
*/
class Customer extends User {
...
}
What should I add into the comments or what should I to do when using
an extension?
When I use the Customer alone it works fine, but when I use the
Customer with the extension the WSDL is not generated.
Thank you!
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
phpsoa group.
To post to this group, send email to phpsoa@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.co.uk/group/phpsoa?hl=en
-~--~~~~--~~--~--~---
[phpsoa] Re: WSDL and extends
Hi,
What you're seeing is a consequence of the php internals design, in
that a derived class is not processed at compile-time. I encountered
this when adding the ability to control service methods through an
interface. You can get round the problem by moving the include for
SCA.php to after the definition of the derived class (I think this
should be the recommended practice, and needs updating in the docs).
The following works for me:
ParentClass.php
?php
class ParentClass {
public function method1() {}
}
?
DerivedClass.php
?php
include 'ParentClass.php';
/**
* My service using extension
*
* @service
* @binding.soap
*/
class DerivedClass extends ParentClass {
public function method2() {}
}
include 'SCA/SCA.php';
?
I hope this helps.
Graham.
On 2 Jan, 17:46, aouriques [EMAIL PROTECTED] wrote:
First of all, thank you Graham.
I have tested your example and it works fine, but I am trying to
create another structure where I have a parent class in a separated
file.
For example:
?php
include_once 'SCA/SCA.php';
/**
* My service using extension
*
* @service
* @binding.soap
*/
class ParentClass {
public function method1() {}
}
?
?php
include_once 'ParentClass.php';
include_once 'SCA/SCA.php';
/**
* My service using extension
*
* @service
* @binding.soap
*/
class DerivedClass extends ParentClass {
public function method2() {}
}
?
Using this files structure it doesn't work.
Thank you.
On 2 Jan, 14:18, Graham Charters [EMAIL PROTECTED] wrote: OK, so I should
have tried it before responding
Get_class_methods does include methods from parent classes. I've just
tried the following example:
filename: DerivedClass.php
?php
include 'SCA/SCA.php';
class ParentClass {
public function method1() {}
}
/**
* My service using extension
*
* @service
* @binding.soap
*/
class DerivedClass extends ParentClass {
public function method2() {}
}
?
When I point my browser athttp://./DerivedClass.php?wsdl, it
returns the following, which includes both methods.
?xml version=1.0 encoding=UTF-8?
wsdl:definitions xmlns:tns2=http://DerivedClass; xmlns:wsdl=http://
schemas.xmlsoap.org/wsdl/ xmlns:soap=http://schemas.xmlsoap.org/wsdl/
soap/ xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
targetNamespace=http://DerivedClass;
types
xs:schema xmlns:xs=http://www.w3.org/2001/XMLSchema;
targetNamespace=http://DerivedClass;
elementFormDefault=qualified
xs:element name=method2
xs:complexType
xs:sequence
/xs:sequence
/xs:complexType
/xs:element
xs:element name=method2Response
xs:complexType
xs:sequence
/xs:sequence
/xs:complexType
/xs:element
xs:element name=method1
xs:complexType
xs:sequence
/xs:sequence
/xs:complexType
/xs:element
xs:element name=method1Response
xs:complexType
xs:sequence
/xs:sequence
/xs:complexType
/xs:element
/xs:schema
/types
wsdl:message name=method2Request
wsdl:part name=method2Request element=tns2:method2/
/wsdl:message
wsdl:message name=method2Response
wsdl:part name=return element=tns2:method2Response/
/wsdl:message
wsdl:message name=method1Request
wsdl:part name=method1Request element=tns2:method1/
/wsdl:message
wsdl:message name=method1Response
wsdl:part name=return element=tns2:method1Response/
/wsdl:message
wsdl:portType name=DerivedClassPortType
wsdl:operation name=method2
wsdl:input message=tns2:method2Request/
wsdl:output message=tns2:method2Response/
/wsdl:operation
wsdl:operation name=method1
wsdl:input message=tns2:method1Request/
wsdl:output message=tns2:method1Response/
/wsdl:operation
/wsdl:portType
wsdl:binding name=DerivedClassBinding
type=tns2:DerivedClassPortType
soap:binding transport=http://schemas.xmlsoap.org/soap/http;
style=document/
wsdl:operation name=method2
soap:operation soapAction=/
wsdl:input
soap:body use=literal/
/wsdl:input
wsdl:output
soap:body use=literal/
/wsdl:output
/wsdl:operation
wsdl:operation name=method1
soap:operation soapAction=/
wsdl:input
soap:body use=literal/
/wsdl:input
wsdl:output
soap:body use=literal/
/wsdl:output
/wsdl:operation
/wsdl:binding
wsdl:service name=DerivedClassService
wsdl:port name=DerivedClassPort
binding=tns2:DerivedClassBinding
soap:address location=http://localhost/bugs/extends/
DerivedClass.php/
/wsdl:port
/wsdl:service
/wsdl:definitions
!-- this line identifies this file as WSDL
[phpsoa] Re: SCA not working on PHP 5.3
I've just checked a couple of fixes into FULMAR. Seems to work fine now. Graham. On 29 Jan, 10:13, Graham Charters [EMAIL PROTECTED] wrote: I've just moved up to PHP 5.3 and encountered a few problems (e.g. a public const in SCA_CommentReader.php called NAMESPACE apparently clashing with the new namespace support). I'll try to look at this in the next day or so, but if anyone wants to beat me too it... ;-) . Graham. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups phpsoa group. To post to this group, send email to phpsoa@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.co.uk/group/phpsoa?hl=en -~--~~~~--~~--~--~---
[phpsoa] Re: caching of xsd
Hi Dali, I'm not sure this is a caching problem. There is some primitive caching support, but it's only turned on for the ebaysoap binding. Could you provide a little test case which reproduces the problem and I'll see if I can track down what's going on? Regards, Graham. On 7 Feb, 23:28, Dalibor Andzakovic [EMAIL PROTECTED] wrote: Is there any caching of xsds for the @types annotation? When i add a type to an xsd file and try to call SCA::createObject() with that type, i get Fatal error: Uncaught SoapFault exception: exception 'SDO_TypeNotFoundException' TIA dali --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups phpsoa group. To post to this group, send email to phpsoa@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.co.uk/group/phpsoa?hl=en -~--~~~~--~~--~--~---
[phpsoa] Re: Methods Documentation in WSDL
Hi Silvano, Sorry for not replying sooner and not replying to your original note. I always had in mind to generate documentation in the WSDL from the methods descriptions, so what you have done is exactly the right idea. Thanks also for the patch. I haven't taken a look at the moment. The SCA_SDO project has a CLA to cover contributions and so far as I'm aware you've not signed, or been asked to sign it. Is this something you'd be willing and able to do? I can give you more information in needed. Regards, Graham. On 30 May, 17:05, Silvano Girardi Jr [EMAIL PROTECTED] wrote: Since I got no comments, I made it only for methods and not optional. I've put the patch in the case. Silvano On Fri, Apr 25, 2008 at 1:06 PM, Silvano Girardi Jr [EMAIL PROTECTED] wrote: On Fri, Apr 25, 2008 at 12:28 PM, Caroline Maynard [EMAIL PROTECTED] wrote: Silvano Girardi Jr wrote: On Fri, Apr 25, 2008 at 5:38 AM, Caroline Maynard [EMAIL PROTECTED] wrote: Silvano Girardi Jr wrote: is there any special reason for the SCA to do not generate the documentation/documentation in the WSDL based on the method's description in the doc block? Probably nobody thought to do it. Seems a good idea to me. Any volunteers? I was checking how it works and it seems something I can handle in my spare time. I will need to be in touch with someone here to discuss how we are going to do this. Might be best in private and once we define the ways to do it we can put here in the list for votes. (Just thoughts really... not sure how you guys handle these things). Anyway, I am a volunteer :) Silvano Great :-) Suggest you raise a Feature/Change Request at http://pecl.php.net/bugs/report.php?package=SCA_SDO. Then when you have a proposed patch we can get the relevant committers to review it. Ok I just did it:http://pecl.php.net/bugs/bug.php?id=13775 Need your thoughts here. 1 - should it include the description of the service too (as I put in the request above), or only for methods? 2 - should it always happen or be optional? If optional, how to handle this? Silvano --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups phpsoa group. To post to this group, send email to phpsoa@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.co.uk/group/phpsoa?hl=en -~--~~~~--~~--~--~---
[phpsoa] Re: inheritance and soap
Hi Flo, Are you using SCA on the client side? Could you post a small sample which demonstrates the problem and I'll take a look? Regards, Graham. On 3 Oct, 20:58, flo [EMAIL PROTECTED] wrote: I just ran into a problem with my soap connection. Server is java6 and client is php5. Everything works fine, but as soon as i work with a hierarchical structure of objects i get the problem that subclasses are lost. Following example shows a simple setup: Classes: class a class b extends a class c extends a class d extends a Via soap i send an array of a. On the client side b, c and d are lost now. Is there a way to keep subclasses? Thanks, flo --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups phpsoa group. To post to this group, send email to phpsoa@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.co.uk/group/phpsoa?hl=en -~--~~~~--~~--~--~---
[phpsoa] Re: Local SCA client access.
Hi Bruno, There is a cost over and above doing local calls for local SCA service invocations. Firstly, SCA will reflect on the service you are going to call, in order to understand its types and what methods are available. Secondly, the invocation will go through a proxy (SCA/ Bindings/local/Proxy.php) to make the call. Proxying allows us to ensure pass-by-value semantics on the call (consistent with remote invocations). The call does not do serialization to/from XML. I don't know of any performance comparisons. Regards, Graham. On 19 Nov, 17:07, Bruno Reis [EMAIL PROTECTED] wrote: Hi there, I was wondering about how a local SCA access happens. I run trough the IBM tutorial where I set up a service and a client, running on the same machine. It worked just fine, but I have not tested performance. How is this operation compared to a normal method access? Does this local access involves XML messaging, or the SCA recognize its on the same server and do this access on another (maybe faster) way? I will begin to build an application and I am thinking about using SCA to organize it in a service oriented way. But I dont plan to use a rich client capable of doing all the job on the client, so I will have a middleware layer that will act as a controller either. Do you think this may be an overhead to use SCA this way, instead of accessing this service layer with normal php code? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups phpsoa group. To post to this group, send email to phpsoa@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.co.uk/group/phpsoa?hl=en -~--~~~~--~~--~--~---
