[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
On Jan 29, 2008, at 8:53 PM, Patil, Sanjay wrote: > > I share the concern that some 20% use cases may be adding a lot of > complexity. I also think that the 'autowire' feature falls in the 20% > category. > Like Dave said, I think we are going to disagree on the 20% use case. As some anecdotal evidence, many of the dependency-related technologies today support or are based on autowire. Google Guice and PicoContainer are both based on it. While many of the Spring people prefer explicit wiring, they have been heavily criticized for the XML- verbosity this creates - so much so that they are now introducing a new @Autowired annotation in Spring 2.5 (they have had autowire support in XML for years). I definitely share the sentiment that complexity when it is not needed is a bad thing but in this case I think complexity is a bugbear. Cutting down on XML (or the gesture of drawing a wire in a GUI environment) is IMO a simplification. For example, in many respects, Giuce and PicoContainer are a lot easier to use than Spring. Also, as Mike pointed out, special casing the domain composite is arguably introducing more complexity as it is another behavior people need to remember. > While there may be valid use cases for supporting the autowire feature > at the domain level, there are potential issues in doing so: > > - Expensive: With every new deployed service, the runtime will have to > reevaluate all the predeployed references with autowiring turned on > (assuming the reference multiplicity allows for new targets). I was the one who implemented autowire resolution in Fabric3 and WebLogic Server and the performance impact we are seeing is negligible. So much more goes on during deployment that resolution is just noise. I have two cases that I think prove my point. The first is that, except for a small core bootstrap, the Fabric3 runtime is itself assembled entirely using autowire. There are a significant number of components that make up the runtime and we have not optimized the autowire resolution code but we still have very fast start-up time. I haven't profiled startup in depth, but from what I have seen, introspection of Java classes required to determine componentType information takes much more time than autowire. As a second example, we have found autowire to be fast enough to use during iterative development in an IDE. A couple of weeks ago, I used it to implement an IntelliJ plugin for Fabric3. Several of our users were complaining that component testing was cumbersome. So, we added the ability for someone in IntelliJ to write a JUnit test class and annotate injection sites with @Reference. When they right-click on the test class, they can select "Run" (just like the standard JUnit test runner), and the class will be used as a component implementation and have all @Reference sites injected with autowired services. The JUnit class can then drive test cases which invoke and verify the autowired services. Under the covers, the plugin runs an embedded SCA runtime. As the runtime is booted, a composite with the JUnit component definition is synthesized which includes an application composite containing the services to be tested via autowire. The IDE project is contributed to the embedded domain with the synthesized composite used as the deployment composite. On my machine (dual core) this entire process occurs in a couple hundred milliseconds (which also includes autowiring the entire embedded runtime). From the developer's perspective, all they need to deal with is writing a JUnit class and clicking a button. This would not have been possible without autowire. In terms of reevaluating references, again, I think this will be relative noise. What I think will take more time is reinjection, particularly in a distributed environment. In this case, some form of change notification will need to be sent to the runtime node, communication channels will have to be established for the new wire, and proxies will need to be updated. I would bet the time spent doing that in addition to the network latency incurred from sending the change notification will be much more than scanning part of a domain model. > > - Unpredictable: Not all services that provide the same interface are > equally qualified to be a target for every reference asking for that > interface. For example, there may be multiple services for the same > interface, and each service may be providing a different quality of > service in terms of response time, reliability of operations, etc. > Some > of the QoS aspects may be related to infrastructure and therefore > may be > expressed via SCA binding metadata. However, there may be other > application level QoS aspects that can not be modeled via SCA metadata > and therefore would not be considered as part of the autowire matching > algorithm. Such situations may lead to unintended wiring (which is > clearly dangerous for production scenarios) If autowire by default is off, none of this can happen unless someone explicitly turns it on. Also, I suspect tooling will come along that helps with this. For example, I would expect some vendors to ship deployment tools that determine if a service and reference can be wired before deployment is to take place. Similarly, such a tool could show a deployer how an autowire would be resolved prior to deployment. > > - Difficult to control: There would be scenarios (e.g. controlled > rollout of new services) where the deployer of a service would want to > expose the service to select clients. It is not clear whether and > how a > newly deployed service can exclude itself from being a target of > autowired references. I don't think explicit wires are going to help here either since someone could come along an wire a client to the new service. The only way to guarantee this is to use encapsulation provided by composites. > > - Complex: The autowire feature is adding complexity to the > specifications. In addition, once we give consideration to edge > scenarios (e.g. when autowire setting of a deployable composite > conflicts with that of the domain composite), the description of the > autowire feature is going to be even more complex. I think it would take one or two sentences in the spec to address this case. I'm willing to write them up if it would help. > Also, if we wanted to > define different semantics for the autowire feature for a developer > vs. > a deployer role, that will add another dimension of complexity. > I don't think this would be legal: wire resolution only happens at deployment. > - Not strictly necessary: I guess the use cases where autowire is very > valuable are in a minority, and moreover, there is also a strong > possibility that such use cases may be better met with some other > solution e.g. eventing (I don't have a solid data to back up this > point, > but nevertheless I think it is an important point). I'm having difficulty making this connection but would be happy to explore alternatives. I understand autowire to deal with how a reference is targeted - that seems substantially different than eventing. > > Assuming folks agree with above concerns, I wonder whether the > 'autowire' feature (in any form) is worth the effort! > I think so! We've spent very little effort writing it up, it's been relatively easy to implement, and we have people using it extensively. Jim > -- Sanjay > > >> -----Original Message----- >> From: David Booz [mailto:booz@us.ibm.com] >> Sent: Tuesday, Jan 29, 2008 6:32 AM >> To: sca-assembly@lists.oasis-open.org >> Subject: Re: [sca-assembly] ISSUE 40: Autowire at the domain-level >> >> <soapbox> >> When we started this SCA effort, we tried to focus on the 80% >> use cases in >> order to deliver the basic functionality of SOA composition >> as fast as we >> could. Over time we've slowly added more and more of the 20% >> cases which >> has caused us to drift into becoming a complex environment. >> I even heard >> someone say 'platform' one time. That's a red flag for me. >> I definitely >> consider Domain level autowire to be on the 20 side of the >> 80-20 rule. I >> think autowire is a very valuable capability for assembling >> fine grained >> components down in the composite implementation hierarchy as >> they tend to >> have similar lifecycles. I think autowire is an awesome >> capability to ease >> a developer's experience with the programming model because >> it helps SCA >> stay out of his way. Autowire doesn't translate well into >> the deployer's >> world where the concerns are quite different, e.g. applying >> policy, mapping >> to topologies, ensuring availability and adequate capacity, >> etc. SCA is >> becoming too complex and we need to consciously resist the >> urge to throw in >> everything that seems interesting. I believe we will fail if >> we attempt to >> rule the world in the first release. >> <soapbox/> >> >> The rub comes in when we don't agree what the 80% use cases >> are. There are >> definitely cases where a Domain is constrained such that >> autowire is likely >> to not introduce problems, e.g. and OSGI based runtime on a >> cell phone. I >> think I said that in my email below. It's just that I put those >> environments on the 20 side of the 80-20 rule for an SOA composition >> technology. Given the caveats in my soapbox above, I think >> we are making a >> mistake WRT complexity. However, if there is truly a split >> in the TC on >> this issue then I'd be willing to accept the following: >> 1) Autowire in the virtual Domain composite is OFF by >> default. The default >> remains OFF even when a deployment composite containing >> autowire="true" is >> deployed into the Domain. Perhaps a warning should be issued. >> 2) Autowire in the virtual Domain is an optional compliance point. >> 2) SCA runtimes can provide a switch to enable autowire at >> the domain level >> if they so choose. When the switch is on (domain_autowire = >> "true"), a >> deployment composite with autowire="false" will produce a warning. >> >> Is there anyone that might want to experiment with autowire >> such that some >> component assemblies in the Domain participate in autowire >> and some don't? >> If so, then we shouldn't do anything to preclude this, but again, it >> shouldn't be part of the spec. IMO. >> >> >> >> 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 >> >> >> >> >> Jim Marino >> >> <jmarino@bea.com> >> >> >> To >> 01/28/2008 06:18 "Patil, Sanjay" >> >> PM <sanjay.patil@sap.com> >> >> >> cc >> David >> Booz/Poughkeepsie/IBM@IBMUS, >> >> <sca-assembly@lists.oasis-open.org> >> >> 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 >>> >> >> >> >> >> --------------------------------------------------------------------- >> 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]