Hi David, Well, I have an idea that we could use to debate more concretely about this topic. Currently, I am (trying to) implementing a monitoring layer on top of CXF/DOSGi. My target would be a distributed environment composed by services that could be monitored. In such an environment, an administrator could, at any time, signal that a service should be monitored (here I could consider initially response time and availability). I thought that he could signal that changing the value of an intent (maybe from Visual VM console using a MBean). That intent would indicate to the Importing Distribution Provider (IDP) that it should register whether a request was successfully responded and the time that it took to get a response. If the IDP could understand that intent, it would collect that data and use it to update a QoS database that would, in a future, be used during service selection. However, if the IDP can not understand that intent, it could safely ignore it. At any moment, the administrator could shutdown service monitoring again changing the corresponding intent. In such an environment, I could maybe even introduce a service that is not a OSGi service, but a WS for example. In that case, it would be sufficient to register a corresponding "Endpoint descriptor" in Zookeeper repository including that "consumer side and optional" intent, for example.
What do you think about this idea? Cheers, Fábio is to develop a way that could allow me to collect some metrics related to service utilization. On Thu, Oct 21, 2010 at 6:33 AM, David Bosschaert <[email protected]> wrote: > 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 <[email protected]> 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 >> <[email protected]> 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 <[email protected]> >>> 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 >>>> <[email protected]> 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 <[email protected]> >>>>> 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 >> > -- Fábio
