Hi David, First of all, thank you very much for your response!
Well, I see what you mean, I understand that. Please, let me try to explain my question. My point is NOT that those intents are merged under the property "service.intents". This is OK. My point is related to the implementation of createProxy() in class PojoConfigurationTypeHandler. This method is called in the service consumer side to create a proxy to the remote service using the corresponding endpoint. In createProxy`s code, there is a calling to applyIntents(). I guess that calling is responsible for applying intents to the CONSUMER side, isn't it? If it is, this means that I can realize an Intent that can be mapped to a "Policy" that adds interceptors to the client side (using the corresponding factory). In my case, I am considering to use this idea to add an intent (and corresponding interceptors) that is able to monitor a request from the client´s perspective, logging data concerning response time, availability, etc. Well, to obtain the intents that are supposed to be applied to the client side, applyIntents uses getRequestedIntents() method, which looks for intents using RemoteConstants.SERVICE_EXPORTED_INTENTS, RemoteConstants.SERVICE_EXPORTED_INTENTS_EXTRA and Constants.EXPORTED_INTENTS_OLD properties. But, and this is my point, there are NO properties named like that in the consumer side, as the intents are stored in service.intents property. So, I suspect that it is not currently possible to apply intents to the consumer side and, if this is the case, why does createProxy calls applyIntents method? Thank you, very much again! Cheers, Fábio On Mon, Oct 18, 2010 at 3:57 AM, David Bosschaert <david.bosscha...@gmail.com> wrote: > Hi Fabio, > > You are right that the service.intents, service.exported.intents and > service.exported.intents.extra are all merged on the distributed > discovery information. > These properties do serve different purposes, however. > > On the service provider side: > * service.intents: indicates any intents that are implemented by the > service's logic itself. Maybe the service encrypts the message before > it leaves the API or something like that. > * service.exported.intents: any intents specified in this property > have to be provided by the OSGi Remote Services implementation and > intents specified in this property are crucial to the semantics of the > service. Transactionality could be an example. If the Remote Services > implementation can not provide these intents it must not export the > service. > * service.exported.intents.extra: these are also intents that need to > be provided by the OSGi Remote Service implementation, but they are > used to configure the distributed service. The internal semantics of > the service don't depend on these intents but the working of the > system does. These intents should really be made configurable from the > outside (e.g. through config admin). An example could be a secure > protocol setup. Again, if the OSGi Remote Service implementation > cannot provide these intents the service must not be exported. For > more information see [1]. > Typically you will find that the intents that a OSGi Remote Service > implementation provide are configurable. In the case of CXF-DOSGi this > is currently done through the intent-map.xml... > > On the service consumer side, the consumer wants to see all the > intents that are provided by the remote service. At that point it > doesn't matter where they came from that's why they are merged into a > single service.intents property from the client view. > > BTW all the information present in a distributed discovery system > (actuallt in the EndpointDescription [2]) represents the service > consumer view so it therefore doesn't contain any 'exported' > properties. However you should see some *.imported properties there... > > Hope this helps, > > David > > [1] Table 13.1 in the OSGI 4.2 Enterprise Specification > http://www.osgi.org/Download/Release4V42 > [2] > http://www.osgi.org/javadoc/r4v42/org/osgi/service/remoteserviceadmin/EndpointDescription.html > > On 15 October 2010 17:07, Fabio souza <fabio.nogueira.so...@gmail.com> wrote: >> Hi, >> >> Looking at DOSGi's intents implementation I found something that seems >> a little bit strange to me... To apply an intent during proxy >> creation, the method createProxy in class PojoConfigurationTypeHandler >> calls method applyIntents, right? Ok, but, this method calls >> getRequestedIntents to recover the intents that should be applied. >> However, this last method looks for intents using something like: >> >> Collection<String> intents = Arrays.asList( >> OsgiUtils.parseIntents(OsgiUtils.getProperty(sd, >> RemoteConstants.SERVICE_EXPORTED_INTENTS))); >> Collection<String> extraIntents = Arrays.asList( >> OsgiUtils.parseIntents(OsgiUtils.getProperty(sd, >> RemoteConstants.SERVICE_EXPORTED_INTENTS_EXTRA))); >> Collection<String> oldIntents = Arrays.asList( >> OsgiUtils.parseIntents(OsgiUtils.getProperty(sd, >> Constants.EXPORTED_INTENTS_OLD))); >> >> Set<String> allIntents = new HashSet<String>(intents.size() + >> extraIntents.size() + oldIntents.size()); >> allIntents.addAll(intents); >> allIntents.addAll(extraIntents); >> allIntents.addAll(oldIntents); >> >> However, in CXF-DOSGi, when SERVICE_EXPORTED_INTENTS and >> SERVICE_EXPORTED_INTENTS_EXTRA are copied to ZooKeeper they are >> combined in a property named service.intents. So, there aren't >> properties named *EXPORTED* on the proxy side and this code doesn't >> find any intents to apply... So, I guess that in that version I can >> use intents that are supposed to include interceptors in the proxy >> side. Am I right? >> >> Thank you, very much! >> >> Cheers, >> >> Fábio >> > -- Fábio
