|
Comments
Did you read today's front page stories & breaking news?
SYS-CON.TV
|
XML Protocols Transactions Aplenty
Transactions Aplenty
By: JP Morgenthal
Jul. 31, 2002 12:00 AM
In the world of automation, the ambiguous can be a beautiful thing or it can be a nightmare. To those responsible for delivering a solution, ambiguity leads to missed expectations, higher costs for delivery, and delays in completion. To those providing solutions, ambiguity leads to opportunity. One of the most overused and ambiguous words in the IT industry today is transaction. Over the years, the transaction has come to mean so many different things depending on whether you have a business perspective or a technology perspective. Recently, however, the business and technology perspectives have begun to coincide at management levels. This makes the goal of communicating the vision and goal of a project even more difficult and complex than previously. Let's look at some of the different uses of the word in the enterprise world and isolate a few distinctions in its meaning that we'll be able to use downstream to ensure clear delivery of intent.
Exchange Transaction
Database Transaction
This definition tends to be most closely associated with the properties of transaction management with regard to database management. However, I think that ACID captures the intent of any transaction, whether it occurs in the database or over the Web.
Compensating Transaction
Transactional Messaging
Transaction Processing Monitor
As you can see from the above definitions, it's possible to classify transactions for purposes of setting proper expectations. If you're developing system requirements and want to represent that the transaction is initiated by the user purchasing merchandise in the store, it would be best to call it an exchange. Likewise, if you want to represent the credit portion of that transaction, you might identify that as an ACID or transactional message, depending on whether it's with the store's back office or directly with the credit card company. Clarifications like this may seem rudimentary and overly basic, but between those gathering requirements and those implementing the solution I've seen confusion mount quickly because the terms weren't defined explicitly. In one very poorly defined situation, the system requirements described what amounted to an exchange transaction, which led the implementers to believe they could build their system against the executed transactions in the database. One month before expected completion of the project, the misunderstanding surfaced and the team realized they were a good two months away from completion because they hadn't built the mechanism to record the transaction in the database the point of sale. Reader Feedback: Page 1 of 1
Latest Cloud Developer Stories
Subscribe to the World's Most Powerful Newsletters
Subscribe to Our Rss Feeds & Get Your SYS-CON News Live!
|
SYS-CON Featured Whitepapers
Most Read This Week
Breaking Cloud Computing News
|
|||||||||||||||||||||||||||||||||||||||||||||||||