Hi David, First of all, Happy New Year!!!
I'd like to discuss a bit more about client-side intents, can we do that? I was thinking about it, and I felt a bit confused... It seems to me that there are some intents whose use on the SERVER side has some implications on the CLIENT side. Let´s consider cryptography as an example... Well, when we say that a server should receive cyphered requests, it will not be able to process a request which is not cyphered. So, when we create a proxy to this server on the client side, this proxy should include an interceptor which is responsible for cyphering the request before sending it to the server side. Well, I don't see why the client need to be aware of this fact (although it could be). Maybe, the server could indicate to the client (in fact, to the distribution provider on the client side) that an interceptor is needed. In this case, an intent set on SERVER side is affecting the interceptors that should be placed on CLIENT side. When we use an EJB, for example, the proxy (stub) that is used by the client already includes the needed interceptors (which are configured on the server side). On the other side, a client can have some special requirements. For example, consider a client that would like to indicate that its requests should be monitored (so that, for example, the round-trip time could be captured and that failures could be logged). Well, in OSGi model, a client has a direct reference to a service. However, when this service is remote, a proxy should be created on client side. So, why not plugging the monitoring capability using this proxy (through interceptors)? Can we say that this kind of requirement is an intent that should be indicated by the client? And in this case, should we indicate this intent using a filter as we considered previously? In fact, I can't see any way since the only thing that the client sends to the registry in order to select a server is the filter... Well, sorry about this long email and about those confused ideas. The idea was just to do another brainstorm... Thank you, very much for the attention and patience. Best regards, 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
