| Summary Discusses a simple SOA that can be a starting point for any organization exploring service oriented architecture. Introduction SOA or Service Oriented Architecture has been touted as the "new" evolution for integrated software applications. There are several messaging patterns touted to satisfy the end means. Several articles mention various possibilities and they are more often distributed application architecture theory. They have their purpose and are well meaning in intent. But they do not explain a simple mechanism to implement or a simple steps to adopt from which other thoughts and ideas can evolve over the time. Therefore discussions or planning for adopting SOA as a mechanism shifts to the vocabulary of the user and the article or book that propounded the concept. The problem before any task force assigned to implement SOA would be the starting point. There is no study on which one implementation could be better than the other, since SOA is only a concept applicable in different formats. Some task forces start the initial design from a message pattern. I have seen a similar plan and noticed all the patterns seem to solve the problem and hence complicating the task further. Moreover a pattern should not be used as a starting point in the planning process. The reason that this is not a good idea is because pattern should evolve from the problem being solved. Another plan quite often seen in most teams is to start small by trying to create a framework for a small problem and then try to adopt it further upstream with higher requirements. This intention is good but it's also important to have a larger picture in mind. A better analogy of this would be to build a car starting with the wheels if the larger picture of car is not present to the team then each member of the team could be defining different steps and eventually it could become a truck though not the intended product. Realizing this dream of building a simple system with the real intent in mind was the grounds for evolution of a "simple" SOA framework. This article presents a simple SOA framework and hence a team could make headway in the direction of the process to be adopted.
The Process The basic premise of an SOA system is to decouple the applications from each other and hence the applications are autonomous in their own terms. Therefore when each of these different applications in an organization needs to integrate they would have to communicate their needs by a standard process. This communication is done via messages sent across as defined by the business rules. These messages are XML message though need not be necessarily since some systems could send non - XML messages. For the case of a simple SOA we would consider XML messages since it's more or less the de-facto form of communication today. These messages have to be sent across and this is where the plumbing for the task arises. The task therefore is to send a simple XML message across and this would have to be received by the application. Defining the framework (Figure 1) would mean that these messages would have to pass through a message channel. These messages are then routed to their appropriate destination. Agents are available for each application the only task the agents perform would be to publish the user input to the Messaging channel and also forward the received message to the application. Thereby the agents facilitate connectivity transparency. 
Figure 1: Simple SOA Framework
The agents are representatives of each of the application and they could publish the message to a standard queue called publishing queue. All the agents are left with the task of passing the message to this publishing queue. The messaging channel would be responsible for handling several queues. Additionally they would be responsible for the reliability of the message and promptness of service. They would have to ensure that the message received is atomic. More on this later since our attempt is to define a simple SOA using XML as the payload of our message. Later we can define the message framework. The message should be also promptly transferred to the router. The messages in the messaging channel can be transformed into another format. This transformation could adhere to a specific schema based on the business rules. Moreover it's often easy for the agents to send raw XML and these are then transformed into appropriate SOAP messages. The messages could be XML messages that are serialized by binary formatting and then pushed to the queue and hence the channel is responsible for reformatting the message. More often it could be less rigid processing structure for the channel if the agent sends the message as SOAP a message which gives the benefit of using standard process of reading the messages. As an example the agent could be a Web Service that sends the messages as SOAP message which could then be pushed to the publishing queue and the message channel is left with the responsibility of only reading the message and checking for its validity as per any defined schema based on the business rule. Some systems could have a Collection Agent as part of the framework. This agent looks at the input message and picks the required information and reformats it as needed and then sends this information to another queue which is then read by the channel. This could be called an information queue. Since the channel is built to read from multiple queues if needed the collection agent can be easily incorporated. But adding a collection agent is a complex process and could be avoided in our simple scenario. The message router is responsible for routing the message to the appropriate agents. This would mean that the message router would be provided with the information needed to identify the different messages as more receiving agents are added to the system. The message router is built independent of the message and hence it would need to parse the message and apply some predefined knowledge and then route the message to the appropriate agent. The router could parse the message for the intended destination. It could also use another of W3C recommendation XPath which could be used to parse for the information it needs. The router could have a set of XPath expressions (Figure 2) which can be evaluated against the messages and if the expression is satisfied then the router would identify the destination agents that have subscribed for this message. This XPath expression could be part of predefined set of business rules. This is a type of Content Based routing. 
Figure 2: XPath expression and the destination can be a 1...n relationship or it can be a 1...1 relationship depending on the business rules.
Use of XML and XPath XML today is widely used by most applications and is today the preferred mode of communication. We will not delve into details of XML since its well understood and widely used. XPath has been a W3C recommendation but it's not well understood. Therefore a brief explanation is provided. XML document is a hierarchical tree of elements. It's acyclic and hence starting at any node on the tree to any other node in the tree there is only one path to it. XPath provides the necessary syntax to select a subset of the nodes in the tree based on the path to those nodes. Expressions are the building blocks of XPath. The following examples, will give an idea of the syntax used by XPath expressions: If we had an XML which had the root element as Customer and child elements as Orders then we could have some of the following expressions. Select all elements of type Orders that are children of the Customer: / Customer / Orders
Select all elements of type Orders that appear anywhere in the XML document: //Orders
Select the first element of type Orders that is a child of the Customers: /Customer/Orders[1]
Select all elements of type Customer that have an attribute named Location: //Orders[@Location]
Select all elements of type Customer that have an attribute named Location with the value 'USA': //Customer[@Location='USA']
Select all elements the name of which starts with the letter 'U': //*[starts-with(name(),'U')]
Therefore several useful expressions can be created with XPath and since it's a standard it can easily and widely understood. Moreover since the messages use XML it's better to use XPath.
Simple Scenario Studying the framework we can apply a simple scenario where we have a message that needs to be sent from application X to application Y. Application X has the publishing agent which is a web service. A message is sent by application X to the web service. The web service now transfers this message to the publishing queue. The Channel now reads the raw XML from the queue. It checks if its well formed XML and then transfers this message to the router. The Channel can be implemented as windows service and monitor the publishing queue. The Router can be a simple assembly that could be used by the channel. The router when it receives the message looks at its cache of regular expressions. These XPath regular expressions are mapped to some specific endpoints. If the message evaluates against any of the regular expression then its destination is read and the message is now sent to the agent of application Y through dynamic invocation of the assembly or even through generic web proxies. Application Y now has an XML message it could parse and perform necessary action on it. The agent of Application Y can also parse and write it to a database if needed. The cache can be implemented as a table in the database or a simple file. Looking at the scenario there are several different options within this framework. It could be a SOAP message passed completely through the framework. We could have agents that need not be web service and could be any other type of application. These techniques can be adopted with the latest WSE 2.0 available which are transport protocol agnostic. Hence SOAP message can be sent not only over HTTP but also over TCP.
Patterns Evolved In defining the Simple SOA we observe three messaging patterns. Point - to - Point. 
Figure 3: Point - to - Point
This pattern is when the message is sent from several applications to a specific application. This appears in the Simple SOA when multiple agents send their messages to the publishing queue and then this message is then routed to a single destination. Publish - Subscribe. 
Figure 4: Publish - Subscribe
This pattern is when several applications subscribe for the same message. This appears in the simple SOA when an agent sends a message to the queue and this message is routed to all the destinations that have their expression validated. Content Based Routing. Content based routing occurs when each of the messages is validated against the expression defined and then the destinations that have this expression matched being sent the message. We could also extend this to a Request - Response style pattern. The message is sent by the agent. The message is then evaluated against the expression and the sent to the specific destination. The destination agent then process this message and then sends the response back through the message queue and this message is evaluated and passed back to the original agent. The important design is not the path but the message itself. Since the message would have to carry the necessary information to identify it. This leads to the design of the message for the simple SOA.
The Message Messages can be sent in different formats. The chosen basic format is an XML message. Considering a simple XML message would be the first best pass through the simple SOA framework. When the router receives this message it evaluates the XPath expressions against the XML message. If it satisfies the expression then the associated destination is read from the cache and the message is forwarded to the destination. Alternate scenario: In this case we would like to have a SOAP message passed to the destination and not the raw XML since we could take advantage of SOAP format.
This would mean that if the agent is web service feeding the message queue, the data in the message queue would be a simple raw XML since the XML string written back to the queue is deserialized and is no more the SOAP message. Moreover we have to send an XML message as a string through the service agent and thus restricted to sending a pre-processed xml string. This would deny the flexibility for the users in creating the agent based on business constraints. Therefore to add the flexibility we could let the user model the agent based on their business need. This would mean the data passed would be not in the format of XML string but simply values. For example in passing the Customer ID and Name, formerly they would have to create by concatenating the values as XML string. But if the design is based on business rules they would invoke the web service (agent) and pass in the value of Customer ID and name to a method call defined in the web service. This would mean how to obtain the XML message in the message queue for the channel to process since the message that the ASP.NET web service provides as return value would be the deserialized actual values. The message that is actually needed in the queue is the actual SOAP message that we need. To obtain this we would have to build a SOAP extension which is a filter that would read the SOAP from the stream after its serialized and then pass this SOAP message to the message queue. Now we have the message that we need and this can be processed by the channel. There are several advantages in using the SOAP message and avoiding raw XML. SOAP is a standard format and can be adopted across technologies. Moreover a raw XML would mean that we are responsible for maintaining the schema and structure and as the messages become complicated the schema would be difficult to maintain. This brings us back to the topic of the message being Atomic. Since the message is passed as a SOAP message the message is complete and can be verified for validity. The SOAP header can also carry an ID and hence if the message is repeated then the channel can ignore the message this would mean the message is idempotent.
Failed Messages Every message need not be successful. Identifying the failure of the message and analyzing the cause of the failure could be a means of iteratively stabilizing the framework. Appropriate corrections to the messaging framework can be done to rectify the problem. There could be several types of failure and we could examine some of the causes of the failure. Every failure is either a system failure or business rule failure. System failure is most often due to unavailability of the system. This is a high potential because of the disconnected systems as part of the framework. It could be if the receiving agent is not available. The messages would be dropped. The way to correct this problem would be to resend the message by adding it to another queue which could be periodically checked by a channel and rerouted. But this could add the load on the system if the agent is perpetually unavailable. Another way to solve this would be to notify the administrator and then force a resend and hence they system could be rectified in time. There are problems in resending the message. Agents should have a built in mechanism to check for duplicity. If several agents had subscribed to this message and if only a few of the destinations failed then resending to all the subscribed agents is wasted resources and load on the system. In order to avoid the complexity on the receiving agent the problem can be shifted to the router. The router keeps a list of destinations failed (Figure 5) for a specific message, identified by the id and hence when the message with same id arrives it resends these message only to the failed destinations. 
Figure 5: Message ID and Failed Destinations
Business failure could occur from the XPath expression being too generic and hence message sent to destinations that do not require the message. This would mean fine tuning of some of the XPath expressions. Therefore a better mechanism to handle such occurrences would be a better error handling mechanism in the receiving agents. They would also have to report these errors and identify the message that created the problem. This could be through the id of the message.
Conclusion The framework described for the simple SOA is a first step in defining the framework. Further extensions can be done to this framework such as specialized channels for handling various inputs. There can be an interface between the agents and channel which has the responsibility of handling and monitoring various message queues. This can also be extended for non-XML inputs and then transform it to XML as needed. Additionally XML to XML transform can be done by using XSLT in the Messaging Channel. There are so many possibilities of extension as needed to satisfy the business needs. This article examined a simple SOA which can be starting point for such expansions.
| 
