cxf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sergey Beryozkin" <sbery...@progress.com>
Subject Re: Applying aspects to service invocations
Date Tue, 23 Jun 2009 15:33:20 GMT
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" <jholtzman@berkeley.edu>
To: <users@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 <eoglynn@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 <jholtzman@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
>> >
>>
> 


Mime
View raw message