Assembly open issues for callbacks and conversations

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