Re: What is autowire

[Jean-Sebastien Delfino <js...@apache.org>]

Jeremy,

Ok that helps, I have a few more questions below.

Jeremy Boynes wrote:
> Jean-Sebastien Delfino wrote:
>   
>> - Autowire was introduced by Tuscany. It is only available as a Java5
>> annotation now. If Autowire is a first class thing should't we add it to
>> the assembly model and the XSD as well?  I was thinking about modeling
>> AutoWire as a specialization of Wire, but I'm not sure I ever completely
>> understood this Autowire concept. Could somebody describe what an
>> Autowire represents to help me model it?
>>
>>     
>
> I view an autowire as a generalization of a Reference.
>   
Do you mean that Reference is a specialization of an Autowire? Would 
Reference extend Autowire?

Who do you think would declare an Autowire? the app developer defining 
the component type? or the app developer configuring a component or 
placing the component in an assembly?

> A Reference has a service contract that has both functional and
> non-functional requirements. The functional requirements are things like
> the interface and what the operations on it do; the non-functional
> requirements are things like the policies that must be applied to
> fulfill the contract terms but which are not represented in the operations.
>
> For example, an account service may expose an operation that adds an
> entry to the account. The functional part of that could an operation
> that described the type of entry that could be added; the non-functional
> part could include a requirement that the operation be performed within
> the context of the same global transaction the client was using.
>
> [[ There's room for debate over exactly what non-functional means but my
> intention here is to mean requirements that are part of the client
> service contract that are not in the interface signature. ]]
>
> Currently a Reference definition does not provide any way to specify
> these non-functional requirements; all a Reference definition specifies
> is the functional requirements, supplied in the form of an interface.
> However, before a Reference can actually be used it must be associated
> with a Wire - either explicitly through a <wire> or implicitly inside
> the <references> definition of the component usage. The Wire, through
> the policies attached, defines the non-functional behaviour.
>
> This is very simple to use but it has two problems:
> 1) the assembler must supply wires for every Reference the components
>    have. However, there are many wires whose routing can be expressed
>    as a set of rules (e.g. always wire a reference to the auditing
>    service to a specific audit server) and for those it simplifies
>    the assemblers job if they can automatically be wired by the system
>
>   
Are you saying that an Autowire is the expression of many wires through 
a set of rules? Is it the assembler who specifies the Autowire rules? or 
somebody else?

> 2) there is no way the system can check that the non-functional
>    requirements that the client has are actually being met given the
>    way the components have been wired. For example, the account client
>    may be implemented in a way that requires that two account update
>    operations are performed in the same transaction but there is no
>    way that the system can enforce this as there is no way to supply
>    the metadata indicating this requirement.
>
> Autowire addresses these issues by generalizing a Reference definition
> to allow the provision of metadata that describes these non-functional
> requirements. It becomes the system's responsibility to ensure that
> these requirements have been met given the way the component has been
> configured.
>
> One of the non-functional requirements that you can have is that the
> assembler must provide the URI of the service provider. What this means
> is that during the assembly process someone must provide a target URI to
> configure the autowire - if there are no other constraints imposed, this
> maps exactly to what they have to do now in order to configure a reference.
>
> Autowire allows you to provide other constraints though. For example,
> the audit case I mentioned above can be handled by adding a constraint
> that says that the autowire should be resolved by wiring to the audit
> server for the current environment. The system now has enough metadata
> to be able to perform that automatically (assuming that there is some
> way of designating something as being the local audit server) which
> means that the business rule will always be enforced and that the
> assembler does not need to configure the wire manually.
>
> Or, for the account example, a constraint can be added that says that
> the account service autowire must be resolved to a provider that can
> operate within the same global transaction as the client. If the
> assembler mistakenly wires it to one that can't meet that requirement
> the system can detect that error and reduce the risk of inconsistent data.
>
>
> The autowire implementation we have right now is fairly basic. It is
> only implemented for system components and only operates on the
> functional requirement specification. What you can do is annotate a
> field/setter on a system component as @Autowire and the system context
> will automatically connect you to a system service that provides the
> service defined by the interface. I proposed an algorithm for how things
> are located here:
> http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200603.mbox/%3c440F5257.10209@apache.org%3e
> and Jim has now implemented it.
>
> To get all the function I described above we need to extend our
> implementation to support the metadata for the non-functional
> requirements. This means two bits of work:
> 1) support that allows providers to publish the capabilities that they
>    have (e.g. I can enroll in an XA transaction, I am the audit service
>    for this machine)
> 2) support that allows clients to specify the capabilites that they
>    require
>
> We also need to extend the autowire implementation to be able to resolve
> more things. There used to be a //todo on AutowireContext that said that
> but it seems to have been removed.
>
> --
> Jeremy
>
>   
-- 
Jean-Sebastien

Re: What is autowire

[Jeremy Boynes <jb...@apache.org>]

Jean-Sebastien Delfino wrote:
> Jeremy,
> 
> Ok that helps, I have a few more questions

I snipped my original, comments inline.

> 
> Do you mean that Reference is a specialization of an Autowire? Would
> Reference extend Autowire?
> 

Yes. Yes. My thinking is that a Reference is a specialization of an
Autowire which adds a constaint that requires that a target URI for a
provider be defined. This is a common enough usage pattern that we
define a specific specialization for it.

It is also possible to think of it the other way around: that an
Autowire is a Reference with additional information that determines
which policies must be applied. That seems easier as it just means that
we extend Reference to support constraints.

However, I think this isn't quite right when it comes to the concept of
Configured Reference. An Autowire can have constraints on it that are
not expressed in the contract for Reference but which are implicitly
there in the selection of the provider.

It's a very fine distinction and I've flip-flopped mentally on this over
the years :-)

> Who do you think would declare an Autowire? the app developer defining
> the component type? or the app developer configuring a component or
> placing the component in an assembly?


I think it is the app developer defining the componentType. The
constraints on the autowire express requirements that the client
implementation has that are not defined by the functional contract
(interface). Those constraints apply to every usage (deployment) of that
implementation and so don't belong in the assembly (composition).

However, the assembler needs to be able to supply values used by the
system as it resolves the autowire. If you treat reference configuration
as fulfillment of the constraint that a target URI must be supplied,
then there has to be a way for the assembler to provide a value for the
target uri.

[[ note viewing wiring this way is not something we expect a user to do
- they should just be able to wire a reference to a service. It's more
of a view of how the internals work. ]]

>> 1) the assembler must supply wires for every Reference the components
>>    have. However, there are many wires whose routing can be expressed
>>    as a set of rules (e.g. always wire a reference to the auditing
>>    service to a specific audit server) and for those it simplifies
>>    the assemblers job if they can automatically be wired by the system
>>
>>   
> 
> Are you saying that an Autowire is the expression of many wires through
> a set of rules? Is it the assembler who specifies the Autowire rules? or
> somebody else?
> 

Kind of. To be precise, I would say that Autowire allows the expression
of rules that constrain how a user or the system can wire the assembly.
The actual wiring can be done explicitly by the assembler or implicitly
by the system but in all cases the constraints must be met.

I think the assembler follows rules specified by someone else. That
someone could be the component implementor who uses them to express
assumptions made by his implementation (like it needs to be able to call
a service in the same transaction context). Or it could be someone
responsible for business policies (like that all audit be done by a
particular service). Or it could be done by the assembler to capture a
set of "best practices" that they use.

--
Jeremy