On Tue, Nov 4, 2008 at 3:19 PM, Simon Laws <[EMAIL PROTECTED]>wrote: > Hi Michael > > Sorry for the delay, was distracted. Some comments in line... > > Hope this helps > > Simon > > On Sat, Nov 1, 2008 at 12:04 PM, Michael Frey <[EMAIL PROTECTED]> wrote: > >> Hi, >> >> Simon Laws wrote: >> >> Not sure what you mean by "bind" here. You can add the requires attribute >>> to the composite, composite, reference, service etc and, >>> >> >> the basic idea of my policy extension is to provide Quality of Service >> for Web Services. Since JDKLoggingPolicy constrains on >> implementation.java and my extension should be independent of the >> underlying language/technology I was wondering if it is possible to >> apply the policy by adding an requires attribute to a service or a >> reference. I'll give you an example: >> >> <composite xmlns="http://www.osoa.org/xmlns/sca/1.0"; >> targetNamespace="http://sample"; >> xmlns:sample="http://sample"; >> xmlns:tuscany="http://tuscany.apache.org/xmlns/sca/1.0"; >> name="Calculator"> >> >> <service name="CalculatorService" >> promote="CalculatorServiceComponent"> >> <interface.java interface="calculator.CalculatorService" /> >> <binding.ws/> >> </service> >> >> <component name="CalculatorServiceComponent"> >> <implementation.java class="calculator.CalculatorServiceImpl"/> >> <reference name="addService" promote=""> >> <interface.java interface="calculator.AddService" /> >> <binding.ws >> uri="http://vs23:8080/sample-add-ws-webapp/AddService"/> >> </reference> >> ... >> </component> >> </composite> >> >> The above calculator.composite represents a calculator based upon web >> services. The basic idea of the QoS-Proxy is to offer several Quality of >> Service classes for a service. So I have a gold class and a silver class in >> the example below. I was thinking it was possible to enable the policy by >> setting the requires attribute on the service element. In fact > > > You should be able to do this. For example, itest/policy-security-basicauth > uses reference and service intents as follows.. > > <component name="HelloWorldClientComponent"> > <implementation.java class="helloworld.HelloWorldClientImpl" /> > <service name="HelloWorldService"> > <interface.java interface="helloworld.HelloWorldService"/> > <binding.sca/> > </service> > <reference name="helloworldWS" requires="authentication"> > <binding.ws uri=" > http://localhost:8085/HelloWorldServiceWSComponent"/> > </reference> > </component> > > <component name="HelloWorldServiceWSComponent"> > <implementation.java class="helloworld.HelloWorldServiceImpl" > requires="tuscany:identity"/> > <service name="HelloWorldService" requires="authentication"> > <interface.java interface="helloworld.HelloWorldService"/> > <binding.ws uri=" > http://localhost:8085/HelloWorldServiceWSComponent"/> > </service> > </component> > > The thing to watch out for is the way that the policies themselves are > defined. In this case the definitions.xml file contains > > <sca:policySet name="BasicAuthenticationPolicySet" > provides="authentication" > appliesTo="sca:binding.ws"> > <tuscany:basicAuthentication> > <tuscany:userName>myname</tuscany:userName> > <tuscany:password>mypassword</tuscany:password> > </tuscany:basicAuthentication> > </sca:policySet> > > Notice that it applies to binding.ws. The end result of this is that a > basic authentication policy object will be assigned to any web service > bindings that belong to services or references that require authentication. > The interceptor for this policy is added to the reference or service wire as > appropriate. > > >> I had to enable it on the implementation so the policy is now depend on >> the implementation instead of the service or to be precise on the >> binding.ws (I didn't see how to constrain on binding.ws since only >> service, implementation, composite and components support the requires >> attribute) >> >> <composite xmlns="http://www.osoa.org/xmlns/sca/1.0"; >> targetNamespace="http://sample"; >> xmlns:sample="http://sample"; >> xmlns:tuscany="http://tuscany.apache.org/xmlns/sca/1.0"; >> name="Calculator"> >> >> <service name="CalculatorServiceGold" >> promote="CalculatorServiceComponent"> >> <interface.java interface="calculator.CalculatorService" /> >> <binding.ws/> >> </service> >> >> <service name="CalculatorServiceSilver" >> promote="CalculatorServiceComponent"> >> <interface.java interface="calculator.CalculatorService" /> >> <binding.ws/> >> </service> >> >> >> <component name="CalculatorServiceComponent"> >> <implementation.java class="calculator.CalculatorServiceImpl" >> requires="tuscany:proxy"/> >> <reference name="addService" promote=""> >> <interface.java interface="calculator.AddService" /> >> <binding.ws >> uri="http://vs23:8080/sample-add-ws-webapp/AddService"/> >> </reference> >> ... >> </component> >> </composite> >> >> It is possible to 'filter' the service in the interceptor of the policy >> but I have to determine the clients address since I'm using some kind of >> service level management framework in the back. The idea is that there are >> several service level agreements about the calculator service (multiple >> silver and gold agreements). So if a client_1 uses the agreement >> gold_1_agreement it has probably a another priority than a client_2 with a >> gold_4_agreement. I hope it's not too confusing. > > > Ok, so does this rely on the clients authenticating in some way? > > >> >> >> tuntime. I can give you more detail on what is going on under the covers >>> if that helps. >>> >> >> That would be great! > > > The gory details of the policy framework ca be found in the SCA policy > specification. We are primarily based on the OSOA version here ( > http://www.osoa.org/download/attachments/35/SCA_Policy_Framework_V100.pdf?version=1). > Let me say how a little about how this works in the Tuscany runtime. > > The inputs are > definitions.xml - defines intents and policy sets > xyz.composite - defines which artifacts require which intents/policy > sets > > The runtime uses and extensions mechanism to implement policy sets > model - the model of the policy set as read from the definitions.xml > file > processor - uses the stax processor to read the xml from > definitions.xml and generate the model. The policy extension is loaded via > the Java META_INF/services mechanisn keyed off of the > name of the policy element as it appears in definiitons.xml > factory - used to create policy providers > provider - used to create policy interceptors (not sure why we have > policy providers, don;t seem to add any value) > interceptor - tuscany has chains of intercepts between the binding and > the implementation on the service side (on the reference side it's between > the implementation and the binding;-) .The interceptors > allow you process the message after it's come off the wire but before it > goes into > the implementation. Policy interceptors get added in > three places. Just before the reference binding, just after the service > binding > or just before the implementation > > The binding or implementation code is free to look into the assembly model > and use the policy configuration iteself of course. > > >> >> Hmmm, tricky. The target URI is calculated inside the binding and >>> probably isn't in the message directly. at the point at which the policy has >>> access to it. Let me put it in the debugger and see what's available. >>> >> >> That would be really nice. To be precise I'm looking for the source URI or >> some kind of IP or hostname of the client who has sent the service request - >> probably you mean by target the recipient for the web service request >> response. > > > This is a bit more tricky. We may not generally have this information > available. Even if we did I'm not sure you would want to rely on IP type > information in order to provide QoS type discrimination. I would imagine you > would want the client to authenticate, using an authentication policy, and > then base the QoS disrimination based on the authenticated client identity. > If you are using the Tuscany binding.ws we could look at turning on basic > authentication or we have a simple token based authentication mechanism > (involves passing a token of your choice in the SOAP header). > > If you did want to get hold of the client IP info the way we would do it is > to instigate a new interceptor to pulling out the remote address from the > http headers in the message context. > > >> >> >> Thanks in advance! >> >> Regards, >> Michael >> >> > Actually, on the last point, what we should do is make the message context available in the tuscany message so that you can go ahead and pull out the transport information if you really need to.
Simon
