From:
Mike Edwards [mailto:mike_edwards@uk.ibm.com]
Sent: 22 May 2008 12:20
To: OASIS Java
Subject: RE: [sca-j] NEW ISSUE:
equals() method on ServiceReference and CallableReference
Mark,
I'd
like to pick up on a small phrase that may be crucial in understanding this
issue better:
"...result in the same target
Component running the code twice"
Is
the question here really about the same "target Component instance"
running twice, or
is
it really about distinguishing between distinct target service implementations?
...or
are there different use cases for both of these?
Instances
become important where there are conversations going on - clearly in that case,
calling
an operation is potentially very different depending on whether it is within
conversation A
rather
than conversation B.
Target
service implementations become important when the operation(s) concerned have
side
effects, even if there is no conversation going on. Create/update/delete
style operations
have
this nature. Invoking these twice for the same service implementation
will probably give
a
very different result from invoking them twice on distinct target services.
Whether
you can establish that the same target service implementation is involved for
targets
accessed
via non-SCA bindings is a problem that we will have to consider.
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
"Mark Combellack"
<mcombellack@avaya.com>
22/05/2008 09:47
|
To
|
<sca-j@lists.oasis-open.org>, Simon
Nash/UK/IBM@IBMGB
|
cc
|
|
Subject
|
RE: [sca-j] NEW ISSUE: equals() method on
ServiceReference and CallableReference
|
|
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
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