Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ecf-dev] Intents in ECF

Hi Scott,

Thank you, very much for your answer. Can I make a few more questions? As far as I understood, the intents are applied on both sides, as they MUST be suported by the providers on both sides in order to enable consumer/provider communication, is this right? What about an intent like transaction, for example? Can a service use such intent just to say that it support transaction? In this case, what kind of support is expected from the client side? Does it make sense to have an intent like log to ask the provider on the server side to log requests (like in cxf)? In that case, does it make sense to require that the provider on the client side support log too?

thanks,

Fábio

On Mon, Jan 10, 2011 at 7:42 PM, Scott Lewis <slewis@xxxxxxxxxxxxx> wrote:
Hi Fabio,


On 1/10/2011 2:28 PM, Fabio souza wrote:
Hi,

Just to complete my previous email, I would like to know if ECF differentiates between those intents that have an impact only on the server side and those that impact both sides. Is there something like an intent type?

No.  In the OSGi 4.2 remote services specification there are some pre-defined service properties that allow intents (as Strings) to be passed to providers/implementers (like ECF).  Specifically, for the host/server side service properties with these keys are allowed/expected:

service.intents
service.exported.intents
service.exported.intents.extra

The values of both of these properties can be String+ (which means either a single String or an arbitrary length String[]).

In ECF's implementation, the values of these properties are passed to ECF providers, in order find a match (i.e. a provider that can satisfy the given intents).  If a match is found, then that/those providers are used to export the remote service (make it available remotely via the selected/matching provider).

The intents required by the exported service are communicated (through the EndpointDescription) to the consumer/client, and in ECF's implementation the providers are also consulted to match a provider that can satisfy the required intents.  If found, then the provider is used to import the remote service (i.e. create/use a proxy).


I ask this because in SCA we have 2 types of intents, which are interaction intents and implementation intents. How are these concepts mapped to OSGi?

The distinction between interaction intents and implementation intents doesn't seem to be made in the OSGi specification...there are just 'intents' (as per the service properties listed above).

Hope this helps.

Scott


As far as I know, there are no differences between then in the OSGi spec.

Thanks again,



On Mon, Jan 10, 2011 at 6:37 PM, Fabio souza <fabio.nogueira.souza@xxxxxxxxx> wrote:
Hi,

I have some doubts concerning the idea of DOSGi intents and its implementation. I have being using another DOSGi implementation (CXF) and, there, the idea of intents is implemented using the interceptor pattern. In fact, when a remote service is published locally, a distribution provider creates a corresponding endpoint. Then, the intents that are indicated during service publication are mapped to interceptors which are appended to the endpoint (in fact, to the corresponding chains of interceptors). Once this endpoint is created and configured, it can be exported to an external repository where it can be found by a client. 

In this scenario, a service developer/publisher can indicate to the SERVER SIDE distribution provider (using intents) that some special processing is needed in order to this service become remotely available. Those intents are interpreted and the corresponding interceptors are added to the corresponding endpoint's chains. Such an intent can be, for example, a Log intent which instructs the distribution provider on the server side to log all requests that arrive to this service.

When a client is going to use a remote service, the distribution provider on the CLIENT SIDE creates a proxy which can also have some interceptors appended to it. Let´s consider the necessity of cryptography as an example... Well, when we say that a service should receive encrypted requests, it will not be able to process a request which is not encrypted. So, when we create a proxy to this service on the client side, this proxy should include an interceptor which is responsible for encrypting the request before sending it to the server side. The endpoint on the server side must also have an interceptor which is responsible for decrypting the request. So, in this case, an intent set on the SERVER SIDE is motivating the creation of interceptors on BOTH sides of the communication.

I wonder, however, if the client could establish some requirement to the distribution provider on its own side. For example, consider a client that would like to indicate that its requests should be monitored from the client perspective (so that, for example, the round-trip time and marshalling time could be captured and that failures could be logged). This kind of "intent" makes sense only to this client, and not to other clients from the same service. Well, in this case we could plug the monitoring capability using the proxy to the remote service (through interceptors). Can we say that this kind of requirement is an intent that should be indicated by the client? And in this case, how could we indicate such intent since the only thing that the client sends to the registry in order to select a server is a filter?

Well, sorry about this long email and about those confused ideas. In fact, this is basically a brainstorm.

Thank you, very much for the attention and patience.

Best regards,
 
Fábio



--
Fábio
_______________________________________________ ecf-dev mailing list ecf-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/ecf-dev


_______________________________________________
ecf-dev mailing list
ecf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ecf-dev




--
Fábio

Back to the top