You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by Josh Holtzman <jh...@berkeley.edu> on 2009/06/18 23:02:37 UTC
Applying aspects to service invocations
I'm trying to figure out how best to apply aspects like authentication and
authorization to my distributed OSGi services using CXF. Since I won't know
which services are deployed locally or remotely until the osgi container is
running, I don't think servlet filters are the right approach (the filter
would be bypassed for local service invocations).
I'm pretty sure that each service that is exposed as a remote endpoint via
DOSGI has its own CXF Bus. So I should be able to add interceptors to the
buses generated by the CXFNonSpringServlets. But I think these buses are
bypassed when the service is locally invoked, so the CXF interceptor
approach doesn't work either.
Does anyone have suggestions for applying aspects to (D)OSGI services? I'm
about to read up on the new Find hooks available in the osgi 4.2 spec, since
I might be able to sneak a proxy into service location, but I don't want to
give up on a CXF based solution if there is one.
Thanks,
Josh
Re: Applying aspects to service invocations
Posted by Sergey Beryozkin <sb...@progress.com>.
Hi
Can SpringDM help somehow as well. such that the application context sets up the various interceptors on the default bus ? That
would be a very CXF-specific solution :-)
I like the idea of using custom intents. We may need to think how to ensure that some intents, those not intended for client
bundles, are not published. I can't recall at the moment if a client is supposed to fail if it sees the intents it is not aware of
or can not satisfy.
cheers, Sergey
----- Original Message -----
From: "Josh Holtzman" <jh...@berkeley.edu>
To: <us...@cxf.apache.org>
Sent: Thursday, June 18, 2009 11:16 PM
Subject: Re: Applying aspects to service invocations
> Very helpful, thanks! I didn't realize that DOSGi intercepts service calls
> from the local osgi container, but I suppose it must in order to provide QoS
> concepts.
>
> Thanks,
> Josh
>
> On Thu, Jun 18, 2009 at 3:04 PM, Eoghan Glynn <eo...@gmail.com> wrote:
>
>> Hi Josh,
>>
>> Sounds like you need a custom intent.
>>
>> An intent is simply a string that identifies some QoS that should be
>> enabled
>> on the local proxy or is required by the remote service. The desired
>> intents
>> are specified via a space-separated list provided as a property on the
>> service lookup (check with DavidB for the latest property name, these have
>> been changing recently due to some churn in the specification process).
>>
>> Now dOSGi uses a master intent map, that's retrieved from
>> /OSGI-INF/cxf/intents/intent-map.xml in the DSW bundle.
>>
>> But you can provide your own application-specific intents in the calling
>> bundle (same path as above) which would then be merged with the master map.
>>
>> As you can see from [1], the intent map is simply a string-to-bean map
>> where
>> the key is a string intent name and the value is a CXF Feature, list of
>> WS-Policy assertions or a BindingConfiguration.
>>
>> So your custom map could look something like this:
>>
>> <beans xmlns="http://www.springframework.org/schema/beans"
>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>> xmlns:auth="http://holtzman.org/auth"
>> xsi:schemaLocation="
>> http://www.springframework.org/schema/beans
>> http://www.springframework.org/schema/beans/spring-beans.xsd">
>>
>> <bean id="intentMap" class="org.apache.cxf.dosgi.dsw.qos.IntentMap">
>> <property name="intents">
>> <map>
>> <entry key="authorization" value-ref="joshAuth"/>
>> </map>
>> </property>
>> </bean>
>>
>> <auth:authorization id="joshAuth"/>
>> </beans>
>>
>> Then your authorization feature would simply install the required
>> interceptors, on the individual proxy created for the remote service.
>>
>> You can model your feature implementation on the WSAdedressingFeature[2],
>> which is one of the simplest in CXF.
>>
>> You'll also need need a META-INF/spring.handlers file mapping your
>> namespace
>> to a handler class, e.g.:
>>
>> http\://holtzman.org/auth=org.holtzman.auth.spring.NamespaceHandler
>>
>> Then just base the namespace handler and bean definition parser on the WS-A
>> analogues ([3], [4]).
>>
>> Hope this helps!
>>
>> Cheers,
>> Eoghan
>>
>> [1]
>>
>> http://svn.apache.org/viewvc/cxf/dosgi/trunk/dsw/cxf-dsw/src/main/resources/OSGI-INF/cxf/intents/intent-map.xml?view=co
>> [2]
>>
>> http://svn.apache.org/viewvc/cxf/trunk/rt/ws/addr/src/main/java/org/apache/cxf/ws/addressing/WSAddressingFeature.java?view=co
>> [3]
>>
>> http://svn.apache.org/viewvc/cxf/trunk/rt/ws/addr/src/main/java/org/apache/cxf/ws/addressing/spring/NamespaceHandler.java?view=co
>> [4]
>>
>> http://svn.apache.org/viewvc/cxf/trunk/rt/ws/addr/src/main/java/org/apache/cxf/ws/addressing/spring/AddressingBeanDefinitionParser.java?view=co
>>
>> 2009/6/18 Josh Holtzman <jh...@berkeley.edu>
>>
>> > I'm trying to figure out how best to apply aspects like authentication
>> and
>> > authorization to my distributed OSGi services using CXF. Since I won't
>> > know
>> > which services are deployed locally or remotely until the osgi container
>> is
>> > running, I don't think servlet filters are the right approach (the filter
>> > would be bypassed for local service invocations).
>> >
>> > I'm pretty sure that each service that is exposed as a remote endpoint
>> via
>> > DOSGI has its own CXF Bus. So I should be able to add interceptors to
>> the
>> > buses generated by the CXFNonSpringServlets. But I think these buses are
>> > bypassed when the service is locally invoked, so the CXF interceptor
>> > approach doesn't work either.
>> >
>> > Does anyone have suggestions for applying aspects to (D)OSGI services?
>> I'm
>> > about to read up on the new Find hooks available in the osgi 4.2 spec,
>> > since
>> > I might be able to sneak a proxy into service location, but I don't want
>> to
>> > give up on a CXF based solution if there is one.
>> >
>> > Thanks,
>> > Josh
>> >
>>
>
Re: Applying aspects to service invocations
Posted by Eoghan Glynn <eo...@gmail.com>.
Well dOSGi intercepts the OSGi container around service lookup (so as to
trigger the registration of a proxy) and service registration (as as to
trigger the exposure of a remote endpoint).
Once the proxy is passed back to the client application, then all calls are
mediated directly by the CXF runtime, i.e. the OSGi container is not really
involved at that point.
The idea of intents is enable to the appropriate QoS when the proxy is being
created, usually via CXF interceptors installed on the per-proxy interceptor
chains.
Cheers,
Eoghan
2009/6/18 Josh Holtzman <jh...@berkeley.edu>
> Very helpful, thanks! I didn't realize that DOSGi intercepts service calls
> from the local osgi container, but I suppose it must in order to provide
> QoS
> concepts.
>
> Thanks,
> Josh
>
> On Thu, Jun 18, 2009 at 3:04 PM, Eoghan Glynn <eo...@gmail.com> wrote:
>
> > Hi Josh,
> >
> > Sounds like you need a custom intent.
> >
> > An intent is simply a string that identifies some QoS that should be
> > enabled
> > on the local proxy or is required by the remote service. The desired
> > intents
> > are specified via a space-separated list provided as a property on the
> > service lookup (check with DavidB for the latest property name, these
> have
> > been changing recently due to some churn in the specification process).
> >
> > Now dOSGi uses a master intent map, that's retrieved from
> > /OSGI-INF/cxf/intents/intent-map.xml in the DSW bundle.
> >
> > But you can provide your own application-specific intents in the calling
> > bundle (same path as above) which would then be merged with the master
> map.
> >
> > As you can see from [1], the intent map is simply a string-to-bean map
> > where
> > the key is a string intent name and the value is a CXF Feature, list of
> > WS-Policy assertions or a BindingConfiguration.
> >
> > So your custom map could look something like this:
> >
> > <beans xmlns="http://www.springframework.org/schema/beans"
> > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> > xmlns:auth="http://holtzman.org/auth"
> > xsi:schemaLocation="
> > http://www.springframework.org/schema/beans
> > http://www.springframework.org/schema/beans/spring-beans.xsd">
> >
> > <bean id="intentMap" class="org.apache.cxf.dosgi.dsw.qos.IntentMap">
> > <property name="intents">
> > <map>
> > <entry key="authorization" value-ref="joshAuth"/>
> > </map>
> > </property>
> > </bean>
> >
> > <auth:authorization id="joshAuth"/>
> > </beans>
> >
> > Then your authorization feature would simply install the required
> > interceptors, on the individual proxy created for the remote service.
> >
> > You can model your feature implementation on the WSAdedressingFeature[2],
> > which is one of the simplest in CXF.
> >
> > You'll also need need a META-INF/spring.handlers file mapping your
> > namespace
> > to a handler class, e.g.:
> >
> > http\://holtzman.org/auth=org.holtzman.auth.spring.NamespaceHandler
> >
> > Then just base the namespace handler and bean definition parser on the
> WS-A
> > analogues ([3], [4]).
> >
> > Hope this helps!
> >
> > Cheers,
> > Eoghan
> >
> > [1]
> >
> >
> http://svn.apache.org/viewvc/cxf/dosgi/trunk/dsw/cxf-dsw/src/main/resources/OSGI-INF/cxf/intents/intent-map.xml?view=co
> > [2]
> >
> >
> http://svn.apache.org/viewvc/cxf/trunk/rt/ws/addr/src/main/java/org/apache/cxf/ws/addressing/WSAddressingFeature.java?view=co
> > [3]
> >
> >
> http://svn.apache.org/viewvc/cxf/trunk/rt/ws/addr/src/main/java/org/apache/cxf/ws/addressing/spring/NamespaceHandler.java?view=co
> > [4]
> >
> >
> http://svn.apache.org/viewvc/cxf/trunk/rt/ws/addr/src/main/java/org/apache/cxf/ws/addressing/spring/AddressingBeanDefinitionParser.java?view=co
> >
> > 2009/6/18 Josh Holtzman <jh...@berkeley.edu>
> >
> > > I'm trying to figure out how best to apply aspects like authentication
> > and
> > > authorization to my distributed OSGi services using CXF. Since I won't
> > > know
> > > which services are deployed locally or remotely until the osgi
> container
> > is
> > > running, I don't think servlet filters are the right approach (the
> filter
> > > would be bypassed for local service invocations).
> > >
> > > I'm pretty sure that each service that is exposed as a remote endpoint
> > via
> > > DOSGI has its own CXF Bus. So I should be able to add interceptors to
> > the
> > > buses generated by the CXFNonSpringServlets. But I think these buses
> are
> > > bypassed when the service is locally invoked, so the CXF interceptor
> > > approach doesn't work either.
> > >
> > > Does anyone have suggestions for applying aspects to (D)OSGI services?
> > I'm
> > > about to read up on the new Find hooks available in the osgi 4.2 spec,
> > > since
> > > I might be able to sneak a proxy into service location, but I don't
> want
> > to
> > > give up on a CXF based solution if there is one.
> > >
> > > Thanks,
> > > Josh
> > >
> >
>
Re: Applying aspects to service invocations
Posted by Josh Holtzman <jh...@berkeley.edu>.
Very helpful, thanks! I didn't realize that DOSGi intercepts service calls
from the local osgi container, but I suppose it must in order to provide QoS
concepts.
Thanks,
Josh
On Thu, Jun 18, 2009 at 3:04 PM, Eoghan Glynn <eo...@gmail.com> wrote:
> Hi Josh,
>
> Sounds like you need a custom intent.
>
> An intent is simply a string that identifies some QoS that should be
> enabled
> on the local proxy or is required by the remote service. The desired
> intents
> are specified via a space-separated list provided as a property on the
> service lookup (check with DavidB for the latest property name, these have
> been changing recently due to some churn in the specification process).
>
> Now dOSGi uses a master intent map, that's retrieved from
> /OSGI-INF/cxf/intents/intent-map.xml in the DSW bundle.
>
> But you can provide your own application-specific intents in the calling
> bundle (same path as above) which would then be merged with the master map.
>
> As you can see from [1], the intent map is simply a string-to-bean map
> where
> the key is a string intent name and the value is a CXF Feature, list of
> WS-Policy assertions or a BindingConfiguration.
>
> So your custom map could look something like this:
>
> <beans xmlns="http://www.springframework.org/schema/beans"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xmlns:auth="http://holtzman.org/auth"
> xsi:schemaLocation="
> http://www.springframework.org/schema/beans
> http://www.springframework.org/schema/beans/spring-beans.xsd">
>
> <bean id="intentMap" class="org.apache.cxf.dosgi.dsw.qos.IntentMap">
> <property name="intents">
> <map>
> <entry key="authorization" value-ref="joshAuth"/>
> </map>
> </property>
> </bean>
>
> <auth:authorization id="joshAuth"/>
> </beans>
>
> Then your authorization feature would simply install the required
> interceptors, on the individual proxy created for the remote service.
>
> You can model your feature implementation on the WSAdedressingFeature[2],
> which is one of the simplest in CXF.
>
> You'll also need need a META-INF/spring.handlers file mapping your
> namespace
> to a handler class, e.g.:
>
> http\://holtzman.org/auth=org.holtzman.auth.spring.NamespaceHandler
>
> Then just base the namespace handler and bean definition parser on the WS-A
> analogues ([3], [4]).
>
> Hope this helps!
>
> Cheers,
> Eoghan
>
> [1]
>
> http://svn.apache.org/viewvc/cxf/dosgi/trunk/dsw/cxf-dsw/src/main/resources/OSGI-INF/cxf/intents/intent-map.xml?view=co
> [2]
>
> http://svn.apache.org/viewvc/cxf/trunk/rt/ws/addr/src/main/java/org/apache/cxf/ws/addressing/WSAddressingFeature.java?view=co
> [3]
>
> http://svn.apache.org/viewvc/cxf/trunk/rt/ws/addr/src/main/java/org/apache/cxf/ws/addressing/spring/NamespaceHandler.java?view=co
> [4]
>
> http://svn.apache.org/viewvc/cxf/trunk/rt/ws/addr/src/main/java/org/apache/cxf/ws/addressing/spring/AddressingBeanDefinitionParser.java?view=co
>
> 2009/6/18 Josh Holtzman <jh...@berkeley.edu>
>
> > I'm trying to figure out how best to apply aspects like authentication
> and
> > authorization to my distributed OSGi services using CXF. Since I won't
> > know
> > which services are deployed locally or remotely until the osgi container
> is
> > running, I don't think servlet filters are the right approach (the filter
> > would be bypassed for local service invocations).
> >
> > I'm pretty sure that each service that is exposed as a remote endpoint
> via
> > DOSGI has its own CXF Bus. So I should be able to add interceptors to
> the
> > buses generated by the CXFNonSpringServlets. But I think these buses are
> > bypassed when the service is locally invoked, so the CXF interceptor
> > approach doesn't work either.
> >
> > Does anyone have suggestions for applying aspects to (D)OSGI services?
> I'm
> > about to read up on the new Find hooks available in the osgi 4.2 spec,
> > since
> > I might be able to sneak a proxy into service location, but I don't want
> to
> > give up on a CXF based solution if there is one.
> >
> > Thanks,
> > Josh
> >
>
Re: Applying aspects to service invocations
Posted by Eoghan Glynn <eo...@gmail.com>.
Hi Josh,
Sounds like you need a custom intent.
An intent is simply a string that identifies some QoS that should be enabled
on the local proxy or is required by the remote service. The desired intents
are specified via a space-separated list provided as a property on the
service lookup (check with DavidB for the latest property name, these have
been changing recently due to some churn in the specification process).
Now dOSGi uses a master intent map, that's retrieved from
/OSGI-INF/cxf/intents/intent-map.xml in the DSW bundle.
But you can provide your own application-specific intents in the calling
bundle (same path as above) which would then be merged with the master map.
As you can see from [1], the intent map is simply a string-to-bean map where
the key is a string intent name and the value is a CXF Feature, list of
WS-Policy assertions or a BindingConfiguration.
So your custom map could look something like this:
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:auth="http://holtzman.org/auth"
xsi:schemaLocation="
http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans.xsd">
<bean id="intentMap" class="org.apache.cxf.dosgi.dsw.qos.IntentMap">
<property name="intents">
<map>
<entry key="authorization" value-ref="joshAuth"/>
</map>
</property>
</bean>
<auth:authorization id="joshAuth"/>
</beans>
Then your authorization feature would simply install the required
interceptors, on the individual proxy created for the remote service.
You can model your feature implementation on the WSAdedressingFeature[2],
which is one of the simplest in CXF.
You'll also need need a META-INF/spring.handlers file mapping your namespace
to a handler class, e.g.:
http\://holtzman.org/auth=org.holtzman.auth.spring.NamespaceHandler
Then just base the namespace handler and bean definition parser on the WS-A
analogues ([3], [4]).
Hope this helps!
Cheers,
Eoghan
[1]
http://svn.apache.org/viewvc/cxf/dosgi/trunk/dsw/cxf-dsw/src/main/resources/OSGI-INF/cxf/intents/intent-map.xml?view=co
[2]
http://svn.apache.org/viewvc/cxf/trunk/rt/ws/addr/src/main/java/org/apache/cxf/ws/addressing/WSAddressingFeature.java?view=co
[3]
http://svn.apache.org/viewvc/cxf/trunk/rt/ws/addr/src/main/java/org/apache/cxf/ws/addressing/spring/NamespaceHandler.java?view=co
[4]
http://svn.apache.org/viewvc/cxf/trunk/rt/ws/addr/src/main/java/org/apache/cxf/ws/addressing/spring/AddressingBeanDefinitionParser.java?view=co
2009/6/18 Josh Holtzman <jh...@berkeley.edu>
> I'm trying to figure out how best to apply aspects like authentication and
> authorization to my distributed OSGi services using CXF. Since I won't
> know
> which services are deployed locally or remotely until the osgi container is
> running, I don't think servlet filters are the right approach (the filter
> would be bypassed for local service invocations).
>
> I'm pretty sure that each service that is exposed as a remote endpoint via
> DOSGI has its own CXF Bus. So I should be able to add interceptors to the
> buses generated by the CXFNonSpringServlets. But I think these buses are
> bypassed when the service is locally invoked, so the CXF interceptor
> approach doesn't work either.
>
> Does anyone have suggestions for applying aspects to (D)OSGI services? I'm
> about to read up on the new Find hooks available in the osgi 4.2 spec,
> since
> I might be able to sneak a proxy into service location, but I don't want to
> give up on a CXF based solution if there is one.
>
> Thanks,
> Josh
>