OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

sca-assembly message

[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


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
>




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]