[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsrp] (Aliasing) Transient property follow up
I'm not sure if aliasing really helps auto wiring.
If I understood the proposal correct the alias would be an alias for the
name (e.g. event name).
I think this could help wiring only in the case of simple types but really
need human interaction when complex types are used.
So let's say we have an event1 named com.foo.zipChanged with a simple type
of string in the payload.
If another portlet defined event2 com.bar.ChangedZipCode also with a simple
type string then the Consumer could automatically wire both events.
In this case portlets would declare they accept event1 with event2 as the
alias.
What is the difference between the portlet declaring that the accept both
events?
In both cases the portlets have to know that there is another event
representing the same semantics.
If we have complex types I really don't see a value in the alias because
the Consumer has to do the payload transformation. I don't think the
payloads can be described in a manner that autowiring is possible. And if
this is the case the admin has to understand both events and do the wires.
Or are you suggesting that eventnames (i.e. event qnames) and their payload
wouldn't have a 1:1 relationship anymore?
I.e. in the above example the Consumer could send event1 or event2 or worse
change the eventname of event1 but keep the payload of event2?
Is then the Producer doing the payload transformation? In that case what
would the difference be, to place both events into the PortletDescription?
Mit freundlichen Gruessen / best regards,
Richard Jacob
______________________________________________________
IBM Lab Boeblingen, Germany
Dept.8288, WebSphere Portal Server Development
WSRP Team Lead & Technical Lead
WSRP Standardization
Phone: ++49 7031 16-3469 - Fax: ++49 7031 16-4888
Email: mailto:richard.jacob@de.ibm.com
Subbu Allamaraju
<subbu@bea.com>
To
10/24/05 05:17 PM wsrp <wsrp@lists.oasis-open.org>
cc
Subject
Re: [wsrp] (Aliasing) Transient
property follow up
I agree that aliasing would help auto-wiring. I would also argue that
aliasing would help other coordination features like events (e.g.
aliases for event names).
In practice, we find that wiring on the consumer side is somewhat
harder. The admins don't usually know a lot about the exact details of
portlets in a distributed deployment, and to get the wiring correctly,
the admins will have to talk to admins/developers of various producers
out of band. Aliasing would ease some of the mapping burden.
Subbu
Michael Freedman wrote:
> I agree that some/many consumer may provide the developer a way to
> relate two distinct names, I am merely introducing another use case that
> would allow producers to do so [and therefore take advantage of
> auto-wiring capabilities in the consumer]. This type of data is easily
> captured in non-code meta data -- hence one can envision a producer
> administrator updating the meta data without updating the
> producer/version when [auto] interactions with other producer/portlets
> is desired.
> -Mike-
>
> Rich Thompson wrote:
>
>>
>> Your two questions are sufficiently different that I would suggest
>> splitting the discussion into two threads.
>>
>> Relative to aliasing, I see the value, namely; if the portlet
>> developer/deployer knows that the semantics of a particular property
>> is equivalent to another well-known property, it would certainly help
>> the Consumer to make this available in a computer processable form.
>> The question I would raise is whether the Producer is going to be the
>> locus of such information often enough to warrant defining a field for
>> it. I suspect that most often it will be the page developer
>> discovering this as the described semantics of the two properties are
>> compared.
>>
>> Rich
>>
>>
>> *Michael Freedman <michael.freedman@oracle.com>*
>>
>> 10/18/05 03:21 PM
>>
>>
>> To
>> wsrp <wsrp@lists.oasis-open.org>
>> cc
>>
>> Subject
>> [wsrp] Transient property follow up
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> A couple of questions/issues I came up with post F2F on Transient
>> properties:
>> 1. Should the meta data that describes transient properties be
>> improved to support a notion of aliasing?
>> Is there value in distinguishing between the name the portlet receives
>> the transient property as and the set of [coordination] names that
>> identify this property to the consumer? The use case is two [sets of]
>> portlets that are developed independently each with their own
>> namespace/vocabulary for properties sometime afterwards understanding
>> that coordination could also occur between them because the property
>> [semantics] are the same. Current model requires the one/both to
>> change its implementation with potential backwards compatibility
>> impacts. We could however offer another field in the
>> TransientPropertyDescription that is an array of aliases which
>> identify other identities of the same property. Should we add this to
>> our 2.0 design?
>>
>> 2. By defining a specific/known duration for consumerSession
>> scope can we make this a required feature in 2.0?
>> My understanding from our F2F discussions is that producers couldn't
>> rely on transient properties to hold internal state because though we
>> required support for this feature we said it was valid for the
>> consumer to claim support by merely always sending/representing a null
>> value [i.e. value always out of scope]. I think this is a severly
>> restricts the value of transient properties and makes them more akin
>> to NavigationalParameters. Since all we are defining is the
>> consumerSession Scope and that we though unstated this scope is
>> implied/must exist in WSRP 1.0 to support managing portletSessions can
>> we stengthen our proposal by requiring that a transientProperty of
>> consumerSessionScope must be maintained for the exact amount of time
>> that the consumer maintains the portlet's session assuming that
>> portlet session has an infinite lifetime from the perspective of the
>> producer? [I.e. portlet session timeouts aren't a factor in this].
>> By equating this transientProperty scope to the same scope that the
>> consumer manages portletSessions on we create an equivalence between
>> the management of public session state and opaque session state
>> meaning the portlet can now depend on the public state.
>> -Mike-
>> ---------------------------------------------------------------------
>> 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]