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
- From: Mike Edwards <mike_edwards@uk.ibm.com>
- To: "OASIS Assembly" <sca-assembly@lists.oasis-open.org>
- Date: Tue, 26 Feb 2008 09:22:18 +0000
Anish,
Some questions inline.
I'm in favour of allowing autowire at
the domain level, but I argue that the default value for the Domain
itself should be autowire="false"
and that all references that want to use the autowire feature must be
explicitly marked. "Controlled
indeterminacy"
Yours, Mike.
Strategist - Emerging Technologies, SCA & SDO.
Co Chair OASIS SCA Assembly TC.
IBM Hursley Park, Mail Point 146, Winchester, SO21 2JN, Great Britain.
Phone & FAX: +44-1962-818014 Mobile: +44-7802-467431
Email: mike_edwards@uk.ibm.com
Anish Karmarkar <Anish.Karmarkar@oracle.com>
26/02/2008 07:04
|
To
| David Booz <booz@us.ibm.com>
|
cc
| sca-assembly@lists.oasis-open.org
|
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).
<mje> "implementation"
you here mean "SCA runtime", correct?
I'd prefer not to do this,
so as to reduce the level of barriers to portability
</mje>
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.
<mje> That is my
position - require the value to be set on the components/references</mje>
-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
>
---------------------------------------------------------------------
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
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
3AU
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]