qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (Jira)" <j...@apache.org>
Subject [jira] [Commented] (QPID-8361) [Broker-J] Create a developer guide for Qpid Broker-J
Date Tue, 17 Sep 2019 13:22:00 GMT

    [ https://issues.apache.org/jira/browse/QPID-8361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16931447#comment-16931447

ASF GitHub Bot commented on QPID-8361:

alex-rufous commented on pull request #36: QPID-8361: [Broker-J] Create a developer guide
for Qpid Broker-J
URL: https://github.com/apache/qpid-broker-j/pull/36#discussion_r325161989

 File path: doc/developer-guide/src/main/markdown/architecture.md
 @@ -0,0 +1,399 @@
+# High Level Architecture
+This article provides a high level description of the architecture of Qpid Broker-J.
+Broker-J is messaging broker that implements the AMQP protocols (version 0-8, 0-9, 0-91,
0-10 and 1.0).
+Any AMQP compliant messaging library can be used with the Broker. The Broker supports on
the fly message translation
+from one AMQP protocol to another, meaning it is possible to use the Broker to allow clients
that use different
+AMQP protocol version to exchange messages. It can be managed over a built in HTTP interface
+(that presents a REST API and a Web Management Console), or by AMQP Management (early draft
+The Broker has a highly pluggable architecture that allows alternative implementations to
be substituted for any concern.
+For instance, you can simply build a module delegating to your own storage or own authentication
provider linking
+to your enterprise authentication backend.
+Broker-J is 100% pure Java.  It can be run standalone or embedded within another Java applications.
+## Model
+A tree of manageable categories, all of which extend of the interface `ConfiguredObject`,
underpin the `Broker`.
+A `ConfiguredObject` has zero or more attributes, zero or more children and zero or more
context variable name/value pairs.
+A `ConfiguredObject` may be persisted to a configuration store so its state can be restored
when the Broker is restarted.
+The manageable categories are arranged into a tree structure.  `SystemConfig` is at the root
and has a single descendent
+`Broker`.  The `Broker` itself has children: `Port`, `AuthenticationProvider`, `VirtualHostNode`
amongst others.
+`VirtualHostNode` has a child `VirtualHost`.  The children of the `VirtualHost` are categories
that directly involved
+in messaging such as `Queue`. The diagram below illustrates the category hierarchy but many
categories are elided for brevity.
+The model tree structure is codified in the `BrokerModel` class.
+![Broker Model](images/model.png)
+## Category Specializations
+Some categories have specialisations.  An example is the category `Queue`.  It has specialisations
corresponding to
+the queue types supported by the `Broker` e.g. `StandardQueue`, `PrirorityQueue` etc.
+### Attributes
+Each `ConfiguredObject` instance has zero or more attributes.   Attributes have a name and
a value which can be
+a Java primitive value or an instance of any class for which an `AttributeValueConverter`
exist.  This mechanism allows
+ attribute values to be `Lists`, `Sets`, `Maps`, or arbitrary structured types `ManagedAttributeValues`.
+Attributes are marked up in the code with method annotations `@ManagedAttribute` which defines
+whether the attribute is mandatory or mutable.  Attributes can also be marked a secure which
indicates restrictions
+ no how the attribute is used (used for attributes that that store passwords or private-keys).
+Attributes can have default values. The default value applies if the user omits to supply
a value when the object
+is created.  Defaults themselves can be defined in terms of `context variable` references.
+### Context Variables
+Each `ConfiguredObject` instance has zero or more context variable assignments. These are
simply name/value pairs
+where both name and value are strings.
+When resolving an attribute's value, if the attribute's value (or attribute's default) contains
a context variable
+reference (e.g. `${foo}`), the variable is first resolved using the `ConfiguredObject`'s
own context variables.
+If the `ConfiguedObject` has no definition for the context variable, the entity's parent
is tried,
+then its grandparent and so forth, all the way until the `SystemContext` is reached.
+If the `SystemContext` provides no value, the JVM's system properties are consulted.
+A context variable's value can be defined in terms of other context variables.
+Context variables are useful for extracting environment specific information from configuration
for instance path stems
+or port numbers.
+## Lifecycle
+`ConfiguredObjects` have a lifecycle.
+A `ConfiguredObject` is created exactly once by a call its parent's `#createChild()` method.
+This brings the object into existence.  It goes through a number of phases during creation
+ * resolution (where the attribute values are resolved and assigned to the object)
+ * creation validation (ensuring business rules are adhered to)
+ * registration with parents
+ * implementation specific creation (`#onCreate`)
+ * implementation specific opening (`#onOpen`)
+When the `Broker` is restarted objects that exist in the configuration store are said to
be recovered.
+During recovery, they follow the opening (`ConfiguredObject#open`)
+ * resolution (where the attribute values are resolved and assigned to the object)
+ * validation (ensuring business rules are adhered to)
+ * implementation specific opening (#onOpen)
+Some `ConfiguredObjects` support starting (`ConfiguredObject#start()`) and stopping (`ConfiguredObject#stop()`)
+ but this have not yet been extended to all objects.
+`ConfiguredObject#delete()` caused the object to be deleted.
+## AbstractConfiguredObject
+Most configured object implementations extend `AbstractConfiguredObject` (ACO). ACO provides
the mechanics
+behind the configured implementations: attributes, context variables, state and lifecycle,
+and a listener mechanism: `ConfigurationChangeListener`.
+## Threading
+The threading model used by the model must be understood before changes can be made safely.
+The `Broker` and `VirtualHost` `ConfiguredObject` instances have a task executor backed by
single configuration thread.
+Whenever the a configuration object needs to be changed, that change MUST be made by the
nearest ancestor's
+configuration thread.  This approach ensures avoids the need to employ locking.  Any thread
is allowed to observe
+ the state of a `ConfiguredObject` at any time.  For this reasons, changes must be published
safely, so they can be
+read consistently by the observing threads.
+The implementations of the mutating methods (`#setAttributes()`, `#start()`, #`stop()`, etc)
+`AbstractConfiguredObject` are already implemented to adhere to these rules.
+## Configuration Persistence
+`ConfiguredObject` categories such as `SystemConfig` and `VirtualhostNode` take responsibility
for managing the storage
+of their children.  This is marked up in the model with the `@ManagedObject` annotation (`#managesChildren`).
+These objects utilise a `DurableConfigurationStore` to persist their durable children to
+`ConfigurationChangeListener` are used to trigger the update of the storage each time a `ConfiguredObject`
is changed.
 Review comment:
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:

> [Broker-J] Create a developer guide for Qpid Broker-J
> -----------------------------------------------------
>                 Key: QPID-8361
>                 URL: https://issues.apache.org/jira/browse/QPID-8361
>             Project: Qpid
>          Issue Type: Task
>          Components: Broker-J
>            Reporter: Alex Rudyy
>            Priority: Major
>             Fix For: qpid-java-broker-8.0.0
> The developer documentation is currently scattered over various Qpid confluence pages.
It could be challenging for people interested in contributing to the project to find that
documentation. A developer guide could be added to cover such aspects as
> * Environment Setup
> * Building project
> * Running tests
> * Releasing
> * Architecture overview
> The following wiki pages are good candidates for inclusion into a developer guide:
> [High Level Architecture|https://cwiki.apache.org/confluence/display/qpid/High+Level+Architecture]
> [How To Build Qpid Broker-J|https://cwiki.apache.org/confluence/display/qpid/How+To+Build+Qpid+Broker-J]
> [Releasing Qpid Broker-J|https://cwiki.apache.org/confluence/display/qpid/Releasing+Qpid+Broker-J]
> The wiki pages below might be included as well
> [Java Coding Standards|https://cwiki.apache.org/confluence/display/qpid/Java+Coding+Standards]
> [Qpid Java Run Scripts|https://cwiki.apache.org/confluence/display/qpid/Qpid+Java+Run+Scripts]
> The developer documentation should be easy to modify, maintain and preview. Thus, it
can be written in  markdown or [asciidoc|https://asciidoctor.org/docs/asciidoc-syntax-quick-reference/].
The latter is also supported on github. 
> Potentially, it can be published on Qpid  project site as part of release process.

This message was sent by Atlassian Jira

To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org

View raw message