[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02

INTERNET-DRAFT
expiration date: April 9, 2016
Intended status: Draft Standard


draft-adligo-hybi-asbp-02
Internet Engineering Task Force (IETF)                        S. Morgan
Request for Comments:                                        Adligo Inc
Obsoletes:                                              October 7, 2016
Category: Standards Track
ISSN:

                Asynchronous Services Bus Protocol

Abstract

   ASBP (Asynchronous Services Bus Protocol) is a simple command based
   application-level protocol for routing data and messages.  ASBP
   is intended to allow implementation of fully Asynchronous
   Service Bus Architectures, in a simple standardized
   manor.  ASBP is intended to be layered over
   WebSocket or HTTP.  The protocol consists of a simple ASCII or UTF-8
   key value(s) header and any arbitrary data (text, binary, XML, JSON,
   etc.), which the application's specific Command-Attendant or
   Command-Respondent processes.  In addition this document touches on
   an extension to ASBP, CP (Conversation Protocol) a protocol used
   to facilitate communication between Asynchronous Service Busses
   implemented or hosted by different organizations.  CP will be
   covered in more detail in another RFC still in progress.

Internet-Draft

      This Internet-Draft is submitted in full conformance with the
      provisions of BCP 78 and BCP 79.

      Internet-Drafts are working documents of the Internet Engineering
      Task Force (IETF). Note that other groups may also distribute
      working documents as Internet-Drafts. The list of current
      Internet-Drafts is at http://datatracker.ietf.org/drafts/current.

      Internet-Drafts are draft documents valid for a maximum of six
      months and may be updated, replaced, or obsoleted by other
      documents at any time. It is inappropriate to use Internet-
      Drafts as reference material or to cite them other than as
      "work in progress.

Copyright Notice

   Copyright (c) 2016 IETF Trust and the persons identified as the
   document authors. All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document. Please review these documents
   carefully, as they describe your rights and restrictions with
   respect to this document.
Morgan                       Standards Track                   [Page 1]


RFC <rfc-no>      Asynchronous Services Bus Protocol       October 2016


Table of Contents

   1. Introduction ...................................................3
      1.1. Background.................................................3
      1.2. Conventions and Terminology................................3
      1.3. Protocol Overview..........................................5
           1.3.1 ASBP Layered on HTTP.................................6
           1.3.2 ASBP Layered on WebSocket............................6
           1.3.3 ASBP Layered on Extended WebSocket...................6
           1.3.4 Header Overview......................................6
                 1.3.4.1 Header Syntax................................7
                 1.3.4.2 Reserved Header Keys.........................7
   2. Asynchronous-Services-Bus Components............................9
      2.1. Channels...................................................9
      2.2. Course.....................................................9
      2.3. Tubes......................................................9
      2.4. Brokers....................................................8
      2.5. Broker-Agents.............................................10
      2.6. User Agents...............................................10
      2.7. Application Agents........................................10
   3  Advantages of Asynchronous-Services-Bus Architecture...........11
      3.1. Maintenance and Upgrades Without Down Time................11
         3.1.1 Large Scale Deployment Diagram........................12
      3.2. Asynchronous-Services-Bus Architecture Usage in
                Three Tiers..........................................13
         3.2.1 Three Tier Command Diagram............................13
      3.3. Asynchronous-Services-Bus Architecture Usage on
                Four+ Tiers..........................................13
         3.3.1 Four Tier Command Diagram.............................14
      3.4. Unlimited Extension of Tiers..............................14
         3.4.1 Unlimited Tier Command Diagram........................15
   4. Protocol Versions..............................................15
   5. IANA Considerations............................................15
   6. Internationalization Considerations............................16
   7. Security Considerations........................................16
      7.1 Firewall Diagram...........................................16
      7.2. Application-Agents Security...............................17
      7.3. User-Agent Subject Security...............................17
           7.3.1. User-Agent Subject Authentication..................17
           7.3.2. User-Agent Subject Authorization...................18
   8. References.....................................................19
        8.1. Normative References....................................19
        8.2. Informative References..................................20
   9.  Acknowledgements..............................................20
   Author's Addresses................................................20






Morgan                       Standards Track                   [Page 2]


RFC <rfc-no>      Asynchronous Services Bus Protocol       October 2016


1.  Introduction

1.1.  Background

   _This section is non-normative._

   Over the past few decades enterprise system architecture has evolved
   quite dramatically with the rise of service oriented architecture,
   cloud computing, WebSockets, and an increasing popularity of
   asynchronous programming.  These improvements to enterprise
   system architecture are all impressive on their own, however they
   would have a much greater impact when combined.

   Service oriented architecture (SOA) is fundamentally a way for
   enterprise architects to separate concerns, add modularization, and
   encapsulation to application code.  However most implementations of
   SOA revolve around the request response paradigm, which does not
   facilitate notification / real time communication very well.

   Cloud computing allows organizations to out-source maintenance
   of computer hardware, high capacity bandwidth, and other cost saving
   advantages. However cloud computing providers seem to have hardly
   any interest in creating and ad-hearing to standards for the cloud
   computing provider industry.  The large cloud computing providers
   seem to be interested in creating their own APIs in an attempt to
   block customers from moving their applications between providers or
   hosting their applications on multiple providers simultaneously.
   This creates the pseudo cloud industry standard of treating the
   (virtual) operating system as the common component provided by
   most cloud providers, which can make application architects
   hesitant to use any of the cloud providers custom APIs.

   The ASBP protocol is designed to create a simple standard to take
   advantage of the major evolutions in enterprise application
   architecture by aggregating the improvements into a abstract modular
   design for asynchronous enterprise services buses.  Hopefully the
   ASBP protocol will become a standard allowing independent software
   vendors to build software components which use the common ASBP
   protocol as a standard intermediary for services.

1.2.  Conventions and Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].






Morgan                       Standards Track                   [Page 3]


RFC <rfc-no>      Asynchronous Services Bus Protocol       October 2016

   The following terms are capitalized and concatenated with a dash to
   indicate a reference to this section;

   Application-Agent:  A program that connects to a Broker to form a
         Tube, with the intention of processing (handling) Commands.
         Each Application-Agent MUST contain a unique
         Application-Agent-Identifier to the Asynchronous-Services-Bus.
         Application-Agents MUST allow for runtime deployment and
         removal of Command-Respondents. Application Agents often will
         manage shared resources (i.e. database connection pools),
         so that the Command-Respondents can perform storage and other
         operations (i.e. start a Hadoop application, send a email,
         etc.).

   Asynchronous-Services-Bus:  A software architecture model used for
         designing and implementing communication between asynchronous
         software agents.

   Authenticate-Command:  A Command known by the the
         Asynchronous-Services-Bus as the Command which
         has a Command-Respondent that authenticates Subjects.

   Authenticated-Command:  A Command sent by a Subject
         who is currently authenticated.

   Broker:  A application running in a web server which MUST be
         compatible with HTTP 1.0 (see [RFC1945]), and HTTP 1.1
         (see [RFC7230]).  A Broker MUST also be compatible with
         the WebSocket (see [RFC6455]) or the HTTP/2 (see [RFC7540])
         protocol.  A Broker SHOULD be compatible with all protocols
         mentioned.

   Broker-Agent:  A Broker-Agent is a combination of a Broker
         and an Application-Agent for three tier implementations of
         Asynchronous-Services-Bus architecture.  Broker-Agents MAY
         use Command-Respondents in a asynchronous or synchronous
         manor.  Broker-Agents are MAY to have
         Application-Agent-Identifiers or runtime deployment and
         removal of Command-Respondents.  Broker-Agents are
         RECOMMENDED only when migrating legacy applications to an
         Asynchronous-Services-Bus architecture, or when a four plus
         tier Asynchronous-Services-Bus architecture is NOT available.
         Four plus tier Asynchronous-Services-Bus
         architecture is RECOMMENDED.

   Channel:  The logical (not physical) connection between a
         User-Agent and a Broker.  A Channel MAY be a
         physical connection in addition to a logical connection.




Morgan                       Standards Track                   [Page 4]


RFC <rfc-no>      Asynchronous Services Bus Protocol       October 2016

   Command:  The Command is a ASBP protocol message which includes a
         ASBP header and MAY include arbitrary data (text, XML, JSON,
         binary, etc.)..  The Command's name MAY be obfuscated.

   Command-Attendant:  A part of an User-Agent which attends to
         individual message based on the Command's name.

   Command-Respondent:  A part of a Application-Agent,
         Application-Broker or Broker which responds to
         individual message based on the Command's name.

   Conversation-Address:  A address similar to a email address
         which has a * instead of an @ (i.e. scott*adligo.com
         instead of scott@adligo.com).  The Conversation-Address
         can be used to target where to send Commands that pertain
         to a conversation of various types (audio, audio/video,
         text/file, and video).  Conversation-Addresses MUST NOT
         include the single quote character (').

   Course:  The logical and physical remote connection between an
         Brokers and or Broker-Agents from different Asynchronous
         Service Busses.

   Cracker:  A entity that is attempting to compromise, or gain access
         and or information that they SHOULD NOT be able to access.

   Broker-Spoofing-Agent:  A program created by a Cracker that acting
         like an Application-Agent in an attempt to compromise a Broker.

   Subject:  A authenticated User-Agent user.

   Tube:  The logical and physical remote connection between an
         Application-Agent and a Broker.

   User-Agent:  The client which initiates a Channel. These are often
               web browsers, web applications running in browsers,
               mobile applications, desktop applications, and other
               software as a service client applications.

1.3.  Protocol Overview

   _This section is non-normative._

   The ASBP protocol is intended to be layered on existing
   protocols like WebSokets and HTTP (1.0, 1.1 & 2) in order to
   facilitate adoption and reduce the number of implementations.
   The protocol consists of a header similar to a HTTP Query (see
   Section 3.4 of [RFC3986]) followed by data of any type
   (text, binary, XML, JSON, etc.). The ASBP messages are always
   intended to be encoded/transferred a binary data, where the ASBP
   header is ASCII or UTF-8 [RFC3629] and the data is unknown.

Morgan                       Standards Track                   [Page 5]


RFC <rfc-no>      Asynchronous Services Bus Protocol       October 2016

1.3.1. ASBP Layered on HTTP

   When the ASBP protocol is layered over HTTP 1.0 the ASBP
   header and OPTIONAL data MUST be placed in the Entity-Body
   (see 4 of [RFC1945]).  In HTTP server responses which use the
   ASBP protocol the HTTP Content-Encoding (see 3.6 of [RFC1945])
   MUST be set to "application" for binary data and the Content-Length
   (see 10.4 of [RFC1945]) MUST be specified.

   When the ASBP protocol is layered over HTTP 1.1 the ASBP
   header and OPTIONAL data MUST placed in the Message Body
   (see 3.3. of [RFC7230]).  In HTTP server responses which use the
   ASBP protocol the HTTP Transfer-Encoding (see 3.3.1 of [RFC7230])
   MUST be set to "BINARY" and the Content-Length
   (see 3.3.2 of [RFC7230]) MUST be specified.

   When the ASBP protocol is layered over HTTP/2 the ASBP
   header and OPTIONAL data MUST be placed in the Application data
   (see 6.1 of [RFC7540]).  In HTTP server responses which use the
   ASBP protocol the HTTP Transfer-Encoding (see 3.3.1 of [RFC7230])
   MUST be set to "BINARY" and the Content-Length
   (see 3.3.2 of [RFC7230]) MUST be specified.

1.3.2. ASBP Layered on WebSocket

   When the ASBP protocol is layered over WebSocket(s) the ASBP
   header and OPTIONAL data MUST be placed in the Application Data
   section (see 1.2 of [RFC6455]).

1.3.3. ASBP Layered on Extended WebSocket

   _This section is non-normative._

   The ASBP protocol may be upgraded so that the ASBP header
   is separated from the Application Data section
   (see 1.2 of [RFC6455]) and encoded using a
   Sec-WebSocket-Extensions (see 11.3.2 of [RFC6455]).
   This document leaves the details on how this would be
   accomplished to other RFCs.

1.3.4. Header Overview

    The ASBP protocol header is a simple Key Value-Token(s) pair data
    structure in the ASCII or UTF-8 character encoding.  The ASBP
    protocol does NOT allow characters to be escaped, however
    Value-Tokens may be wrapped in single quotes to allow usage of
    reserved characters in Value-Token(s).  The ASBP protocol header
    is assumed to be ASCII but may be upgraded to the UTF-8 character
    encoding by starting the header withthe '+' character.



Morgan                       Standards Track                   [Page 6]


RFC <rfc-no>      Asynchronous Services Bus Protocol       October 2016

    An example ASBP header follows (Note RFC line wrap formatting);

    c='display text',g=['friends','country men'],
    d=de305d5475b4431badb2eb6b9e546014;

    An example ASBP message (header and data) follows
    (Note RFC line wrap formatting);

    c='display text',g=[friends,'country men'],
    +d=de305d5475b4431badb2eb6b9e546014;Hello World!

1.3.4.1. Header Syntax

    The following characters are reserved by the ASBP protocol;

    reserved    = ";" / "=" / "," / "'" / "[" / "]" / "+"

    All whitespace characters MUST NOT be included in a ASBP header
    outside of a Value-Token wrapped by single quotes.  In
    addition Value-Tokens MUST NOT contain Carriage-Return (CR) or
    Line-Feed (LF) characters.

    The ASBP header consists of Key Value-Token(s) pairs followed by a
    semicolon which terminates the header.  Each set of Key
    Value-Token(s) is separated by a comma.  Each Value-Token MAY be
    wrapped by single quotes. If a Key has multiple Value-Tokens the
    Value-Tokens MUST be wrapped by square brackets, and the
    Value-Tokens MUST be separated by commas.

1.3.4.2. Reserved Header Keys

    The following chart specifies the reserved ASBP header keys and
    their allowed values and purpose.  Most of these keys are optional
    and should only be used as required by the specific ASBP Commands
    routing requirements.

    Key    Meaning and allowed Values
    a      Application-Agent-Identifier:  A single textual value
           which uniquely identifies an Application-Agent in the
           Asynchronous-Services-Bus.

    b      Broker-Identifier:  A single textual value that uniquely
           identifies the Broker within the Asynchronous-Services-Bus.

    c      Command-Name:  A single textual value, which MAY indicate
           what to do with the data (i.e.  'display text message').
           Note the Deliver Command-Name 'd' is reserved for CP.

    d      Destination:  One or more Channel-Identifiers where this
           ASBP message should be sent to.


Morgan                       Standards Track                   [Page 7]


RFC <rfc-no>      Asynchronous Services Bus Protocol       October 2016

    e      Encoding:  The encoding (i.e. Charset name from RFC 2978
           (see [RFC2978]) ASCII, UTF-8, UTF-16, etc) binary is assumed
           by default when this is absent.  Inside of a application or
           enterprise encoding can also be determined by the Command's
           name.

    f      Format:  A OID used to identify the data type
           when one organization's Asynchronous Services Bus is
           communicating with another organization's
           Asynchronous Services Bus using CP.

    g      Group: One or more group names where this ASBP message
           should be sent to.  A group is a collection of
           Channel-Identifiers that is specific to a Broker.

    i      Channel-Identifier: A single UUID (without dashes) that is
           created by the Broker and guaranteed to be unique at that
           Broker in order to identify the User-Agent Broker channel.

    o      Of-Total: A single unsigned one based text integer of any
           size.  This value is used to identify the order and place
           of this Command in a large number of Commands.
           (i.e. Frame 1,143 in a stream of movie frames.)

    m      Mime Type:  The mime type (see [RFC2046]) if a file is being
           delivered through the Command's data.  This is only
           necessary when the Command could contain arbitrary files in
           the data section.

    r      Recipient:  One or more Conversation-Addresses where this
           Command should be sent to.  This field is only used /
           reserved for Conversation Protocol.

    p      Publisher:  A single Conversation-Addresses identifying
           the Subject who published this Command.  This field is only
           used / reserved for Conversation Protocol.

    s      Subject-Identifier: A single UUID (without dashes) that
           uniquely identifies an authenticated User-Agent's subject
           at the Broker.  The Broker MUST create and provides a unique
           Subject UUID for an authenticated Subject.  ASBP allows
           standard HTTP session tracking to be overridden by the
           Subject-Identifier, in order to enable concurrent usage of
           multiple accounts with in User-Agents.

    t      Total: A single unsigned text integer of any size.  This
           value is used to identify the total number of ASBP messages
           that are expected for a large response.  This key value pair
           should only be included with the first ASBP message in a
           long stream of ASBP messages. (i.e. Total number of video
           frames in a movie.)

Morgan                       Standards Track                   [Page 8]


RFC <rfc-no>      Asynchronous Services Bus Protocol       October 2016

    u      User-Agent to Channel Command-Identifier:  A single unsigned
           text integer unique to the User Agent Channel.  The value
           should be between 0 and 65,563.  The User Agent provides
           this number and should wrap back to 0 after using all
           65,563 identifiers.  This allows the User Agent to
           match request response commands, and order or skip frames
           when necessary.

    x      Exchange-Command-Name:  This field was added in order to
           encapsulate command names to a particular Asynchronous
           Services Bus.  This field is used for the CP (Conversation
           Protocol) in addition to the Command-Name.  This fields
           values MUST use OID or other mechanism which has been
           reserved for the CP.

    z      Compression:  The MIME type for compression used to compress
           the data (i.e. application/x-bzip2, application/x-lzma,
           application/x-gzip, etc).  Note if the MIME type name
           starts with 'application/' the value MAY be abbreviated
           to include the value after the slash (i.e. x-gzip, x-bzip2).


2.  Asynchronous Service Bus Components

   There are three major components to an Asynchronous Service Bus
   User-Agents, Brokers and Application-Agents.  All components
   communicate using Commands.  Commands are transported over the
   various network layers using Channels, Courses, and or Tubes.  A
   Channel is the medium of network communication between a
   User-Agent and a Broker.  A Tube is the medium of network
   communication between an Application-Agent and a Broker.  A
   Course is a medium of network communication between Brokers
   which belong to separate Asynchronous Service Busses.

2.1.  Channels

   A Channel MAY be layered on any of the network protocols mentioned
   by the ASBP protocol including HTTP 1.1 long pooling (for legacy
   User-Agents).  Upon creation of a Channel the Broker MUST assign
   a Broker unique UUID to the Channel as it's Channel-Identifier.

2.2 Courses

   A Course MUST be layered on either a secure WebSocket or
   secure HTTP/2 connection.  Detail on communication through Courses
   will be covered in the RFC for Conversation Protocol.

2.3 Tubes

   A Tube MUST be layered on either a secure WebSocket or
   secure HTTP/2 connection.

Morgan                       Standards Track                   [Page 9]


RFC <rfc-no>      Asynchronous Services Bus Protocol       October 2016

2.4.  Brokers

   Brokers act as the intermediary between User-Agents and
   Application-Agents.  Commands sent to the broker MUST either
   originate from a User-Agent or an Application-Agent.  Brokers
   MUST create a unique User-Agent Channel-Identifier for each
   User-Agent connection.

   Commands originating from a User-Agent are intended to be handled by
   a Broker's, Broker-Agent's, or Application-Agent's
   Command-Respondent.   The Broker MAY alter the Commands header and
   data.  The Broker MAY respond directly to the originating
   User-Agent.  The Broker MAY send the Command to non-originating
   User-Agents.  The Broker MAY send the Command to an
   Application-Agent.  The Broker MAY send the Command to a Broker in
   another Asynchronous Services Bus.

   Commands originating from an Application-Agent are intended to be
   sent to one or more User-Agents, Brokers and or Application-Agents.
   The Broker MAY alter the Command's header or data.  The Broker MAY
   respond directly to the originating Application-Agent.  The Broker
   MAY send the Command to one or more User-Agents.  The Broker MAY
   send the Command to one or more Application-Agents.  The Broker MAY
   send the Command to a Broker in another Asynchronous Services Bus.

2.5.  Broker-Agents

   Broker-Agents MUST only be used in three tier
   Asynchronous-Services-Bus implementations.  Broker-Agents MAY be
   used to migrate away from legacy three tier systems or when no
   Broker/Application-Agent frameworks are available.  Brokers-Agents
   MAY send Commands to the same locations as Brokers.

2.6.  User-Agents

   Stateless (HTTP 1.0, 1.1) User-Agents MUST obtain a unique channel
   identifier from the Broker and submit the channel identifier with
   all subsequent commands.

2.7.  Application-Agents

   Application-Agents MUST connect to Brokers using a Tube.
   Application-Agents MUST authenticate with the Broker during
   Tube connection (this is covered in more detail in Security
   Considerations).  Application Agents MUST notify the broker of
   commands supported by the Application-Agent.

   Application-Agents MAY be created as a single program (i.e. JVM)
   or as a group of programs which share a
   Application-Agent-Identifier.  Application-Agents MUST be able to
   add or remove Command-Respondents at runtime.

Morgan                       Standards Track                  [Page 10]


RFC <rfc-no>      Asynchronous Services Bus Protocol       October 2016

3. Advantages of Asynchronous-Services-Bus Architecture

   _This section is non-normative._

   Asynchronous-Services-Bus Architecture provides a number of
   advantages, many of which are already
   enjoyed today by service oriented architectures.
   Asynchronous-Services-Bus architecture can be easily scaled by
   adding additional layers of Brokers and Application-Agents.
   Additional resources can be added with ease while running in a
   production environment from almost all public clouds or private
   clouds.  In addition since the Asynchronous-Services-Bus
   Architecture is designed to be compatible with most
   cloud service providers, switching between cloud providers to save
   money becomes less difficult improving ROI, and the potential risk
   of a single cloud provider raising prices on the organization is
   reduced.

3.1. Maintenance and Upgrades Without Down Time

   _This section is non-normative._

   Medium to large installations of Asynchronous-Services-Bus
   architecture allow maintenance and upgrades without down time!
   Each of the three Asynchronous-Services-Bus components may be
   removed or added while the Asynchronous-Services-Bus stays in
   production.

























Morgan                       Standards Track                  [Page 11]


RFC <rfc-no>      Asynchronous Services Bus Protocol       October 2016

   Consider the following deployment diagram when upgrading
   an Enterprise scale application from Version 1.0 to Version 2.0
   (lines indicate network connection bundles);

3.1.1 Large Scale Deployment Diagram

   Application-Agent A      Application-Agent B    Application-Agent C
         |           \      /                \      /        |
         |            \    /                  \    /         |
         |             \  /                    \  /          |
         |              \/                      \/           |
         |              /\                      /\           |
         |             /  \                    /  \          |
         |            /    \                  /    \         |
         |           /      \                /      \        |
         |          /        \              /        \       |
         |         /          \            /          \      |
         |        /            \          /            \     |
         Broker A                Broker B              Broker C
               \                     |                  /
                \                    |                 /
                 \                   |                /
                  \                  |               /
                   \                 |              /
                    \                |             /
                     \               |            /
                      \              |           /
                       \             |          /
                        \            |         /
                         \           |        /
                           Domain Name System
                              User-Agents

   1) Remove Broker C from the DNS entries.
   2) Shutdown Application-Agent C,
        Configure Application-Agent C to connect to Broker B only
        Start Application-Agent C
   3) Shutdown Application-Agent B,
        Configure Application-Agent B to connect to Broker A only
        Start Application-Agent B
   4) After 24 hours (proliferation of DNS caching),
      shutdown Broker C
   5) Upgrade and start Broker C
   6) Shutdown and Upgrade Application-Agent C
       Configure Application-Agent C to connect to Broker C only
       Start Application-Agent C
   7) Add Broker C to the DNS entries

   At this point one third of the Asynchronous-Services-Bus is running
   Version 2.0.  The other two thirds are running Version 1.0.  Simply
   repeat the upgrade pattern until all nodes are running Version 2.0.

Morgan                       Standards Track                  [Page 12]


RFC <rfc-no>      Asynchronous Services Bus Protocol       October 2016

   The above upgrade procedure is actually a worse case scenario!
   Most of the upgrades for software running on a
   Asynchronous-Services-Bus can be accomplished with much less effort.
   Brokers have a very small amount of code, and need to be upgraded
   quite infrequently.  New web application front ends (User-Agent)
   can be hot deployed and favored using URL rewriting.
   Application-Agents can be added and removed at any time.  The
   Subjects SHOULD only see errors if a Broker receives Commands
   which are not know by any attached Application-Agents.

3.2. Asynchronous-Services-Bus Architecture Usage on Three Tiers

   _This section is non-normative._

   Asynchronous-Services-Bus Architecture does not necessarily need
   a large number of servers or a complex DNS setup.  Asynchronous
   Services Bus Architecture can be developed for a typical three
   tier system, and scaled as growth and demand is needed.

   The following diagram displays a three tier deployment of an
   Asynchronous-Services-Bus Architecture;

3.2.1 Three Tier Command Diagram
                                  Database or other
   User-Agent     Broker-Agent         Storage
    |                 |                    |
   ---               ---                  ---
   | |----Socket---->| |                  | |
   | | ----ASBP----->| |                  | |
   | |               | |-----Socket------>| |
   | |               | |<------Data-------| |
   | |<----ASBP------| |                  | |
   ---               ---                  ---
    |                 |                    |

   Diagram Note: The lines on the above diagram display both socket
   connections (which could be any non ASBP protocol) and
   Command flows.  The lines which include the word Socket indicate
   the directionality of the network sockets.  The ASBP lines do
   NOT show the directionality of the network sockets, but instead
   show the flow of the Command.

3.3. Asynchronous-Services-Bus Architecture Usage on Four+ Tiers

   _This section is non-normative._

   Great care should be taken when writing Asynchronous Services
   Bus Architecture so that the great majority of Application
   Agent code can be simply moved to a four tier deployment.



Morgan                       Standards Track                  [Page 13]


RFC <rfc-no>      Asynchronous Services Bus Protocol       October 2016

   The following diagram displays a four tier deployment of an
   Asynchronous-Services-Bus Architecture;

3.3.1 Four Tier Command Diagram

                                                 Database or other
   User-Agent      Broker    Application Agent        Storage
    |                 |            |                     |
   ---               ---          ---                   ---
   | |               | |<-Socket--| |                   | |
   | |-----Socket--->| |          | |                   | |
   | | ----ASBP----->| |          | |                   | |
   | |               | |--ASBP--->| |                   | |
   | |               | |          | |-----Socket------->| |
   | |               | |          | |<-----Data---------| |
   | |               | |<--ASBP---| |                   | |
   | |<----ASBP------| |          | |                   | |
   ---               ---          ---                   ---
    |                 |            |                     |

   Diagram Note: The lines on the above diagram display both socket
   connections (which could be any non ASBP protocol) and ASBP
   Command flows.  The lines which include the word Socket indicate
   the directionality of the network sockets.  The ASBP lines do
   NOT show the directionality of the network sockets, but instead
   show the flow of the Commands.

3.4. Unlimited Extension of Tiers

   _This section is non-normative._

   The following diagram uses the term Intermediary-Agent, which
   is simply a Application-Agent that is also a User-Agent in this
   context. The following diagram displays a unlimited tier
   deployment of an Asynchronous-Services-Bus Architecture;


















Morgan                       Standards Track                  [Page 14]


RFC <rfc-no>      Asynchronous Services Bus Protocol       October 2016

3.4.1 Unlimited Tier Command Diagram

   User-Agent      Broker    Intermediary-Agent        Broker
    |                 |            |                     |
   ---               ---          ---                   ---
   | |----Socket---->| |<--Socket-| |-----Socket>------>| |<-Socket
   | |-----ASBP----->| |          | |                   | |
   | |               | |---ASBP-->| |                   | |
   | |               | |          | |-------ASBP------->| |etc.->
   | |               | |          | |<------ASBP--------| |<-etc.
   | |               | |<--ASBP---| |                   | |
   | |<----ASBP------| |          | |                   | |
   ---               ---          ---                   ---
    |                 |            |                     |

   Diagram Note: The lines on the above diagram display both socket
   connections (which could be any non ASBP protocol) and ASBP
   Command flows.  The lines which include the word Socket indicate
   the directionality of the network sockets.  The ASBP lines do
   NOT show the directionality of the network sockets, but instead
   show the flow of the Commands.

4. Protocol Versions

   The initial ASBP version if accepted as a IETF standard will be 1.0.
   Subsequent versions of ASBP should use the following major dot
   minor version scheme.

   Major version numbers MUST only be incremented when a break in
   backward compatibility with the previous major version is
   required.  Backward compatibility is always preferred.

   Minor version number MUST be incremented for each approved
   update to the Asynchronous-Services-Bus Protocol standard by the
   IETF.

5.  IANA Considerations

   ASBP is layered on other protocols
   including HTTP and WebSockets in order to keep IANA considerations
   minimal for use and implementation with in organizations.  There are
   no schemes or keywords to be registered for ASBP for use and
   implementation with in organizations.

   However, CP (Conversation Protocol) an extension to ASBP which
   will enable conversations by utilizing Asynchronous
   Service Busses from multiple organizations will require IANA
   considerations.  In particular the Exchange-Command-Names
   and Formats will require a OID to extend from for each extension.


Morgan                       Standards Track                  [Page 15]


RFC <rfc-no>      Asynchronous Services Bus Protocol       October 2016

6.  Internationalization Considerations

   The only internationalization consideration was to require the
   ASBP header to be encoded in UTF-8, so that command names and
   other values could use non English languages.

7. Security Considerations

   _This section is non-normative._

   This section describes some security considerations applicable to
   ASBP.  ASBP relies on the protocols it is layered on to provide
   details on how to secure usage of ASBP, namely HTTP, or WebSocket
   over SSL (see [RFC6101]).  This section focuses on topics not
   covered by the secure protocol layers which ASBP supports.

   The ASBP protocol originally started as a Java application framework
   called the ASDC  (Adligo Secure Data Connector), which was inspired
   by the Google Secure Data Connector.  One of the initial goals of
   the protocol and framework was to allow data centers to protect
   themselves better by blocking all in bound fire wall ports as
   follows.

7.1 Firewall Diagram

   Application-Agent   Firewall A  Broker   Firewall B     User-Agent
        |                 |          |           |             |
       ---               ---        ---         ---           ---
       | |               | |        | |         | |           | |
       | | --------ASBP------------>| |         | |           | |
       | |               | |        | |         | |           | |
       | |               | |        | | <-------ASBP----------| |
       | |               | |        | |         | |           | |
       ---               ---        ---         ---           ---
        |                 |          |           |             |

   Firewall A would not require any open in bound ports since the
   Application-Agent dials out to the Broker.  If two
   Application-Agents were hosted at different data centers they
   could synchronize data stores through the Brokers.  Data centers
   could also synchronize data stores through actual private networks,
   or virtual private networks.  Virtual private network
   synchronization would require opening up some in bound
   ports, however even in this case data center is much more difficult
   to breach even when the Broker layer is compromised.

   Firewall B would require standard ports to be open (i.e. 80, 443)
   for public web applications.  Other ports could be open for non
   standard applications as well (i.e. 22, 8080, etc.)



Morgan                       Standards Track                  [Page 16]


RFC <rfc-no>      Asynchronous Services Bus Protocol       October 2016

   Using this design also allows the Broker's SSL certificates to be
   used for both Tubes and Channels.  This reduces the number of
   SSL certificate installations by roughly half for end to end
   SSL in most applications.

7.2. Application-Agents Security

   _This section is non-normative._

   Application-Agents must authenticate with the Broker in order to
   prove that they are the agents which are suppose to be handling
   the Commands.  Failure to create an extra strong
   authentication mechanism from the Application-Agent to the Broker
   would enable a new type of application attack
   'Application-Agent spoofing'.

   A Application-Agent spoofing attack would occur when a Cracker
   creates a program (Broker-Spoofing-Agent) that attempts to connect
   to a Broker in the same manor as a Application-Agent.  If the
   Broker-Spoofing-Agent was able to successfully connect to a Broker,
   it could potentially receive Commands pertaining to Subject
   credentials or other sensitive data.

   The ASBP protocol does not attempt to create any sort of a standard
   for Application-Agent to Broker authenticate.  It is believed that
   each organization that uses a Asynchronous-Service-Bus with the
   ASBP protocol should develop their own unique authentication
   mechanism.  By not specifying a standard here, users of the
   protocol will create a more secure web through diversity, and
   Crackers will have more difficulty compromising the systems because
   they all work differently.

7.3. User-Agent Subject Security

   The ASBP protocol supports multiple Subjects using a
   particular User-Agent.  Brokers and Broker-Agents MUST allow
   multiple Subjects to authenticate from a single User-Agent.
   Brokers and Broker-Agents MAY also allow
   the single Subject/User-Agent authentication session
   methodology in use by most web applications today.
   ASBP REQUIRES multiple Subject per User-Agent in order
   to allow a user to use multiple accounts in a web
   application, and to facilitate more efficient use of User-Agent
   (browsers) resources during concurrent testing of
   Asynchronous-Service-Bus applications.

7.3.1. User-Agent Subject Authentication

   The ASBP protocol facilitates Subject based authentication at the
   Broker-Agent, and Application-Agent tiers.  The ASBP
   protocol provides Subject-Identifier and Broker-Identifiers to
   allow authentication security as follows.

Morgan                       Standards Track                  [Page 17]


RFC <rfc-no>      Asynchronous Services Bus Protocol       October 2016

   When the Broker receives a authentication attempt from a
   User-Agent's Subject the Broker MUST create a
   Subject-Identifier (a UUID unique to the Broker).  Next the Broker
   MUST modify or create a ASBP header appending the
   Subject-Identifier and the Broker-Identifier, before sending
   the Authentication-Command to one or more Application-Agents
   which are known to process the Authenticate-Command.

   This allows the Application-Agents to be aware of which
   Broker the Subject authenticated through, and the
   Subject-Identifier at that Broker.  After a successful
   authentication the Application-Agent MUST return
   the Subjects model through a Command which includes
   the Application-Agent-Identifier to the Broker.
   Broker MUST return the Subject-Identifier through a
   'authentication successful' Command to the User-Agent.

   When the Broker-Agent receives a authentication attempt from a
   User-Agent's Subject the Broker MUST create a
   Subject-Identifier (a UUID unique to the Broker).  The Broker-Agent
   would then find a Command-Respondent to authenticate the Subject
   from the Broker-Agent tier.

   User-Agents that are state-less MUST provide the
   Subject-Identifier in the ASBP header in all subsequent
   Authenticated-Commands.

   If the Broker or Broker-Agent is using the single Subject per
   User-Agent paradigm it MAY use the HTTP sessions identifier to
   locate the Subject-Identifier.

   The Broker MUST keep track of which Application-Agents
   have authenticated particular Subjects, in order for
   Application-Agents to correctly process authorization.
   The Broker MUST only submit Commands to Application-Agents
   that have authenticated the Subject for subsequent
   Authenticated-Commands. The Broker MUST ensure inclusion
   of the Subject-Identifier in all subsequent
   Authenticated-Commands that are sent to the Application-Agents.

7.3.2. User-Agent Subject Authorization

   The ASBP protocol facilitates Subject based authorization security
   at the Broker, Broker-Agent, and Application-Agent layers.  The ASBP
   protocol does not specify or suggest any particular structure for
   Subject authorization models, however it is designed to support
   common ACL, LDAP User/Group/Role isInRole(X) style authorization
   security with out knowledge of implementation.




Morgan                       Standards Track                  [Page 18]


RFC <rfc-no>      Asynchronous Services Bus Protocol       October 2016

   Application-Agents, Brokers, Broker-Agents and User-Agents MAY all
   perform authorization security checks.  User-Agents authorization
   security checks are considered informative to the Subject only, and
   MUST NOT be relied on to prevent unauthorized Command usage.
   User-Agent authorization checks SHOULD obfuscate the names of roles
   if isInRole(X) style checks are used.  Broker,
   Broker-Agent, and Application-Agent authorization security checks are
   considered a reliable way to prevent unauthorized Command usage.

   Most Asynchronous-Services-Bus implementations SHOULD attempt to
   reuse code for identical authorization security check in the
   Broker, Broker-Agent and Application-Agent layers.

8.  References

8.1.  Normative References

   [RFC2046]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
              Extensions (MIME) Part Two: Media Types", RFC 2046,
              November 1996.

   [RFC2119]  S. Bradner, "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997

   [RFC2978]  N. Freed, J. Postel, "IANA Charset Registration
              Procedures", BCP 19, RFC 2978, October 2000.

   [RFC3629]  Yergeau, F., "UTF-8, a transformation format of ISO
              10646", STD 63, RFC 3629, November 2003.

   [RFC3986]      Berners-Lee, T., Fielding, R., and L. Masinter,
                  "Uniform Resource Identifier (URI): Generic Syntax",
                  STD 66, RFC 3986, January 2005.



















Morgan                       Standards Track                  [Page 19]


8.2.  Informative References

   [RFC1945]  T. Berners-Lee, R. Fielding, and H. Frystyk, "Hypertext
              Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996

   [RFC6101]   Freier, A., Karlton, P., and P. Kocher, "The Secure
               Sockets Layer (SSL) Protocol Version 3.0", RFC 6101,
               DOI 10.17487/RFC6101, August 2011,
               <http://www.rfc-editor.org/info/rfc6101>.

   [RFC6455]  I. Fette, and A. Melnikov, "The WebSocket Protocol",
              RFC 6455, December 2011

   [RFC7230]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
              Protocol (HTTP/1.1): Message Syntax and Routing",
              RFC 7230, June 2014.

   [RFC7540]  M. Belshe, R. Peon, and M. Thomson, Ed., "Hypertext
              Transfer Protocol Version 2 (HTTP/2)", RFC 7540,
              May 2015


































Morgan                       Standards Track                  [Page 20]


RFC <rfc-no>      Asynchronous Services Bus Protocol       October 2016

9. Acknowledgements

   Note I am waiting on a response from this thread to acknowledge
   the authors of the Google Secure Data Connector;
   https://groups.google.com/forum/#!topic/google-sdc/fL4TsSxZD_Q

Author's Addresses

Scott Morgan
scott@adligo.com

Adligo Inc
http://www.adligo.com

expiration date: 10/07/2016





































Morgan                       Standards Track                  [Page 21]

Html markup produced by rfcmarkup 1.123, available from https://tools.ietf.org/tools/rfcmarkup/