Last year, I have been putting some thoughts into words while blogging about managing transactions. Those who are enthusiastic, can visit this link of my earlier posts on transactions. I have been primarily limited around managing transactions using a transaction coordinator, or more specifically, an application server like COM+. I also explored of having transaction boundaries spread across components and bridged through synchronous events.
Over the period to time, the requirement of having transactions over HTTP is becoming acute. The primary driver to this requirement is the killing success of web services, and its proliferation beyond the traditional boundaries: political, geographical, or organizational.
I am feeling the heat too. Increasingly, I am trying to grapple up with the issues of data inconsistency across the applications that happened due to partial failure of the processes. While defining the business the requirements, these requirements came up as a single unit of work. However, the underlying steps mandate dealing with multiple applications, one being the base application, and the others are dealt via web services. Consuming web services do not remain limited to consuming data, but many times, it means insert/update/delete into the database of other applications. And, the problem starts from there. I am seeing data updated on the base application, but not on the remote application, and vice versa. The users are scared to death when they see their updates are not getting reflected, the operations people are tearing their hairs to correct data/records, and I am sure all are equally angry to see themselves landing into such a trouble.
WS-Transaction specification has come to address some of these problems and to meet the business requirements the way they are getting defined in today's world. In the subsequent BLOGs, we can speak more about this specification and perhaps will try out some sample codes, if possible.
No comments:
Post a Comment