Martin Beck wrote: > Hi, > > I'm currently working on a presentation about tuscany's wiring and > autowiring concepts for my studies. Up until now, I was staring at the > java code and some of the javadoc... ;) I identified the mechanisms of > the Interceptors, MessageHandlers and TargetInvokers, which are used on > the source and target side of a wire. > However, I still can't get behind the goal of all this stuff. By now, it > seems to me that the wires are built up by the Runtime once the module > is loaded and hided from the application developer who just uses > tuscany. Is this right?
Yes. The goal is to allow the application developer to write implementation code with all the wiring handled by the runtime - this is a fairly classic IoC architecture. Wires are actually built in two phases. In the first phase, the source and target side each build up outbound and inbound wires for just their part; in the seconds the runtime connects outbound and inbound sides together, potentially adding Interceptors and MessageHandlers as part of the process. > But the usages of interceptors and handlers who come into my mind (e.g. > logging, filtering, conversation) require access to the internal wire > model by the application developer, if he for example wants to hook his > own interceptor into the wirechain. If someone wants to hook directly to the wirechain then yes they will need to know the intricacies of with wire model. Although we will allow that, the intention is that they would define these things at a higher level. For example, system behaviour like security or transaction would be specified in terms of policy declarations in the standard SCA assembly model (the is spec activity defining some of this). We would expect a developer or application assembler to say something like "I need a transaction here" rather than having to deal with interceptors. For higher level function, we would like to support a set of aspect or mediation programming models that could be used to define business-oriented things like auditing, filtering, custom routing etc. They would write to that programming model and its integration would deal with the wiring. Hopefully this would be standardized in the SCA spec, but we could also support models from existing implementation such as Synapse. > Additionaly, I didn't found many > classes implementing interceptor and messagehandler interfaces, i.e. > only only MessageDispatcher extends MessageHandler and therefore I dont > see something really using the messagechannels. ;) > Yeah - we started with the intention of supporting policies using this mechanism but didn't quite get to it. There is a small example where we started to use it in the async support. This should get some more attention in the next release. > In http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg04104.html > I read about the "showcase" features of SCA. I think, features like > "dynamic re-wiring" would need sophisticated knowledge about tuscanys > wiring by the application developer as he is the only one, who can > decide whether to use this feature, didn't it? > The intent behind SCA is that this really shouldn't be in the province of the application developer but in the hands of the people managing the SOA network. The goal is to let the application developer write business function without dependencies on infrastructure or wiring - hence the IoC nature. Then the people running the network (applications) can rewiring using the assembly model or other mechanism without impacting the code the developers wrote. For this to work, we need sophisticated wiring mechanisms to support the "white magic." However, the goal is to hide that complexity from the users, developers, assemblers, adminsitrators. > So my concrete question is: Why there is such a complex wirechain if it > is almost not used (by now)? What are your goals with it, if wires are > managed by the Tuscany Runtime, and not the application developer? > I hope I covered the goals above. For what we're doing now it is perhaps overkill but expect it to be used as we add in async, policy, etc. > As a last example, I could imagine using the MessageDispatcher to > broadcast an invocation to more than one components (whyever). But this > wouldn't be possible according to the spec because a wire is defined as > the connection between two components. > You're right in saying wires connect two components but the spec does support the concept of multiplicity at least at the reference level - the application is passed a collection of wires and is responsible for using them individually. Personally I'd like to see this expanded so that concepts like multicast vs. unicast were built into the wiring, or so that some form of wire identification was provided (Map rather than Collection style behaviour in Java terms). You've raised a whole bunch of real issues here that would be good to capture - would you be able to help us pull them together as scenarios on the wiki? Thanks -- Jeremy --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
