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