This Confluence has been LDAP enabled, if you are an ASF Committer, please use your LDAP Credentials to login. Any problems file an INFRA jira ticket please.

Child pages
  • Service References
Skip to end of metadata
Go to start of metadata

The characteristics of service references 

The basic requirements are as follows:

  1. CallableReference/ServiceReference is used to address a SCA component service over a given binding
  2. Some states can be associated with the CallableReference/ServiceReference, such as the conversationID and callbackID
  3. The CallableReference/ServiceReference can be passed around even accross binding protocols (subject to mashaling and unmashaling)
  4. Be able to create a (java) proxy for a business interface to invoke the service which is represented by the CallableReference/ServiceReference

In the current code, we use live java pointers to support local usage of CallableReference/ServiceReference and I would like to enhance them support
the remote case as well. The key is to capture enough metadata and remove the dependency on live model objects.

The structure of the object graph:

    businessInterface: Class
    factory: WireObjectFactory
                        source: EndpointReference
                        component: RuntimeComponent
                        service: Contract
                        binding: Binding
                        callback: EndpointReference
                        target: EndpointReference
                   invocationChains: InvocationChain

  • business interface class name
  • component reference (componentURI, reference binding type, reference binding URI, callback binding type, callback binding URI)
  • conversation id
  • callback id

Serialization of a CallableReference

The target attribute of a <reference> is list of relative URIs (componentName/serviceName). The URI is only resolvable in the context of the containing composite.

Let's assume we have the following composition:

composite1 --- component1 (implementation.composite) --- component11#reference1
                                                                                  --- component12#service1

And component11#reference1 is declared as follows:

<reference name="reference1" target="component12/service1">

When we create a CallableReference for "component12/service1", I think we need to capture the URI of the containing component as well.

The base URI is "component1/component11" (the URI of the component that declares the reference) and the relative URI is "component12/service1". The resolved URI could be "sca:/component1/component12#service1". The reason I use "#" instead of "/" for the service is to avoid the ambigulity when the relative URI is "component12" if "service1" is the only available service.

The serialized CallableReference can look like:

<reference xmlns:t="" t:conversationID="conversation_001" t:callbackID="callback_001">
    < interface="<businessInterfaceClassName>"/>
    <binding.choice uri="sca:/component1/component12#service1"/>

I'm thinking of using <binding.choice> as an internal binding that encapsulates a list of candidate bindings which later on can be matched against the service.

<reference name="$internal$.callableReference" target="component12/service1"

    < interface="<businessInterfaceClassName>"/>

Resolve a CallableReference/ServiceReference to live model objects for local optimizations:

How is a CallableReference/ServiceReference can be used?

Associate a ServiceReference with a reference

The component that consumes the ServiceReference should declare a reference
(wiredByImpl=true). When a component receives the ServiceReference, it
should try to bind it to a declared reference.

  • No labels