Symbolic Logic:Programming:Messaging Systems
In communication between computer systems messages need to be exchanged. Often the message will require some transformation to change it from the structure or format produced by the source to the structure or format used by the destination.
Messages need to be routed from the source to the destination. Sometimes the same message may be required at more than one destination (in different formats).
A Messaging System links messages from sources to destination, performing any conversion and routing required.
Often the codes used to identify the same real world objects will be different between the source and the destination. An external reference is the code used to identify an object in another system.
Contents |
[edit] History
Object Oriented programming unified code into one stucture, the class. However a message is data without functionality. It does not fit well into the Object Oriented paradigm.
The OO approach to communicate between systems is to use an interface. Interfaces allow function calls to be made between components, knowing only the interfaces. This may extended to allow communication between separate programs over a network using,
However this architecture leads to complex interactions between the systems. Individual calls may be made to set and get attributes. Because each call must wait for confirmation from the other system the approach is too slow.
Another approach would be to clone the object and send it to the other system. However in this approach the functionality must be sent along with the object. This also is not a good solution.
The problem is that function calls are too low level. When we request an action on another system we wish to send all the information in one message. The message contains all the data required to perform the action. Messaging systems implement this approach.
There is an underlying problem with programming languages that is highlighted by this problem. Interactions between components and classes are too complex.
A function call with more than 3 parameters is confusing. In a function call the matching of actual parameter to parameter is by position. For example for a function whose signature is,
Address MakeAddress( long unitNumber , long streetNumber , String streetName , String streetType , String suburb , long postCode , String state , String country );
a call to make address then looks like,
Address myAddress = MakeAddress( 88 , 75 , "Elm Street" , "Street" , "Brunswick" , 3056 , "VIC" , "AUSTRALIA" );
With so many parameters it is difficult to verify that each actual parameter value matches with the correct formal parameter. This leads us to write code like,
Address myAddress = new Address(); myAddress.SetUnitNumber(88); myAddress.SetStreetNumber(75); myAddress.SetStreetName("Elm Street"); myAddress.SetStreetType("Street"); myAddress.SetSuburb("Brunswick"); myAddress.SetPostCode(3056); myAddress.SetState("VIC"); myAddress.SetCountry("AUSTRALIA");
but this distorts the code. The intent was to create an Address in one action at one time. The above code divides that action up into pieces, with a complex interaction over time. Each Set method may have other side effects and set other attributes. It is no longer clear exactly what the above code will do.
Language extensions are needed that allow for the support of messages as an integral part of the language, so that the above call may be written,
Address myAddress =
MakeAddress(
UnitNumber(88),
StreetNumber(75),
StreetName("Elm Street"),
StreetType("Street"),
Suburb("Brunswick"),
PostCode(3056),
State("VIC"),
Country("AUSTRALIA")
);
Such code could be written in java / C++, if UnitNumber, StreetNumber, ... were classes with appropriate constructors. But that is not the intent here. The intent here is to pass the data to MakeAddress as a single structured message, so that an Address may be constructed from the data.
[edit] Defining a Message
In constructing a message we would like compile time checking that the message is correct. In addition we would like to construct a message within the language for use in calling functions internally. The same problem exists when communicating with a system as with communicating to an external system. We would like to send all the data in one function call.
[edit] The Role of XML
The syntax of XML does not fit in with a language liken Java or C++. XML also has some nasty features.
- The DTD is overly complicated.
- There is too many ways of doing the same thing.
- Attribute or data.
- It is not easy to define an unordered collection of elements (where there is one of each element).
- Because each element has its own tag, in many situations it is unnecessary and a nuisance to define an order for the elements.
[edit] Language Features for Constructing Messages
Need to be able to define a message as part of the language. Something like,
x = Person (
Name (
GivenName ("Joe"),
MiddleName ("John"),
Surname ("Blogs")
),
Address (
Unit (95),
StreetNumber (43)
StreetName ("River"),
StreetType ("Road"),
Suburb ("GEORGETOWN"),
PostCode (4005),
State ("Tasmania"),
Country ("AUSTRALIA")
)
);
This type of structure is similar to an Algebraic Data Type.
This needs to be an integrated part of the language, but not to be a constructor. This is just structured data from which an object may be constructed later.
[edit] Data Type Definition
We need to be able to define a data type,
datatype PersonMessage =
Person (
Name (
GivenName ( String ) &
MiddleName ( String ) &
Surname ( String )
),
Address (
Unit ( long ) &
StreetNumber ( long ) &
StreetName ( String ) &
StreetType ( String ) &
Suburb ( String ) &
PostCode ( long ) &
State ( String ) &
Country ( String )
)
);
The & symbol means that each element only occurs once. The elements may be in any order.
[edit] Syntax
| Feature | BNF |
|---|---|
| Data Type Definition | <data type def> -> datatype <name path> = <element> ; |
| Tagged Element |
<element> -> <tag name path> ( <element list> ) |
| One of each element in any order | <element> -> <element> & <element> |
| Any one of these elements | <element> -> <element> | <element> |
| Elements must be in order given, | <element> -> <element> , <element> |
| Element List |
<element list> -> <element> <element list> -> <element> <element list> |
| Simple Type | <simple type> -> bool  long double String
|
[edit] Accessing the structure
Need to be able to access parts of the structure. E.g.
streetName = x.Person.Address.StreetName;
This is like an xml query path.
[edit] Conversion to XML and other Formats
We need to be able to convert a data type to XML or any other format. This means that we need to be able to traverse the message and access,
- Values
- Tag names
???? How to allow this in the language ????
[edit] Features
[edit] Message Formatting
There are many formats used for the transfer of messages. Many are propriety, or legacy. In modern times XML is the message format of preference.
Whatever the message format is, middle-ware messaging systems can convert it to another format. The source system produces the message in the format it wants and the destination system receives the message in the format that it can read.
[edit] Message Routing
The messaging system may be configured to send data to one or more destinations. A Routing Script may be used to choose where individual messages are sent.
[edit] Message Mapping
A message mapping script uses information from an input message to construct an output message. The format of the message is not changed.
[edit] Message header
A message header records information about the message. It is used in routing the message to the correct destination and in the interpretation of the message.
| Field | Description |
|---|---|
| Source System | The system that produced the message. |
| Destination System | The system to which the message is to be sent. |
| Message Type | Identifies the structure of the fields in the message. |
| Content Type | Identifies the source and purpose of the message. |
| Time Sent | The time the message was created and sent. |
[edit] Notes
- The messaging paradigm is a powerful paradigm in its own right.
- Most developers have trouble understanding inheritance, functional programming and logic programming.
- Most developers make a terrible mess using imperative programming languages.
The heart of the problem with Object Orientated programming is the lack of separation between classes. A class that inherits or interacts with another class needs to know too much about it. So unless the classes are written by the same person the class structure is hard to understand.
Developers have trouble with functional programming because it is not obvious how to deal with interaction with the environment, and with change over time.
Developers have trouble with logic programming because it appears that the values are produced as a side effect of the constraints.
A typical developer wants to break the problem down into a series of high level actions. Each action has a single purpose. The focus is on implementing only one action at a time.
Like it or not people do not seem to think about problems in terms of logic. People think about a series of high level actions that do things. Mathematics and logic dont seem to be compatible with their view of the world.
The mathematical approach is to write down the rules for how the system behaves. The rules are written in a way that is explicit and general. This allows a small number of rules to describe a complex interaction.
People dont think in terms of rules. They think in terms of high level actions, and what to do in particular situations. So the mathematical rules seem foreign to them because they are too high level and unverifiable.
From a Symbolic Logic point of view a message is a function call where are all the parameters are input except for the receiver of the message. Such a function call has no effect on the caller.
