Hi David, Nice hearing from you again! Please, let me do some brainstorm here...
The purpose of the intents is to establish a vocabulary between services and distribution providers. This vocabulary could be used to express 3 things: 1. Some quality that is implemented by the service itself (service.intents) 2. Some quality that is required from the Exporting Distribution Provider (service.exported.intents and service.exported.intents.extra) 3. Some quality that is required from the Importing Distribution Provider. The idea is that a service provider could signal to the importing side that something is necessary. Then, using this information, an Importing Distribution Provider that support this intent could safely create a proxy that provides the required characteristic. Currently, we don't have any properties to express that. I guess that this is what we are talking about, right? Well, I have also another doubt. Does it make sense to imagine an intent that is "optional"? I mean, something that would be interesting, but that, if the distribution provider does not understand, it can export/import the service anyway? That could, for example, be used by a service provider to signal that he would like that the requests received his services would be logged. However, if the distribution provider can not do that, it can still export that service. By the way, I am a PhD student at Pernambuco's Federal University and my project is related to QoS-based dynamic service selection. So I am very interested in learning more and trying to contribute to that area. Needless to say that this kind of debate is very important to me. Thank you again! Cheers, Fábio On Tue, Oct 19, 2010 at 12:10 PM, David Bosschaert <david.bosscha...@gmail.com> wrote: > Hi Fabio, > > Thanks for explaining your question further. > The client side looking for SERVICE_EXPORTED_INTENTS or > SERVICE_EXPORTED_INTENTS_EXTRA seems like a bug to me. These two > properties can never exist on the client side, as you correctly > observed. > > I think the whole client-side intents story isn't fully covered by > CXF-DOSGi at this moment, but let's think about how it should work. > > Let's say there is a remote service with intents I1 and I2. > A certain client can consume this service as long as the service has > the I1 intent, but it also needs additional handling by the > Distribution Provider which it expresses as I3. (I1 and I3 could be > security-related intents) > > Probably the best way to model this on the client side is to introduce > an additional property. So the client expresses in the service lookup > filter: > service.intents=I1 > service.consumer.intents=I3 > These service.consumer.intents are not part of the Remote Services > spec (yet) but we could propose them for future versions. If we go > with service.consumer.intents it would probably also make sense to > introduce service.consumer.intents.extra just like this is done on the > exporter side. > > 'service.consumer.intents' is just a proposal, other names would be > possible too, oh and while it's not part of the standard yet we should > really prefix is with org.apache.cxf to make that clear... > > Just a thought, > > David > > On 18 October 2010 21:21, Fabio souza <fabio.nogueira.so...@gmail.com> wrote: >> 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 >> > -- Fábio
