Assembly open issues for callbacks and conversations

[Simon Nash <NASH@uk.ibm.com>]

A full-text search of sca-assembly issues
containing the text "bidirectional", "callback" or
"conversation" produced the following issues (after eliminating
duplicates and closed or resolved issues) with potentially signifcant semantic
impact:

ASSEMBLY-33
ASSEMBLY-47
ASSEMBLY-56
ASSEMBLY-59

The first of these is already on the
agenda for this week's F2F.  I request that the other 3 issues listed
above also be discussed at the F2F.

    Simon

Here are the detailed results of my
search.
 
[bidirectional]

ASSEMBLY-4  Dynamic change of callbacks
(resolved)

ASSEMBLY-56  Need to clarify definition
of Bidirectional Interfaces (not discussed or resolved)

    Nature of Issue: The text
which defines the semantics of Bidirectional 
    interface need clarification. 

    The text on Bidirectional interface currently states that
the inclusion of 
    a callbackInterface attribute is used to identify an interface
    to be bidirectional. This only give information on correlation
of the 
    entire callback interface with the service interface. 

    However, there are three questions regarding correlation
of individual 
    operation types defined for the bidirectional interface,
which are not 
    answered by this specification: 

    1) Does every operation type invoked onto the "service
interface" 
    direction have the potential to have correlated callback
interface 
    operations in the opposite direction? 

    2) Does every operation invocation invoked onto the callback
interface 
    have to be considered as a callback for an operation invocation
on the 
    service interface? 

    3) How can it be specified (at design time) which operation
types defined 
    in the callback interface description can be correlated with
which 
    individual operation types defined in the service interface
description? 

[callback]

ASSEMBLY-50  default
binding for callbacks (closed no action)


ASSEMBLY-45
 some smaller things we need to fix in the assembly specification
(resolved) 

ASSEMBLY-29
 Ambigous Service Resolution
(closed no action) 

ASSEMBLY-32  SCA
schema fixes requested for sca-core.xsd (based on OSOA site versions, that
may be copied to OASIS site)

    Affects XSD syntax only.
 Does not affect callback semantics. 

ASSEMBLY-66
 Introduce a top-level interface element in SCDLs (rejected)


ASSEMBLY-12
 Abstract base type for Service and Reference
(fixed)

ASSEMBLY-33  Long-Running
Request-Response Operations

    On the agenda for discussion
at the Walldorf F2F meeting. 

conversation:

ASSEMBLY-59
 Conversations with more than 2 participants

    Line 2386 says: "Conversations
occur between one client and one target service." 
  
    However, we have encountered situations where the user would
like for a
    single conversation to
occur among a larger group of participants, rather
    than considering every
conversation to be limited to two parties. 
  
    In many circumstances, you can't really tell. If a call chain
looks like this: 
      A - B - C 
  
    Then it isn't obvious how it would be different if you consider
the A/B 
    conversation to be the
same conversation as the B/C conversation
    or different. However,
if you have a diamond calling pattern like this: 
  
      B1 
     / \ 
    A C 
     \ / 
      B2 
  
    Then it is important. If there are multiple conversations,
then there
    will be multiple instances
of C, one for its conversation with B1
    and one for its conversation
with B2. If it is all considered to be
    one conversation, then
there will only be one instance of C. (It is
    easiest to think of this
in terms of instances, but even if C were
    "stateless",
it would still be semantically sharing state for the
    conversations with B1
and B2). 
  
    In a common case, all of the components within a composite
should
    share a single conversation.
However, the mechanism should also
    allow for conversation
sharing at a smaller scope. 
  
    Note that the diamond pattern shown above is the way that
the
    SCA Java specification
treats the request scope. The request scope
    is like a conversation
that is shared among all of the local services
    involved in the handling
of a single remotable request. If the
    assembly specification
introduced N-ary conversations, then the
    SCA-J specification would
be able to eliminate the concept of the
    request scope in favor
of this more general mechanism. 

ASSEMBLY-22  WSDL extension should
not be required for conversations (resolved)

ASSEMBLY-35  Confusing words in
Section 5.3 relating to ConversationalIntent (resolved)

ASSEMBLY-7  Replacement of binding types (closed no action)

ASSEMBLY-47  Interface element
needs an operation child element

    The current assembly specification
defines an endsConversation
    attribute that can be
used in WSDL documents to mark an operation
    as ending a conversation.
However, there will be cases where it is
    not possible to annotate
the WSDL document defining an operation.
    For example, the WSDL
file may be controlled by an external
    organization. In this
case, it must be possible to mark the operation
    in the SCDL. This could
also occur when the interface is specified
    in other languages when
for a variety of circumstances, it may not
    be possible to annotate
the source document. 


Simon C. Nash, IBM Distinguished Engineer
Member of the IBM Academy of Technology
Tel. +44-1962-815156  Fax +44-1962-818999

---

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