Guest Opinion
Teach Your Apps to Trust
A service-oriented architecture (SOA) is the basis for creating applications that trust each other to perform their tasks.
Teach Your Apps to Trust
by A. Nicklas Malik
Posted April 26, 2004
|
A. Nicklas Malik |
Using a service-oriented architecture (SOA) helps developers rediscover a key feature of paper-based office processes: trust. SOAs combine a collection of services with some means of coordinating activities between them. Paper-based systems coordinate using trust.
For example, I gave an insurance form to my department secretary recently. She put the form in an envelope and sent it to HR. Our secretary doesn't know what they will do with it. She is a "component" in an elegant design. The design is independently scalable, completely reliable, and proven over time.
Most of our computer systems don't work this way. We've been conditioned to believe that computer systems trump paperwork. Of course, computer systems can reduce human error and speed up processes dramatically. However, we often lose the elegance that comes from trust. My secretary trusts the mail folks to deliver the insurance form to the right people, and she trusts those people to take it from there.
Until recently, we haven't developed or used many trust-based application patterns. When our Web form collects data from a user, we're supposed to store each field in database tables. We've always believed we had to "own" the entire process—to be responsible for every step. Well, it's time to break that habit.
You can do so with a pattern I call the integrated application pattern (IAP). The concept of the IAP is to use loosely coupled components, held together with Web services, or message queues, or enterprise application integration (EAI) tools such as BizTalk Server. In fact, this pattern is designed with EAI message broker tools in mind. IAP doesn't require you to start with an EAI tool, but adapts readily to the addition of an EAI tool at a later time.
The IAP is characterized by components that send "documents" to each other. A document is a set of information that has a meaning to the business. For example, a document can be a purchase order or a request for a list of valid inventory items. Documents and their responses are complete. They are denormalized. They are useful, all by themselves.
So you write components, not applications. Input components validate and send entire documents to other processes asynchronously. Downstream error messages don't come back. You trust other components to do their job, reliably and without complaint.
Now consider this: When my secretary sends my insurance form to the HR department, she doesn't send it along with a note telling them what to do with it. That's not her job. She sends the document, with no control information. The HR department is responsible for the rest. No one calls her back if the filing cabinet in the HR department is locked, or if someone has taken a vacation.
The IAP has you send the business document without asking anyone to save it, or archive it, or throw it away. You don't control it; you trust the subscribers to do that.
Your application doesn't send the document to a hard-wired component. You use a service to find the destination. Look in the UDDI index for a service that manages subscriptions. Get the list of subscribers for your particular document, and publish to each of them. One of the subscribers should be a service that's responsible for holding the documents in archive. Then if a service drops its subscription and picks it up later, it can ask for all the documents that flew by in the meantime. EAI middleware does all this for you, by the way.
With IAP, everything is done using a service. Suppose you want to get a copy of the document already filled out. Simply look for a service that produces this document filled with data. Do not expect to find a "persistence" service that looks up data from a database. You're seeking the document, not the functionality behind it.
The IAP runs in an SOA. You might find this surprising, but SOA is not just about Web services, though Web services can enable it. It's not about scalability, reliability, or testability, although SOA apps score better than other architectures in all these areas. SOA is about creating a framework where one application can trust another one to do the "right" thing.
The IAP delivers the real benefits of SOA. Your apps are scalable. Your system is reliable. You can test each service independently. More importantly, you can integrate two systems together easily. All the work is done by subscribing to documents. You don't need to tell either the sending application or the receiving application that the other one exists, or what it does, or how it's hosted.
Trust is a powerful thing.
About the Author
A. Nicklas Malik is a solutions architect for Sierra Systems Group, a consulting firm based in Vancouver, British Columbia. He works to provide message-oriented middleware and service-oriented architecture to state and local governments. Reach him at [email protected].