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 <matthew.f.pet...googlemail.com>
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 phpsoagooglegroups.com
To unsubscribe from this group, send email to
phpsoa-unsubscribegooglegroups.com
For more options, visit this group at http://
groups.google.co.uk/group/phpsoa?hl=en
-~----------~----~----~----~------~----~------~--~---

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.

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.

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 phpsoagooglegroups.com
To unsubscribe from this group, send email to
phpsoa-unsubscribegooglegroups.com
For more options, visit this group at http://
groups.google.co.uk/group/phpsoa?hl=en
-~----------~----~----~----~------~----~------~--~---