[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
Ok. Thanks for the clarification. I would like to understand why it is all or nothing. One of the arguments for supporting autowire at the domain-level is that we not create exceptions wrt inclusion semantics. Not allowing mix and match actually creates an exception. One thought I have is, why not make the autowire value of the logical domain composite implementation-dependent. It may default to any value that the implementation chooses and an implementation may have implementation-specific way to set it (or not). If I wanted to ensure that certain domain-level references always get auto-wired (irrespective of the implementation used), then I'm free to set the autowire on that reference (or the containing component/composite) to be true. -Anish -- David Booz wrote: > I was suggesting that we override the previous include decision in favor of > allowing/disallowing Domain wide enablement. The use cases that I was > hearing did not involve a mix and match of autowire in the Domain, it was > an all or nothing use case, and thus my proposal simply reflected that > understanding. > > > 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 > > > > Anish Karmarkar > <Anish.Karmarkar@ > oracle.com> To > David Booz/Poughkeepsie/IBM@IBMUS > 02/25/2008 04:47 cc > PM sca-assembly@lists.oasis-open.org > Subject > Re: [sca-assembly] ISSUE 40: > Autowire at the domain-level > > > > > > > > > > > It looks like we don't have a consensus on 80-20 split wrt autowire in > general and autowire at the domain-level in particular. > > I also have concerns about complexity, dynamicity, and conformance to > autowire. > > But more to the point, WRT your proposal of setting default value of > autowire of the virtual domain composite to be 'false': Why do we need it? > Can't the components and component references that are deployed into the > domain set the autowire atribute to 'true'? For the case where the > deployment composite has an autowire='true', I image we would use the > rules for sca:include -- since the deployment composite is sca:included > into the virtual domain composite. > > -Anish > -- > > David Booz wrote: >> Your concern about the need for a language richer than interface/policy >> matching at the Domain level is a good point, and one that I keep >> forgetting to mention explicitly. FWIW, OSGI has this kind of > capability. >> Because SCA doesn't have this language unpredictability, as you call it, >> emerges. +1 >> >> 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 >> >> >> > >> "Patil, Sanjay" > >> <sanjay.patil@sap > >> .com> > To >> David Booz/Poughkeepsie/IBM@IBMUS, > >> 01/29/2008 11:53 > <sca-assembly@lists.oasis-open.org> >> PM > cc > > Subject >> RE: [sca-assembly] ISSUE 40: > >> Autowire at the domain-level > > > > > > > >> >> >> >> >> 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. >> >> 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). >> >> - 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) >> >> - 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. >> >> - 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. 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. >> >> - 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). >> >> Assuming folks agree with above concerns, I wonder whether the >> 'autowire' feature (in any form) is worth the effort! >> >> -- 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 >> >> >> >> >> --------------------------------------------------------------------- >> 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_workgroups.php >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]