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

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
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.


On 15 May, 18:08, Matthew Peters <[EMAIL PROTECTED]>
> 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 

Reply via email to