Parties Overview

Neuron ESB Topics and subscriptions are used to control the path of all messages between all systems, people and resources.  However, messages are published to topics by Parties, either hosted locally or remotely by other applications. Parties are essentially C# objects that can send or receive messages over the bus and can be created by referencing the Neuron.Esb.dll library.

Parties use subscriptions to control which Topics they can publish messages to, as well as determine what messages they are interested in receiving from the bus. Parties that send messages are known as publishers, and parties that receive messages are known as subscribers. A party could be both a publisher and a subscriber. Subscriptions can also be further defined by augmenting them with filters and Message Patterns

Parties are created within the Neuron ESB Explorer and are represented by a logical name, often referred to as the Party ID, Subscriber ID or Publisher ID. Because Parties control the interaction of messages to Topics, all Adapters, Client Connectors and Service Connectors MUST contain a configured Party. The configured Party will determine what messages are received by Adapters or Service Connectors, and where (what Topic) messages will be published to by Adapters and Client Connectors.

Parties have the following attributes which can be configured within the Neuron ESB Explorer UI:

• Security
• Subscriptions
• Instancing
• Logging
• Processes

Working with Messages

Messages are published to topics by Parties, either hosted locally or remotely by other applications. Messages are also submitted by and received from Neuron ESB Client Connectors, Service Connectors and Adapters through their use of embedded Parties.

A message is information that one Party sends to, or receives from the bus. A message contains both data, (the information that some other system, resource or person may be interested in), as well as metadata. Respectively, these are referred to as the payload and header (context) properties of the message. Both are defined as parts of a Neuron ESB Message.

The payload of a Neuron ESB Message can be one of several formats:

• Serializable .NET Object – The ability to pass .NET objects provides flexibility for developers who prefer use of objects over XML
• Binary data – The ability to pass binary data provides flexibility for developers who have to share content that is neither serializable nor XML.
• Text data – Any type of string data
• XML data – Any XML data. XSD schemas are not required to use XML as the payload

System header properties

The Neuron ESB Message has predefined system header properties. Their definitions and uses can be found in the API documentation.

• Action
• Binary
• BodyType
• Compressed
• CompressedBodySize
• CompressionFactor
• CustomProperties
• Created
• DestId
• Duplicate
• Event
• Expires
• FaultType
• Machine
• MessageId
• Part
• Parts
• Priority
• ReplyToMessageId
• ReplyToPartyId
• ReplyToSessionId
• Routing Slip
• Schema
• Semantic
• Sequence
• Serializer
• Session
• SID
• SourceId
• Topic
• TrackingSequence
• UncompressedBodySize
• Username

System failure header properties

In case of failure, the following properties are added to the header of the message and can be viewed in the Failed Messages report by selecting Activity ->Administration->Failed Messages from the navigation bar located on the left hand side of the Neuron ESB Explorer.

• Failure Type
• Failure Date
• Failure Detail

Custom header properties

The Neuron ESB Message also supports the addition of custom properties and values, allowing custom metadata can be added to any Neuron ESB Message before publication to the bus or during processing with a Process, Adapter, Service Connector or Client Connector. Custom properties are name/value pairs that can hold any string or XML value. 

Uses for Custom Properties

Some uses for custom properties include the following:

• Custom properties allow you to preserve some aspects of a message in the clear prior to encrypting its payload.
  For example, you might preserve an order’s delivery postal code in order to route the message to the nearest order fulfillment center.
• Custom properties allow adapter endpoints to capture or apply metadata.
  For example, the Websphere MQSeries adapter captures queue headers as custom properties, and can set queue headers from custom properties.
• Custom properties allow service endpoints to capture or apply SOAP headers.
  For example, a custom property can be used to add a custom SOAP header to an outgoing service message.
• Custom properties allow developers to have a “scratch pad” of their own metadata.
  For example, a developer may want to record some conclusions or rules output about the message in custom properties

Naming Conventions for Custom Properties

Custom message properties are named using the convention <prefix>.<name>. The <prefix> serves the same purpose as a namespace: it distinguishes sets of properties from each other. Whenever you store a custom message property, you should be sure to either use a pre-defined prefix or create one of your own. For example, if you needed to store some order information in a customer properties area, you might use the “order.” prefix and create properties such as “order.OrderId” or “order.Amount“.

Communication Patterns

Sometimes communication between applications, systems and resources require several messages or the support of various communication patterns. Messaging patterns exist at different levels of abstraction in SOA and various ones are available to use with Parties

• Direct – A single message can be sent directly to specific subscriber. This infers that the publisher has knowledge of the subscriber. Using this mode, the message will be sent to all instances of a specific subscriber.
• Request-reply – The publisher waits to receive a reply message from the subscriber. This is the typical service provider/service consumer pattern used with web service calls.
• Publish-susbcribe – Messaging usually involves more than just one subscriber: there can be one or more called publishers, and one or more subscribers. This is the pattern used internally in the ESB and typically used for one way messaging scenarios where the publisher does not have any knowledge of the subscriber and vice a versa.
• Itinerary Routing – A predefined list of Parties and Topics to route to, in a specific order. This is accomplished by defining a Routing Slip (defined in API documentation).