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. 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 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/[EMAIL PROTECTED] 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
