The full source code is available to those who have purchased an Advanced CMarkup Developer License. This includes the CThread Class, CSock Class and the CBuffer Class.
Message13.zip 125k (exe only) release notes
This release of the firstobject Messaging Architecture provides a Windows TCP/IP asynchronous messaging framework in MFC and illustrates a business process in an animated multithreaded demonstration. You can try it out without any setup or configuration, just run the message program and type demo to see the demonstration.
|
|
The full source code is available to those who have purchased an Advanced CMarkup Developer License. This includes the CThread Class, CSock Class and the CBuffer Class. |
Messaging is used between processes that need to communicate information. For example, product supplier software communicates with a warehouse databank or an insurer system checks customers on an insurance claims data service. In situations involving remote applications like these, the systems usually use "queueing" to line up the messages while they are being processed. This is also known as asynchronous message queueing, and the messages are often referred to as transactions.
Asynchronous messaging is used between processes that are designed to communicate without immediate responses. Messages are processed by a receiving application in the order that they are received, and they are generated by the sending application without expectation of immediate response. The most popular form of asynchronous messaging is e-mail. When you send e-mail you do not require the other party to respond before you continue with other tasks.
Asynchronous messaging is nothing new, it is the basis for all of the robust systems that form the information infrastructure of businesses since computers were first used. The mainframe systems of these institutions are asynchronous by virtue of working with transaction files generated by one system and loaded into another system.
This transaction file architecture allows these systems to recover from catastrophic events such as when a group of computers goes down. Since the business communication activities are represented in the transactions rather than the memory state of computer programs, they can be backed up and reintroduced during the recovery process.
Another point of failure is in your transport mechanism. When your e-mail service or LAN is down, you might use diskette (also known as "sneaker net" because you carry it by foot) to deliver information in the meantime. Similarly, messaging architectures are designed in a way that allows for network outages and even transport work-arounds like sneaker net. Manufacturing and military systems often support multiple transport capabilities such as FTP, direct dial-up, and removable storage media so that no single transport failure can shut down business.
The firstobject XML Messaging project transmits messages over TCP/IP using a specified port. Each computer involved in the communication runs a "message node" which is a service that sends and receives messages. The project does not support transmitting over firewalls and proxy servers unless you can make a certain TCP/IP port available for your message nodes. Generally, firstobject XML Messaging is used within a LAN or across TCP/IP connections secured by the WAN (Wide Area Network) provider.
Many developers are interested in using the web for transport, but that is not fully supported in this project. Although you can use this Messaging Architecture over the internet, in practice the computers are often behind firewalls and/or using proxy servers and you will not be able to connect. Messaging systems like SOAP, REST, and Groove are able to converse across firewalls by taking advantage of the fact that HTTP, the web browsing protocol on port 80, is usually kept open. While other TCP/IP ports and protocols are blocked, HTTP is already enabled on many computers for browsing the internet. To implement message nodes to converse across firewalls you need to develop a message node Web service and use HTTP calls to transfer messages.
Whenever you implement messaging outside of your LAN or WAN, you must address wider issues of security. The firstobject XML Messaging Architecture does not currently support this.
In any messaging system, the message consists of address information and the payload. The address information is mainly the origin and destination of the message, but can also include routing times and relay data. The payload is the actual content of the message that needs to be delivered to the receiving application, such as the status of an order sent from a warehouse to a supplier. In the firstobject Messaging Architecture, the message includes the addressing and payload in one XML document.
<Message>
<Origin app="Seller6QF" loc="washington"/>
<Destination app="Buyer2FS" loc="washington"/>
<Payload>
<Buyer>Buyer2FS</Buyer>
<Seller>Seller6QF</Seller>
<Identifier>1</Identifier>
<Status>Requested</Status>
<Quantity>15</Quantity>
</Payload>
</Message>
The message node manipulates the Origin and Destination, and may attach additional routing information, while the application focuses on the Payload content. So the message node stays outside of the Payload element and the application stays inside of the Payload element. However, in practice it can be useful for the application to be able to look at the address information, and for the message node to expose and monitor the payload. As a common format, XML makes this crossover simple.
In messaging platforms like Microsoft Message Queuing (also known as part of COM+ or .NET), you have to buy into an entire infrastructure including the database and transaction controller. When a platform supports guaranteed delivery, it might not support aborting or redirecting messages. Messaging services are never a "one size fits all" solution because messaging design is very difficult to modularize and isolate as a service. The firstobject XML Messaging solution is easy to integrate with your project because it is a small and light source code framework that you can modify and develop.
The message.exe program starts a message node and brings up the console dialog for controlling the message node, as shown in the illustration below. The name of the message node (e.g. "washington") is displayed at the top. Use the command entry box to enter message node commands (e.g. demo). The console has several commands other than demo. Use ? to see a list of commands.
The demo dialogs are spawned in separate threads using CDlgThread so that you can continue typing in the console dialog independently of those other dialogs. If you close the console all the other dialogs and the message node will shutdown too.
The ping command allows you to double check that you have a functioning TCP/IP connection to another computer at a certain name or address. As in the CSock class, the address can be an ip address 206.83.84.176, the name of the computer on the LAN such as ComputerA, or the fully qualified domain name such as firstobject.com.
You can also stop dialogs with the stop command (stop * stops all dialogs, or you can specify a particular dialog using the case sensitive name you see in the output after "Started", e.g. stop BuyerA56).
The animated demonstration illustrates messaging principles in a Buyer Seller supply chain. To see it, simply run message.exe and type demo in the command edit box, and the Buyer and Seller dialogs ("apps") appear and begin talking to each other.
The Buyer and Seller apps represent two applications in a simple supply chain. They illustrate the modelling of business messaging processes and the potential of performing business transactions electronically.
Both of the partners in this business collaboration have an inventory of n items shown by the large number in the dialog. As the Buyer's items are used up, the Buyer application negotiates additional shipments of items from a Seller application. Meanwhile, the Seller replenishes/manufactures items so that it can fulfill orders from Buyers.
The different stages in the process are represented by the following status values:
When the Buyer's Item count is at or below the re-order threshhold, it sends a message with the status "Requested" indicating a quantity of items. The Seller responds with either a "Back Ordered" or "In Stock" message depending on whether it has enough items to fill the order. If it sends an "In Stock" message, it obligates that number of items and does not make them available to other Buyers unless the order is declined.
When the Buyer receives an "In Stock" message it sends a "Confirm" message to indicate that the deal has been made and it will await the shipment. The Seller replies with a "Shipped" message once the items have successfully left its warehouse. Typically this would be automated with a barcode reader as the shipment is loaded for transport.
Finally, the Buyer notifies the Seller with a "Shipment Arrived" message when the items are received. Again, this would typically be automated with a barcode reader once the shipment is unpacked and checked.
When there are two Sellers, the Buyer sends the request to both of them and waits for the first Seller to respond with an "In Stock" message. The Buyer sends that Seller a "Confirm" message and it sends a "Decline" message to the other Seller whether he receives a "Back Ordered" message or an "In Stock" message from that other Seller.
In the demonstration, the Node Monitor is also displayed and the following illustration is a companion to the above Buyer Seller illustration:
This dialog gives some insight into what is happening with the threads and the messages. The list box at the top shows the current threads. The message node utilizes a listener thread and one send thread for every destination location. They are listed together with the number of messages they've sent (or received in the case of the listener). The XML messages as well as status and error messages scroll by in the log window. It only keeps 58K of text at a time, removing the top as it adds to the bottom.
The thread list helps to explain what is happening when the message node is unable to connect to another message node. In the following illustration, it is attempting to connect to the miami destination:
Meanwhile, communication continues between apps located on toronto. In the second illustration, the miami send thread is idling between attempts and indicates the number of attempts it has made so far (it allows 10 seconds between attempts).
As you can imagine, when you have quite a few message nodes involved, the Node Monitor can be very helpful to learn what is going on.
You can see the flexibility of the Buyer and Seller apps and the firstobject Messaging Architecture by adding additional Buyers and Sellers in any combination. You can start with the basic combinations described below on one Computer and then you can also locate these Buyers and Sellers on different computers too as described later.
2 Sellers and 1 Buyer on one computer has been made easy; just type demo2 in the command edit box. When the Buyer is initialized with two suppliers, it will request items from both of them and then confirm the order with the first Seller that can supply it. You can also create this scenario by starting the two Sellers with the seller command and then starting a Buyer by typing buyer SellerZ98;SellerZ99 where the Seller names are the (case sensitive) names of the Sellers you just started.
2 Buyers and 1 Seller involves starting each app individually. Type seller in the command edit box. Then type buyer SellerZ99 where SellerZ99 is the (case sensitive) name of the Seller you just started. Type the same thing again to start another Buyer with the same Seller's name. Each Buyer is initialized with one Seller and they will both request items from that Seller. Notice that with a lack of items, the Seller may not seem judicious in sharing its items with the two Buyers! If you increase the Seller's item count so that it has plenty for both Buyers, then it will supply them both. This is a matter of business logic.
N Buyers and N Sellers involves starting each app individually in any combination you like. First start your Sellers by typing seller in the command edit box once for each Seller. Then type buyer SellerZ97;SellerZ98;SellerZ99 with any specified Seller(s). For example, one Buyer can point to 3 Sellers, another to 1 different Seller, and a third to all 4 Sellers.
It is recommended that you try this program on two computers and configure the connection the way it will be for your own messaging system. That will tell you whether or not this messaging implementation will work over the relevant type of connection.
Each computer involved in the messaging has a "message node." When you run demonstrations you'll notice that the message node is automatically named after the computer you are using at the time.
To try a demo on two computers, start message.exe on both of them. Look at the node names of both computers; we'll call them Computer A and Computer B here. To make sure they can see each other, see the section below on Checking The Connection. Follow these 3 steps to demonstate messaging between the two computers.
The Buyer and Seller applications do not need to be aware of the node location of the other application; they behave the same whether the other application is local or remote. Since they are designed to communicate asynchronously they do not depend on immediate responses.
|
Try unplugging a network cable in the middle of the Buyer Seller conversation! |
When a computer is temporarily disconnected, you will see the error message displayed in the node monitor, and messaging will resume shortly after it is reconnected. While there is no connection, messages simply wait in the "outbox." This release of firstobject XML Messaging does not have an Outbox application for aborting or re-routing messages that are waiting in the outbox.
Start message.exe on the two computers. Look at the node names of both computers; we'll call them Computer A and Computer B here. In the Computer A console dialog you can type ping ComputerB where ComputerB is the (case sensitive) node name of Computer B.
If it is unable to resolve the address, try pinging the fully qualified domain name such as ComputerB.firstobject.com, or the IP address such as 210.10.10.1. If one of these work, then you will have to change to the message node naming convention that works in your configuration. A message node name must be the address used by all other nodes to contact the node. If the node name needs to be the TCP/IP address or fully qualified domain name, change the node name using the setnode command on each computer.
If the ping results in a timeout then the connection might be broken. Make sure that both computers are connected to the network. Sometimes you will intentionally disconnect computers to test your messaging solution and the ping command is a way of checking the interruption of service. If there is a timeout despite both computers being connected to the network, there is probably a TCP/IP or Windows sockets configuration problem, and you may need the help of a network administrator.
In the Messaging Architecture, app naming is an important issue because every app that you install should have a unique name across the community of message nodes. In the demonstration, the names of the Buyer and Seller apps are automatically generated to be unique to a computer. In the rare case that two of them were given the same name on two computers, then it would depend on the registered locations where messages would be sent.
If you developed a system that allowed different users to install and name apps, you would want to implement a name registration app available at a certain known message node. This would provide centralized control over the naming of apps, and could also store location information for distributed forwarding.
After some experimentation it becomes evident that a complete business process of this Buyer Seller demonstration would require more information, more exchanges, and exception handling. Although it is only an illustration unattached to any real business project, here are some example ideas:
"In Stock" message from the Seller who has obligated those items, the Seller needs to send status requests and cancel the order after a certain time period."In Stock" and "Confirm" messages.Developing business logic is the most sensitive part of software development because it is very evident to the end users. It is derived from real life scenarios ("use cases") and it not only encompasses the automated logic discussed above, but also the override logic for unusual circumstances. A lot of time and consideration needs to be applied to developing the business logic, and the messaging solution must conform to its needs. You will also need to implement measures for backup and recovery, and alternative transport options.