Hi Simon,
I’ve had another chat with the user
that originally raised this issue. From their point of view what they want to conceptually
ask is:
“For
two ServiceReferences A and B, will invoking A.getService().someOperation() and
B.getService().someOperation() result in the same target Component running the
code twice?”
On the question of whether the ServiceReferences
use different binding – the user does not really care. From the user’s
point of view, the binding that is used is a deployment issue and should not
affect the code in the Component Implementation. Currently, when writing a
Component implementation, the developer does not need to worry about which
binding is used to connect Components/Services. This is one of the major
benefits of SCA. Therefore, it should be irrelevant in the comparison.
However, having said that the binding is
irrelevant, perhaps in some cases the binding may be relevant.
I would like to propose the following:
If we decide that comparing the Binding is
important then:
- ServiceReference.equals()
method – ServiceReferences are considered equals if they refer to
the same SCA Service and Conversation (if Conversational) and use the same
binding.
- Add
new method such as ServiceReference.isSameTarget() – ServiceReferences
are considered the same if they refer to the same SCA Service and
Conversation (if Conversational)
If we decide that comparing the Binding is
irrelevant then:
- ServiceReference.equals()
method – ServiceReferences are considered the same if they refer to
the same SCA Service and Conversation (if Conversational)
How does this sound?
Thanks,
Mark
Mark Combellack| Software Developer| Avaya | Eastern Business Park | St. Mellons | Cardiff |
CF3 5EA | Voice: +44 (0) 29 2081 7624 | mcombellack@avaya.com
From:
Simon Nash [mailto:NASH@uk.ibm.com]
Sent: 20 May 2008 18:02
To: sca-j@lists.oasis-open.org
Subject: Re: [sca-j] NEW ISSUE:
equals() method on ServiceReference and CallableReference
Mark,
What
does it mean for two service references to be equal? They could have
different bindings (and therefore completely different endpoint URIs) but
connect to the same SCA service. If we want to support equality for such
cases, I think the serialized form of a service reference would have to contain
some unique ID for the service that it connects to. It's not clear to me
how this unique ID could be generated reliably. Defining this would
require an SCA Assembly issue, not an SCA Java issue.
Then
there's the question of what effect the intents/policysets applying to a
service reference have on its equality semantics. If I have two service
references for the same service, but one is secure and one isn't, are they
equal? For the use case you have in mind, would you want them to be
treated as equal?
Simon
Simon C. Nash, IBM Distinguished Engineer
Member of the IBM
Academy of Technology
Tel. +44-1962-815156 Fax +44-1962-818999
ashok malhotra
<ashok.malhotra@oracle.com>
20/05/2008 15:45
Please
respond to
ashok.malhotra@oracle.com
|
|
To
|
Mark Combellack <mcombellack@avaya.com>
|
cc
|
sca-j@lists.oasis-open.org
|
Subject
|
Re: [sca-j] NEW ISSUE: equals() method on
ServiceReference and CallableReference
|
|
If
the equals method involves comparing URIs for equality, do we need to
say some words
about how URIs should be compared? I can provide
some words if needed.
All the best, Ashok
Mark Combellack wrote:
>
> RAISER: Mark Combellack
>
> TARGET: SCA Java Common Annotations and APIs
>
> DESCRIPTION:
>
> The equals() and hashCode() methods are some
of the fundamental Java
> Object methods that are used for comparing
objects. The SCA Java
> specifications do not describe what should
happen when the equals() or
> hashCode() methods are called on a
ServiceReference or CallableReference.
>
> Without an explicit statement, SCA developers
will not know whether
> they can compare ServiceReferences and
CallableReferences.
>
> I’ve sent an email to the SCA-Java list
(see link below) that contains
> an example usage scenario.
>
> http://lists.oasis-open.org/archives/sca-j/200805/msg00037.html
>
>
> PROPOSAL:
>
> Update the specification to state that the
equals() method for
> ServiceReference can be used to test whether
they refer to the same
> target.
>
> Update the specification to state that the
equals() method for
> CallableReference can be used to test whether
they refer to the same
> target.
>
> Update the specification to state that the
hashCode() method for
> ServiceReference and CallableReference must
comply with the hashCode()
> contract as defined by Java - see
> http://java.sun.com/j2se/1.5.0/docs/api/java/lang/Object.html#hashCode()
> <http://java.sun.com/j2se/1.5.0/docs/api/java/lang/Object.html#hashCode%28%29>
>
>
> Mark Combellack| Software Developer| Avaya |
Eastern Business Park |
> St. Mellons | Cardiff | CF3 5EA | Voice: +44
(0) 29 2081 7624 |
> mcombellack@avaya.com <mailto:%7Cmcombellack@avaya.com>
>
---------------------------------------------------------------------
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