Welcome!

Weblogic Authors: Yeshim Deniz, Elizabeth White, Michael Meiner, Michael Bushong, Avi Rosenthal

Related Topics: Weblogic

Weblogic: Article

Transactions for the Next Generation

BAM by the back door?

A realization has dawned across the industry that "service-oriented architecture" is a good thing. In fact, this is less of a dawning and more of a reawakening.

Ever since our Neolithic forebears picked up a bone and realized that separating the 3270 screen handling code from that which implemented their business rules was a "jolly good thing," three tier architecture, n-tier architecture, SOA, call it what you will, has been recognized as the best way to build systems. The facets that make it the best way are called out by the industry mantra "coarse-grained, loosely coupled, asynchronous interfaces," as we all know.

Looking around at a lot of enterprise systems in production today, the "asynchronous" part is often (maybe even usually) delivered via use of an asynchronous reliable queuing mechanism. The power of the "fire and forget" programming style that these technologies bring to the table is that your part of the system can simply post a message and rely on the fact that it will eventually arrive at its intended destination (or be processed by some harassed administrator who was paged in the middle of the night when the infrastructure went pop). The ability to rely on this behavior keeps the application code nice and simple - the concept of "fire and forget" is readily understood, and the technical complexity required to implement it is encapsulated within the queuing product. Couple that with transactional xa access to a database, and your application can rest easy in its bed at night, knowing that everything it wants to achieve will happen once and once only, with no user code needed.

Life is good. We know the chant, we sing it, and we have a trouble-free existence as developers. Everything is as it should be.

Of course, in all of life's rapture moments, something is bound to happen to cause a rude awakening. Imagine now the discordant ringing of a thousand alarm clocks.... Snap out of it! Life isn't that good!

For a start, the administrator got paged in the middle of the night when things went wrong... What did he have to do to fix things? Well, we can't answer that. It depends. Where was the message going? Why didn't it get there? Is the data in the message in error, did the queuing infrastructure break under the strain? Our administrator needs to answer these questions (hopefully in consultation with the documentation, rather than the actual developers that wrote the system, but either way, what to do to resolve the situation can only be decided in the light of hidden knowledge of the context around what was going on). For one thing, this highlights that coarse-grained, loosely coupled, and asynchronous are orthogonal attributes - the asynchronous behaviour of our transport has not bought us loose coupling - a point-to-point asynchronous link is still just that - point-to-point. To address the problems of hidden complexity brought about by a point-to-point design, a choreography layer is introduced into the architecture, decoupling the message senders and receivers. Standards like BPEL, implemented by products such as BEA's WebLogic Integration (or WebLogic Process Edition), provide this place within the architecture for the "knowledge about interconnectedness" to live, so there is a point of reference for the guy who needs to fix things when they break - a single place to go to see the end-to-end message flow, and determine where things fouled up in the overall scheme of things to provide some context for fixing whatever failed. This is the realm that is emerging as the "enterprise service bus (ESB)."

Another rude awakening comes when the user of the application built on this asynchronous technology says, "What happened to my trade" (or, in general, what happened to my <whatever I initiated a while ago with my app>). Suddenly, the support staff is scrambling around with all kinds of headaches. Where did this particular instruction get to? If you are using a choreography layer to solve the point-to-point problem outlined above, then this should provide a means of drilling into an individual instance of a business flow and tracking where it got to (and perhaps why it's stuck there) so you have a solution for this class of problem too.

Then, just as you were feeling smug and ahead of the game, the managers of the individuals who use the system come along and say, "How's it working? Is everything fine? How is our business performing?" Now, the ability to drill into an individual request is not so important. What's needed is to get a top-level overview of the system - how many business transactions are in flight? Where are they all up to in the chain of events from entry to completion? Have any taken too long to pass through the system, requiring intervention to fix whatever is wrong?

This last requirement is usually termed "business activity monitoring" (BAM) - and in traditional point-to-point messaging-based systems, its delivery generally constitutes some kind of dashboard that shows red lights when "too many" messages haven't passed through any given point (or when messages appear to have missed stages, or otherwise broken the rules) and the infrastructure that gathers the transaction tracking data needed to provide the aggregated view generally consists of yet more queues. As each message is delivered to the next application, a "BAM message" is sent to the BAM system, which processes it (along with all the others that are flooding in) to determine where in the end-to-end system each individual business transaction is. Again, in a world orchestrated by an ESB-type approach, the message bus provides an ideal point to collect and collate all this information.

So that's nice. We are happy again, and can start to go back to our sweet dreams.

So, What About "Next Generation Transactions"?
Well, the scenario I described is very much one in which the overall structure of the system is fairly static. OK, so you configured your ESB to wire the constituent services together so it wasn't point to point, but the flow follows the same consistent pattern execution after execution. What about other scenarios? Imagine an order fulfillment system that works out a price for an order by getting prices and availability from several sub-contractors and then makes some decision as to which set of purchases provide the best offer. For example, I get a quote for laptops from three suppliers, each responds with a different price, guarantee terms, and availability. I then get a quote to ship the laptops from each of these suppliers to my customer. My overall price for each permutation is the sum of the unit price and shipping cost, and my customer may wish to choose between the options based on the overall price, and required delivery dates, the guarantee terms, etc. The flow of the final transaction will only be decided when these decisions are made. Suddenly, we are in a situation where we are getting forced down the line of writing an "orchestration" application, which is relatively closely coupled to all the back ends it accesses.

Moreover, because we are getting painted into that corner, tracking our orders will be rather difficult: for every order, we will have to track the decisions that were made in order to know where to look for our in-flight order, once placed. This is where the new-generation transaction comes in. The notion of a cohesion - a unit of work similar to a transaction in that it can be cancelled or committed, but distinct in that it does not have to complete or cancel in an all-o-nothing fashion - was introduced in OASIS' BTP specification. The concept is currently working its way into the WS-BusinessActivity variant of the emerging WS-Transaction specification. Provisional orders for the laptops could be placed with the three suppliers in one cohesion, with every intention that by the time the order is finalized, two of these three laptop orders will be cancelled again. It will be similar for the shipment requests. Using a framework to drive this loosely coupled transactional behavior will greatly simplify the code of the orchestrating application (and provide loose coupling benefits similar to those the ESB offered in the fixed-flow case). The fact that a framework is being used to track all these interactions means that when the requirements for the BAM-style capability surface, the next-generation transaction framework provides a central point of reference, which will directly provide the "where has my transaction got to" information, and (via something analogous to transaction timeouts) be able to monitor service-level agreements and provide the information to drill in to to diagnose problems. In fact, this is an often-overlooked benefit of the traditional JTA style transaction manager: it provides a place you can go to and say, "What data did this operation touch?" at least while the transaction is in flight.

So, a framework supporting cohesions could become to the dynamic application system what the ESB is to the static one. In fact, it is also possible to envisage a cohesions framework augmenting an ESB-style approach, even for statically defined systems. The ESB provides a good "message oriented" way to visualisze a composite application, but business semantics are not described in messages, technology solutions are. Cohesions provide a standardised mechanism for associating messages (and processing of the messages) with business transactions - things like "place an order" that it doesn't take an IT expert to comprehend. Service-oriented architecture encourages us to build components in a loosely coupled fashion so that they can be combined in ways not thought of when they were initially created. Their loose coupling however is merely a technically loose coupling. The composite services are by definition coupled - why else does the business need invocations of the components to occur in sequence? The concept of cohesions provides a standardized way to identify the business semantics causing the message flow - it is this kind of information that will be needed for business activity monitoring at the business level (as opposed to message - flow spotting at the infrastructure level). With an ESB approach, this higher-level information is likely to be some kind of static commentary on a flow diagram, whereas a cohesions framework allows the information about the business semantics of each operation to flow dynamically with the messages that implement it, providing for better visibility into and management of the composite application system, not to mention the more traditional transaction-related business benefits of consistent recoverable outcomes thrown in for good measure. Maybe we had better watch out for the "enterprise transaction bus" appearing alongside the enterprise service bus. But that's the thing about buses. Never one when you want one, and then several arrive at once!

.  .  .

Transactions: Driving You to Distraction? Addenda!
In the May/June issue (Vol. 3, issue 5) of WLDJ, I wrote (after hearing the topic come up on numerous occasions, in many contexts) about the best choice of JDBC driver for use under WebLogic Server-based applications.

As every consultant tries to do, I hedged my bets and gave some good generic advice (namely, benchmark your application using the XA configuration you need for production to ensure that your exact setup will give the throughput you require from your application), but I also (after much hesitation and deliberation) came off the fence and gave specific advice: "with the technology where it is today, it seems safe to conclude that you should try to stick to the type 2 driver for XA database access, unless you have a pretty compelling reason to do otherwise."

I stand by that advice (and boy, am I glad that I included the "technology where it is today" caveat!!!), but needless to say, technology today isn't where technology was at the time of the copy date for the article!!!

A new driver came out of Oracle pretty much as my article left my laptop. That driver is the Oracle 10g thin driver. It supports versions of Oracle prior to 10g (as well, of course, as 10g itself); it's a type 4 driver so it doesn't need native libraries on the client, it supports XA. Not only does it support XA, but it does so without the overhead on database CPU consumption that the old thin drivers had in XA mode. Hallelujah!

So the new specific advice (what am I doing... I see another correction coming in the future!) is to take a long, hard look at the Oracle 10g thin driver as the way to access your database, especially if you're planning to use XA transactions. Not only can you use it in your own database access code, but this driver is supported by all the components of the WebLogic platform in WebLogic 8.1 service packs 2 and 3 (see http://e-docs.bea.com/platform/suppconfigs/ configs81/81_over/supported_db.html#1127404).

Now, back to drawing bubbles, clouds, and lines. Why is it my whiteboard architecture diagrams never have these problems?

More Stories By Peter Holditch

Peter Holditch is a senior presales engineer in the UK for Azul Systems. Prior to joining Azul he spent nine years at BEA systems, going from being one of their first Professional Services consultants in Europe and finishing up as a principal presales engineer. He has an R&D background (originally having worked on BEA's Tuxedo product) and his technical interests are in high-throughput transaction systems. "Of the pitch" Peter likes to brew beer, build furniture, and undertake other ludicrously ambitious projects - but (generally) not all at the same time!

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.


IoT & Smart Cities Stories
Early Bird Registration Discount Expires on August 31, 2018 Conference Registration Link ▸ HERE. Pick from all 200 sessions in all 10 tracks, plus 22 Keynotes & General Sessions! Lunch is served two days. EXPIRES AUGUST 31, 2018. Ticket prices: ($1,295-Aug 31) ($1,495-Oct 31) ($1,995-Nov 12) ($2,500-Walk-in)
Andrew Keys is Co-Founder of ConsenSys Enterprise. He comes to ConsenSys Enterprise with capital markets, technology and entrepreneurial experience. Previously, he worked for UBS investment bank in equities analysis. Later, he was responsible for the creation and distribution of life settlement products to hedge funds and investment banks. After, he co-founded a revenue cycle management company where he learned about Bitcoin and eventually Ethereal. Andrew's role at ConsenSys Enterprise is a mul...
Nicolas Fierro is CEO of MIMIR Blockchain Solutions. He is a programmer, technologist, and operations dev who has worked with Ethereum and blockchain since 2014. His knowledge in blockchain dates to when he performed dev ops services to the Ethereum Foundation as one the privileged few developers to work with the original core team in Switzerland.
René Bostic is the Technical VP of the IBM Cloud Unit in North America. Enjoying her career with IBM during the modern millennial technological era, she is an expert in cloud computing, DevOps and emerging cloud technologies such as Blockchain. Her strengths and core competencies include a proven record of accomplishments in consensus building at all levels to assess, plan, and implement enterprise and cloud computing solutions. René is a member of the Society of Women Engineers (SWE) and a m...
Digital Transformation and Disruption, Amazon Style - What You Can Learn. Chris Kocher is a co-founder of Grey Heron, a management and strategic marketing consulting firm. He has 25+ years in both strategic and hands-on operating experience helping executives and investors build revenues and shareholder value. He has consulted with over 130 companies on innovating with new business models, product strategies and monetization. Chris has held management positions at HP and Symantec in addition to ...
The challenges of aggregating data from consumer-oriented devices, such as wearable technologies and smart thermostats, are fairly well-understood. However, there are a new set of challenges for IoT devices that generate megabytes or gigabytes of data per second. Certainly, the infrastructure will have to change, as those volumes of data will likely overwhelm the available bandwidth for aggregating the data into a central repository. Ochandarena discusses a whole new way to think about your next...
CloudEXPO | DevOpsSUMMIT | DXWorldEXPO are the world's most influential, independent events where Cloud Computing was coined and where technology buyers and vendors meet to experience and discuss the big picture of Digital Transformation and all of the strategies, tactics, and tools they need to realize their goals. Sponsors of DXWorldEXPO | CloudEXPO benefit from unmatched branding, profile building and lead generation opportunities.
Dynatrace is an application performance management software company with products for the information technology departments and digital business owners of medium and large businesses. Building the Future of Monitoring with Artificial Intelligence. Today we can collect lots and lots of performance data. We build beautiful dashboards and even have fancy query languages to access and transform the data. Still performance data is a secret language only a couple of people understand. The more busine...
All in Mobile is a place where we continually maximize their impact by fostering understanding, empathy, insights, creativity and joy. They believe that a truly useful and desirable mobile app doesn't need the brightest idea or the most advanced technology. A great product begins with understanding people. It's easy to think that customers will love your app, but can you justify it? They make sure your final app is something that users truly want and need. The only way to do this is by ...
DXWorldEXPO LLC announced today that Big Data Federation to Exhibit at the 22nd International CloudEXPO, colocated with DevOpsSUMMIT and DXWorldEXPO, November 12-13, 2018 in New York City. Big Data Federation, Inc. develops and applies artificial intelligence to predict financial and economic events that matter. The company uncovers patterns and precise drivers of performance and outcomes with the aid of machine-learning algorithms, big data, and fundamental analysis. Their products are deployed...