POST OF THE DAY
New Paradigm Investing
The Service Oriented Architecture Game

Format for Printing

Format for printing

Request Reprints

Reuse/Reprint

By tomheadrick
April 23, 2003

Posts selected for this feature rarely stand alone. They are usually a part of an ongoing thread, and are out of context when presented here. The material should be read in that light. How are these posts selected? Click here to find out and nominate a post yourself!

The other day I went to a Wal-Mart. When I left the house and got in my car and hit the road the road didn't object or deny me access to the road because I used a standard protocol (HTTP) for accessing the road, and it didn't care that I was going to Wal-Mart or where I was going for that matter nor did Wal-Mart care because Wal-Mart uses the same protocol for accessing the store front. Wal-Mart (the application) is free to implement design, functionality, business process, security, etc, because the transport layer is abstracted from the application, the store. Nothing more in that than to illustrate what a successful architecture and implementation that is between HTML and HTTP.

As I entered the store and browsed through the aisles looking for items of interest I couldn't help but notice that the architecture of this Wal-Mart store uses the same fundamental components as most other stores, Wal-Mart or Sears. Brick, steel and various other similar materials bound together and arranged to support large volumes of items and persons, and these components were implemented according to each different stores needs and use, but they were re-useable code (foundation, walls, roof, doors, floors, HVAC) that saved countless dollars on development costs and implementation at other locations because these components were abstracted from the outward-facing utility of the store; presenting me with goods and services that can be changed in countless ways and at any time with little or no regard to the architecture of the store. Wow, I thought, component architecture with re-useable code because the fundamental building blocks are abstracted from the application. Who'd a thunk it!

I even caught a glimpse of the sticker on the front door that read, "This store is armed with Super Galactic Security." I saw one of the Super Galactic employees in the aisle and asked her, "Do you also provide the security for credit card transactions at the checkout counter and she replied, "No, I think the store most likely uses another company, but I do know that we don't provide that service, just infrastructure security, you know, the store � its' infrastructure and access to the store. We're abstracted from the implementation of the application and its business process, logic and content that is presented to the shopper." "Content!?" I replied somewhat puzzled. She said, "Yes. Content. These individual goods you see stacked on the shelves and hanging from the racks don't have security written into the goods. We police the entire store and the contents from would-be thieves. This saves the suppliers of the goods a lot of money in product development cost because they no longer have to write security code into the product. At most they may provide additional measures bound in the packaging, like CDs, but those devices are standard, low-cost commodity items and they integrate with our security infrastructure at the checkout aisle and the doors. In the end this provides for much lower cost to the shopper and more flexibility in product design for the provider." Ah, now I see, this way the content provider companies and Wal-Mart don't have to change implementation methods every time it changes the presentation of the products because the cameras are mounted overhead and the alarms are built into the doors -the infrastructure- or even if they change the transaction process, that probably saves a lot of time and money when they decide to change products lines and content presentation not to have to re-write all that code for each occasion.

Well, I think I've found a few things I like perhaps I'll head for the checkout. After waiting for a few others ahead of me and observing the multiple forms of payment methods that they had used, one customer used a Capital One Visa and another customer used a Bank of America Visa and when I got to the counter I asked the cashier if they accepted my Comerica Visa and he said, "Yes. Of Course!" I retorted, "But it's different than the other two Visa cards that you just accepted payment from on the same swipe machine, how is that possible?" The cashier replied, "The machine doesn't care and Visa doesn't care what the brand of the card is because the Visa transaction process is abstracted from brand of card you present it with." I see, this must save Visa and various brands of cards a lot time and money in re-writing code because the transaction process doesn't care how the presentation is implemented because they're abstracted from one another. Not only that, but Visa doesn't even care what the business application or type of store it is being used in. Pretty nifty.

"Say, I noticed in the checkout aisle next to us that the cashier is having a problem ringing up one of the items the customer is trying to purchase. He called the store manager and apparently asked for a price check on the item." "Yep! Sure looks that way. But did you notice that he's able to continue ringing up other items until the store manager gets back to him?" "Yes, I did. How's that possible." "It's called loosely coupled, asynchronous communication." "Huh?" "Asynchronous because the cashier can't or doesn't have to be held up from continuing the checkout process because he has to wait for the store manager to get back to him with an answer and loosely coupled because the checkout and transaction process is not broken, the problem is the item. They are abstracted from one another.

These and many others are some of the benefits of the Service Oriented Architecture, a run-time framework that allows developers to drop, drag and re-use these abstracted services; transaction process, logic, security at multiple layers, integration, asynchronous, loosely coupled and coarse grained applications. Still today, in most client applications that run on servers (the client/sever model of the late 80s and 90s) these types of issues have been traditionally dealt with at the application level. This is what drives up a good deal of the cost of application development, change in implementation, integration, scale, flexibility, reliability and security and host of others related to content/public contract exchange, though the latter are being relegated to XML as the Internet has come to the forefront of application development.

If you would have liked to have had the opportunity to play the Client/Server Gorilla Game starting in about 1990 and reaped the rewards of Siebel and Oracle and Sun and others, the Service Oriented Architecture Game offers the same potential. Personally, I think a company many people have not taken notice of is Progress Software and its operating unit Sonic Software. It s the first to get a product to market called an Enterprise Service Bus, ESB. It is referred to as the messaging backbone at the core. It is significant in that it offers many-to-many integration as opposed to point solutions, or one-to-one, and even more robust than the hub and spoke method, one-to-many as implemented by BEAS and IBM and a host of others And, they provide greater scale and flexibility through this architecture at a cheaper price. As well, I don't think many realize the profound significance the role the ESB will continue to play as a highly scalable message backbone for the Internet and its many trillions upon trillions of messages that will be careening across the Internet as we move further out all the time. Sonic will also be releasing a new updated version of Sonic Stylus Studio, a run-time framework that leverages the ESB and their own J2EE standards-based application server. The Sonic business unit will come to dwarf the Progress Software business unit in about another year.

Tom


Become a Complete Fool
Join the best community on the web! Becoming a full member of the Fool Community is easy, takes just a minute, and is very inexpensive.