[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [sca-assembly] ISSUE 40: Autowire at the domain-level
Hi Sanjay, Comments inline. Jim On Jan 25, 2008, at 10:13 AM, Patil, Sanjay wrote: > > +1 to the concern that the autowiring at the domain level would be > dangerous in enterprise production environments. > I don't mind if autowire is off by default at the domain level but I don't think the domain composite should be special-cased for this. FWIW, I'm involved in several customer projects where autowire is being used at the domain level and we have not run into these problems. Whether autowire is dangerous at the domain level really depends. I'm sure Dave is going to be horrified by this but I'll state it anyway: I think a fairly strong argument can be made that autowire at the domain level is actually *safer* in some environments. Here, it is less likely that services offered by "domain-level" components will have the same contracts. In these situations, duplicates are more likely to occur at lower levels of composition. Also, if we eventually include some form of query-based wiring, the chances of "accidents happening" will be reduced. If autowire defaults to off, I don't see how autowire is dangerous in production environments. People would need to make a conscious decision to turn it on. I also don't see why autowire is necessarily more dangerous than at lower levels of composition. In other words, I don't think we can generalize that all environments will have a large number of services with the same contract at the domain level. > I think the use of autowire feature (if it stays) should be limited to > simplifying assembly development environment (e.g. the target of a > wire > is obvious to the composite developer, or there are just too many > obvious wires cluttering the visual representation and the composite > SCDL file), and we should require that the autowires be resolved > before/while a composite is deployed. I'm not sure I follow. Why should autowire be treated differently than any other wire? For example, we allow the deployment of a composite containing only wires into the domain. Again, I've run into the need for dynamic autowire in the projects I am involved with. A common pattern where this occurs is with multiplicity references on registries, i.e. a component that maintains a collection of services it dispatches to for processing. To help explain where I am coming from, I've written a long-winded description of an issue a customer has faced implementing a very large Java-based SCA application (+50m transactions a day): A financial institution (one of the projects) has a set of components that are responsible for handling payment transactions. As part of this process, payment messages need to have certain data formated in different ways as back-end systems are updated. This was implemented using a registry of formatter services. If explicit wires were used, the registry reference would need to be updated to target all formaters (via a wire element or as a list of target uris on the reference). Otherwise, they would need to wire from the formatters to the registry and the registration would be performed programmatically in an initialize method (or in the constructor which is bad IMO). Either way, this is burdensome given some of the formatters are in included composites. The other option is to use autowire. The company came up with two implementation styles. The first was to create a registry interface, use autowire on the formatters, and have them register programmtically in an initialize method. The other option, which I think is easier from an implementation perspective, was to autowire from the registry. In this case, a runtime cannot guarantee that formatters will all be loaded prior to the registry. Having dynamic autowire gets around this as the registry (composite scoped) can be reinjected as new formatters come online. I also believe this registry pattern can be encountered at the domain level, particularly in small runtime environments that are highly extensible where plugins need to register capabilities after the runtime and some composites have been deployed. > > > -- Sanjay > >> -----Original Message----- >> From: David Booz [mailto:booz@us.ibm.com] >> Sent: Thursday, Jan 24, 2008 21:50 PM >> To: sca-assembly@lists.oasis-open.org >> Subject: Re: [sca-assembly] ISSUE 40: Autowire at the domain-level >> >> Or we could choose to disallow autowire at the Domain level >> for everyone. >> At the very least, I think it should be an optional feature >> if it stays. >> If it stays, then I'd like the default to be off for the Domain. >> >> My main concern with autowire in the domain is that it is >> potentially very >> dangerous in a large enterprise production environment. It has the >> possibility for un-intentional side effects. Those >> environments generally >> like to put very tight control over the relationships between >> the different >> parts of the system (domain). I suspect that since you raised the >> question, there may be other environments where less rigor is >> tolerable and >> surprises can be dealt with easily, e.g. turning your phone >> off and then on >> again. In those cases it seems that the introduction of a new >> autowire >> target into the domain is one of the drivers of the re-injection >> capability. I think this is your second bullet below. >> >> >> >> Dave Booz >> STSM, SCA and WebSphere Architecture >> Co-Chair OASIS SCA-Policy TC >> "Distributed objects first, then world hunger" >> Poughkeepsie, NY (845)-435-6093 or 8-295-6093 >> e-mail:booz@us.ibm.com >> http://washome.austin.ibm.com/xwiki/bin/view/SCA2Team/WebHome >> >> >> >> >> Scott Vorthmann >> >> <scottv@tibco.com >> >>> >> To >> Michael Rowley >> <mrowley@bea.com> >> 01/22/2008 07:11 >> cc >> PM "OASIS Assembly" >> >> >> <sca-assembly@lists.oasis-open.org> >> >> Subject >> [sca-assembly] ISSUE >> 40: Autowire >> at the domain-level >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> http://www.osoa.org/jira/browse/ASSEMBLY-40 >> >> On Jan 22, 2008, at 3:54 PM, Michael Rowley wrote: >> >>> >>> RAISER: Michael Rowley >>> >>> TARGET: SCA Assembly Specification section 6.4.2 Autowire >>> >>> DESCRIPTION: >>> >>> Assume that a component is deployed at the domain level has a >>> reference that has been marked to be resolved by autowire. If a new >>> component is deployed later that qualifies as a target for the >>> autowire, will the existing component now target the new component? >>> The specification could: >>> - Require that the runtime handle such dynamic changes and effect >>> such changes onto existing component references. >>> - Allow that some runtimes may freeze the results of autowire at the >>> time the client component is deployed, while others will treat the >>> autowiring as dynamic. >>> - Allow some runtimes to completely disallow autowiring for domain- >>> level components. >>> >>> PROPOSAL: >>> >>> None. >>> >> >> >> --------------------------------------------------------------------- >> To unsubscribe from this mail list, you must leave the OASIS TC that >> generates this mail. You may a link to this group and all your >> TCs in >> OASIS >> at: >> https://www.oasis-open.org/apps/org/workgroup/portal/ >> my_workgroups.php >> >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe from this mail list, you must leave the OASIS TC that >> generates this mail. You may a link to this group and all >> your TCs in OASIS >> at: >> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgr >> oups.php >> >> > > --------------------------------------------------------------------- > To unsubscribe from this mail list, you must leave the OASIS TC that > generates this mail. You may a link to this group and all your TCs > in OASIS > at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]