Hi Fabio, Yes, #3 is what we're lacking at the moment.
Optional intents. It's an interesting idea. How would you model those in terms of service properties? I guess there are a few things that you could do already today if you need optional intents. Let's say you have this optional intent called 'logging': * if your distribution provider doesn't support it and you, as a deployer, think that's ok, you could enhance the DP's vocabulary with a 'logging' intent and map it to a noop. * the previous doesn't really work if you have certain services who need optional logging and others who absolutely require it. I guess you could think about a naming scheme to qualify logging as optional by adopting a convention like calling the intent optional:logging instead of just logging. * another option would be to introduce new properties to hold optional intents... Do you have any other concrete use-cases beyond logging? They might help the conversation... Best regards, David On 20 October 2010 21:37, Fabio souza <fabio.nogueira.so...@gmail.com> wrote: > 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 >
