OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

sca-assembly message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: 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:


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.


Here are the detailed results of my search.

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?


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.


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:
    / \
   A C
    \ /
   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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]