[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
<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
>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]