Picking up on the question of what the developer should see: a little
bit of this is already visible in the SCA Java Annotations spec.

As you probably know, there is a generalised Policy spec for SCA, that
describes how policies should be referred to in the XML definitions.
It is intended to be a layer of abstraction one up from any
implementation e.g. WS_Security. It has the notion of "intents". The
two areas where it is most worked out are are security and
reliability. There are three intents for security: authentication,
confidentiality, and integrity.

The idea of making policies one step up in abstraction is that if the
XML defining the service says you want authentication, and you are
using a web service binding, you will use WS_Security: if you are
using JMS then you will use what is appropriate there, and so on.

The Java Annotations spec takes the three security intents just that
one little bit further and says, for security, you can have the intent
as an annotation: e.g. you put @Authentication in the Java component.

I imagine that since SCA for PHP is already keen on annotations, we
would want the developer to have exactly the same: in the component
they just put @Authentication or @Confidential or @Integrity, and we
do the rest. Of course we realise there has to be some registry of
passwords or certifications behind the scenes but from the developer
point of view that would be hidden - no nuts, no bolts. That's the
only way you can reliably keep the specifics of bindings out of the
business logic.

On Mar 7, 10:42 am, [EMAIL PROTECTED] wrote:
> On 6 Mar, 19:57, "Rob" <[EMAIL PROTECTED]> wrote:
> > On 6 Mar, 14:03, [EMAIL PROTECTED] wrote:
> > > On 6 Mar, 16:40, "jon" <[EMAIL PROTECTED]> wrote:
> > > > Any thoughts on these issues at large? Does anybody have any resources
> > > > they know of that address WS-* PHP implementation? I am interested in
> > > > starting a discussion about these issues, and of course this may be
> > > > the wrong venue, but please contact me if you are interested in
> > > > talking about this, or if any of the PHP SOA team members have
> > > > thoughts as well.
> > Jon,
> > For now, you can use the code I have written for WS-Security and WS-
> > Addressing (find it athttp://www.cdatazone.org/inthe code section).
> > I am still working on the XML Encryption though I do have it working
> > from the soap client right now (not yet released code).
> > The stuff has been tested against many different SOAP implementations
> > such as .NET and a few different Java servers.
> > > It would be really good to bring this policy idea into our PHP
> > > implementation somehow. I.e. simply allow developers to say that they
> > > want a binding to be secure or reliable or transactional.  I'm afraid
> > > we haven't started this to date. As with everything it's a matter of
> > > time.
> > Simon, I dont know how easy this really would be. I too have been
> > thinking about this lately (strictly in respect to SOAP as I'm not
> > sure if you are thinking about more binding types). For example, SCA
> > leverages ext/soap right now. As you may see from the work I have done
> > with some of the WS-* stack on ext/soap, its not a simple plug and
> > play. Also, in regards to the SOAP header, many of these cant simply
> > be done with the ext/soap header support. Take XML DSig (this is the
> > most used WS-Security feature people using my stuff use). The entire
> > SOAP envelope needs to have been constructed in order to generate the
> > signature in many cases.
> > If the axis2 stuff is ever released and proves itself, maybe down the
> > road it could be leveraged (they claim to do everything), but until
> > then you would need to do similar functionality to what I do now.
> > Rob
> Hi Rob
> Agreed, its not easy. Most of the existing infrastructure has not been
> designed to make this kind of thing easy. This is not restricted to
> PHP I have to say. I guess I separate the problem in two in my mind.
> Firstly the ability implement security, tansactionality etc. behaviour
> over a particular protocol. Some platforms are better than others at
> this, eg, in Java SCA they are using Axis2 for WS support and this has
> the Rampart WS security implementation (although it's not used at
> present in SCA as no security/policy work has been done there either!)
> so maybe this will work out in PHP too as you say. I think we do need
> to start getting our story straight though in PHP SCA so need to build
> some experience of what is going to be required. Having your code will
> be a great help so will take a look when time allows. Thanks for the
> pointer.
> Secondly the ability to develop some sensible way to easily describe
> what is required for the developer, i.e. I want a particular reference
> to be signed, encrypted, authenticated, without them having to get too
> deeply into the nuts and bolts of the implementation apart from
> providing credentials etc. Granted doing this in some protocol
> independent way sounds like a holy grail task to me but it at least if
> we can go some way to hiding all the API schenanigans for an
> indiviudual protocol, eg, ws, then this will give us some idea of how
> viable the policy based approach is.
> 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 

Reply via email to