|By Mark Little||
|October 21, 2002 12:00 AM EDT||
Use of atomic transactions is a well-known technique for guaranteeing consistency in the presence of failures. The ACID properties of atomic transactions (Atomicity, Consistency, Isolation, Durability) ensure that even in complex business applications consistency of state is preserved.
Transactions are best viewed as "short-lived" entities operating in a closely coupled environment, performing stable state changes to the system; they are less well suited for structuring "long-lived" application functions (e.g., running for hours, days, etc.) and running in a loosely coupled environment like the Web. Long-lived atomic transactions (as typically occur in business-to-business interactions) may reduce the concurrency in the system to an unacceptable level by holding on to resources for a long time; further, if such an atomic transaction rolls back, much valuable work already performed could be undone. As a result, there have been various extended transactions models where strict ACID properties can be relaxed in a controlled manner. Until recently, translating these models into the world of Web services had not been attempted. However, the OASIS Business Transaction Protocol, specified by a collaboration of several companies, has tried to address this issue. In this article, the second in a two-part series, we'll describe how the BTP has attempted to solve these problems.
Architecture of the Business Transaction Protocol
A very high-level view of the BTP can be described as follows: Web services do work within the scope of atoms, which are created by the initiator of a business transaction; multiple atoms are composed into a business transaction (e.g., arranging a holiday) by a cohesion composer such that different atoms may possess different outcomes, as directed by the business logic, e.g., cancel one insurance quote and confirm another. Businesses take part in atomic or cohesive transactions via participants, and both cohesions and atoms use coordination to ensure that participants see the desired outcome (see Figure 1). This may seem fairly straightforward at first, but as we shall see in the following sections, there's a lot more going on under the covers!
The XML Context
In order for a transaction to span a distributed number of services/tasks, certain information has to flow between the sites/domains involved in the application. This is commonly referred to as the context and typically contains the following information:
The context information is propagated to provide a flow of context information between distributed execution environments, for example using SOAP header information. This may occur transparently to the client and application services. The context is propagated as part of normal message interchange within an application (e.g., as an additional part of the SOAP header).
XML Message Sets and Carrier Bindings
In the Web services world, information is communicated in XML documents, but how those documents are exchanged may be a function of the environment, business relationship, etc. Therefore, although BTP mandates that its own information (context and protocol messages) must be carried in XML payloads, it doesn't specify how these payloads are transmitted; it doesn't mandate a specific carrier protocol.
Obviously, without a carrier protocol, BTP is of very limited use! The technical committee did define a binding to SOAP 1.1 over HTTP 1.1 as part of the BTP 1.0 specification, but the intention has always been that other specific carrier protocol bindings to the BTP XML schema would be provided on an as-needed basis. So if, for example, a group of companies sees merit in defining a binding using pigeons(!), they could so define it and submit it as an appendix on optional bindings to the BTP specification.
As with traditional transaction processing systems, the BTP message set is concerned with messages for driving the protocol and messages containing information for participating within the protocol. The former are typically of interest only to implementers of either BTP or participants, whereas the latter are of interest to service providers and their associated participants.
Typically a BTP message is propagated within the body of the SOAP envelope. For example, Listing 1 shows a typical begin message.
For application messages that also carry BTP content, the situation is different. In this situation the BTP messages are typically located within the header of the SOAP envelope, as can be seen in Listing 2, in which a BTP context is propagated with an application-specific method call.
The Web Service
Whenever a user contacts a Web service, e.g., a taxi booking service, whose work it wishes to be under the control of a transaction, components of the transaction system are responsible for flowing the context to that service. The service can then use this information to enlist a participant with the transaction. The service is responsible for ensuring that concurrent accesses by different applications are managed in a way that guarantees some internal consistency criteria for that service. Note that a Web service may also play the role of a participant.
The participant is the entity that does the real transaction work. The Web service (e.g., a theater booking system) contains some business logic for reserving a seat, inquiring about availability, etc., but it will need to be back-ended by something that maintains information in a durable manner. Typically this will be a database, but it could be a file system, NVRAM, etc.
Now, although the service may talk to the back-end database directly, it cannot commit or roll back any changes it (the service) makes, since these are ultimately under the control of the transaction that scoped the work. In order for the transaction to be able to exercise this control, it must have some contact with the back-end resource (the database in our example), and this is accomplished by the participant.
Each participant supports a two-phase termination protocol via the prepare, confirm, and cancel operations. What the participant does when asked to prepare is implementation dependent (e.g., reserve the theater ticket); it then returns an indication of whether or not it succeeded. However, unlike in an atomic transaction, the participant does not have to guarantee that it can remain in this prepared state; it may indicate that it can only do so for a specified period of time, and also indicate what action it will take (confirm or undo) if it has not been told how to finish before this period elapses. In addition, no indication of how the prepare is implemented is implied in the protocol, so resource reservation (locking), as happens in an ACID transaction system, need not occur.
Associated with every transaction type (atom or cohesion) is a coordinator, which is responsible for governing the outcome of the transaction. The coordinator may be implemented as a separate service or may be colocated with the user for improved performance. It communicates with enlisted participants to inform them of the desired termination requirements, i.e., whether they should accept (confirm) or reject (cancel) the work done within the scope of the given transaction. For example, whether to purchase the (provisionally reserved) flight tickets for the user or to release them. This communication will be an implementation-specific protocol (e.g., two- or three-phase completion).
A transaction manager factory is typically responsible for managing coordinators for many transactions. The initiator of the transaction (e.g., the client) communicates with a transaction manager and asks it to start a new transaction and associate a coordinator with the transaction. Once created, the context can be propagated to Web services in order for them to associate their work with the transaction.
The atom coordinator is typically used to scope work performed on Web services. The cohesion composer is the business logic for gluing together the flow of the application into one or more atoms. Although Web services do work within the scope of a specific atom, it is the composer that ultimately determines which atoms to confirm, and which to undo; as participants are to atoms, so atoms are to cohesion composers (cohesions). The composer may prepare and cancel atoms at arbitrary points during the lifetime of the business transaction, e.g., preparing the flight reservation early in the transaction, and preparing the insurance quote much later after cancelling a prior quote. The main difference between an atom and a cohesion is that whereas all participants enrolled with an atom will either confirm or cancel, the participants enrolled with a cohesion (multiple atoms) may have different outcomes. However, once the composer has arrived at its confirm set (the participants that will confirm), it essentially collapses down to become an atom and guarantees an all-or-nothing effect, i.e., all atoms in the confirm set will either confirm or cancel, with no intermediate effects.
Superiors and Inferiors
Although for simplicity we've talked about services, coordinators, and participants, within BTP all end points are either Superiors or Inferiors or both. An actor within the coordinating entity's system plays the role of Superior (e.g., the atom coordinator) and an actor within the service plays the role of an Inferior (e.g., the participant). Each Inferior has only one Superior. However, a single Superior may have multiple Inferiors within single or multiple parties. A tree of such relationships may be wide, deep, or both, as shown in Figure 2.
An Inferior is typically associated with some set of application activities. Usually this will be a result of some operation invocations (on a "service application element") from elsewhere (an "initiating application element"). The Inferior is responsible for reporting to the Superior that it is "prepared" for the outcome whether or not the associated operations' provisional effect can be confirmed or cancelled.
A Superior receives reports from its Inferiors as to whether they are prepared to give an outcome. It gathers these reports in order to determine which Inferiors should be canceled and which confirmed. The Superior does this either by itself or with the cooperation of the application element responsible for its creation and control, depending upon whether the transaction is an atom or a cohesion, as we shall see later.
The initiator of the atom communicates with an atom/cohesion manager (factory) and asks it to start a new atom. Once created, information about the atom or cohesion (the context) can be propagated to Web services in order for them to associate their work with it. Although work is typically conducted within the scope of an atom, it is entirely possible for services to register participants directly with cohesions.
The terminator of the atom or cohesion will typically be the same entity as the initiator, but need not be. For example a long-running stock purchase transaction may be started by the company that requires the stock, and finished by the company that delivers it. Although an atom can be instructed to confirm all participants immediately, it is more typically instructed to prepare them first, and later (hours, days, etc.) to either confirm or cancel them.
BTP gives builders of transactional Web services the ability to concentrate on the functional aspects of their services (e.g., what it means to book an airline ticket), and to guarantee consensus through the participant interface. Since the participant interface is transparent to its implementation, a provider may use any implementation appropriate to the Web service it acts on behalf of.
Through the cohesion composer, BTP gives the business logic the flexibility to structure interactions with services into multiple (dynamic) consensus groups. The important distinction between BTP and atomic transactions is that multiple such groups exist in BTP, compared to one in atomic transactions, and the cohesion has the capability to drive the two-phase termination protocol explicitly. The fact that atoms may be prepared at any point in the normal flow of business, and later confirmed or undone, gives greater flexibility to the application.
We have described how BTP can be used to conduct typical business-to-business interactions in a reliable manner. In order to do this, many protocol-specific messages need to be exchanged between actors, and this will have an adverse effect on the time taken to complete a business transaction. This is a necessary side effect of achieving reliability and consensus and is not specific to BTP.
Since BTP is intended for long-running transactions, it may be assumed that performance hasn't been a prime factor in its development. However, this is not the case and, in fact, BTP contains a number of optimizations.
Typically a participant is enlisted with a BTP transaction when a service invocation occurs (e.g., "book flight"). When the service request completes, the response is sent back to the initiator of the request. As described earlier, during transaction termination the coordinator will interact with the participant to ensure completion.
In some circumstances it may be possible to compound many of the above messages into a "one-shot" message. For example, the service invocation may cause a state change to occur that means the participant can prepare immediately after the invocation completes. Rather than having to wait for an explicit coordinator message, BTP allows the enroll request and statement of preparation to be compounded within the service response. The receiver is then responsible for ensuring that this additional information is forwarded to the responsible actors.
Resignation by Participant
In a two-phase commit protocol, in addition to indicating success or failure during the preparation phase, a participant can also return a "read-only" response; this indicates that it doesn't control any work that has been modified during the course of the transaction and therefore doesn't need to be informed of the transaction outcome. In some situations this allows the two-phase protocol to complete quickly, since a second round of messages isn't required.
The equivalent of this in BTP is for a participant to resign from the transaction it was enrolled in. Resignation can occur at any time up to the point at which the participant has prepared. Resignation is used by the participant to indicate that it no longer has an interest in the outcome of the transaction.
In some situations, rather than waiting for an instruction from the coordinator to prepare, a participant may be able to spontaneously prepare. For example, a service invocation occurs, moving the service into an idempotent state such that further invocations have no effect on it; in this case, an associated participant may prepare the service immediately, rather than wait for the instruction to do so. In BTP, a participant is allowed to attempt to prepare at any point and inform the coordinator of the result.
Autonomous Decision by Participant
In a traditional two-phase protocol a participant enrolls with a transaction and waits for the termination protocol before it either confirms or cancels. To achieve consensus, it is necessarily a blocking protocol, which means that if a coordinator fails before delivering the final phase messages, prepared participants must remain blocked, holding on to (possibly valuable) resources. Modern transaction-processing systems have augmented the two-phase commit with heuristics, which allow such participants to make unilateral decisions about whether they will commit or roll back. Obviously if a participant makes a choice that turns out to be different from that of other participants, nonatomic behavior occurs.
BTP has its equivalent of heuristics, allowing participants to make unilateral decisions as well. However, unlike other transaction implementations, the protocol allows a participant to give the coordinator prior knowledge of what the decision will be and when it will occur. A participant may prepare and present the coordinator with some caveats as to how long it will remain in this state and into what state it will then migrate (e.g., "will remain prepared for 10 days and then will cancel the flight reservation"). This information may then be used by the coordinator to optimize message exchange.
BTP and the Web Services Stack
So where exactly does BTP fit into the evolving Web services architecture? As shown in Figure 3, it is primarily intended as a low-level protocol, hidden from users in much the same way traditional transaction systems are. Typically, a user would see just a demarcation API (e.g., how to start and end an atom); the BTP specification does not define any such API because it is language independent. One possible API that readers should be aware of is that being developed in JSR 156 - Java API for XML Transactions.
So How Would I Use This BTP Thing?
Consider the flight booking example presented earlier. How could we use BTP in order to coordinate this application in a reliable manner? The problem is that we wish to obtain the cheapest insurance quote as we go along, without losing prior quotes until we know that they are no longer the cheapest; at that point we will be able to release those quotes while maintaining others. In a traditional transaction system, all of the work performed within a transaction must either be accepted (committed) or declined (rolled back); the required loosening of atomicity is not supported.
In BTP, however, we can use atoms and cohesions. A cohesion is first created to manage the overall business interactions. The business logic (application, client, etc.) creates an atom (i.e., ReserveAtom) and enrolls it with the cohesion, as shown in Figure 4.
Once the client has obtained the context from the factory, it can invoke the airline and taxi reservation services within the scope of the atom, such that their work is then ultimately controlled by its outcome. When a suitable flight and taxi can be obtained, ReserveAtom is prepared to reserve the bookings for some service-specific time.
Then two new atoms (AtomQuote1 and AtomQuote2) are created and enrolled with the cohesion, before being used to obtain two different quotes from the respective insurance services.
When the quote from the first insurance site is obtained it is obviously not known whether it is the best quote, so the business logic can prepare AtomQuote1 to maintain the quote, while it then communicates with the second insurance site. If that site does not offer a better quote, the application can cancel AtomQuote2 and it now has its final confirmation set of atoms (ReserveAtom and AtomQuote1), which it can confirm (see Figure 5).
ACID transactions have proven invaluable over the years in the construction of enterprise applications. However, they are only really suited to short-duration activities executing on closely coupled applications and environments. When used in a loosely coupled environment, they prove too inflexible and restricting for many applications. The OASIS Business Transactions Protocol has been developed to solve this problem while at the same time maintaining those aspects of the atomic transaction model that have proven useful. At the time of this writing, there is only a single BTP implementation available, from Hewlett-Packard. However, several companies have stated that they are working on their own implementations.
Digitization is driving a fundamental change in society that is transforming the way businesses work with their customers, their supply chains and their people. Digital transformation leverages DevOps best practices, such as Agile Parallel Development, Continuous Delivery and Agile Operations to capitalize on opportunities and create competitive differentiation in the application economy. However, information security has been notably absent from the DevOps movement. Speed doesn’t have to negat...
Sep. 30, 2016 07:00 AM EDT Reads: 2,334
Cloud computing is now being embraced by a majority of enterprises of all sizes. Yesterday's debate about public vs. private has transformed into the reality of hybrid cloud: a recent survey shows that 74% of enterprises have a hybrid cloud strategy. Meanwhile, 94% of enterprises are using some form of XaaS - software, platform, and infrastructure as a service.
Sep. 30, 2016 07:00 AM EDT Reads: 865
The Internet of Things will challenge the status quo of how IT and development organizations operate. Or will it? Certainly the fog layer of IoT requires special insights about data ontology, security and transactional integrity. But the developmental challenges are the same: People, Process and Platform and how we integrate our thinking to solve complicated problems. In his session at 19th Cloud Expo, Craig Sproule, CEO of Metavine, will demonstrate how to move beyond today's coding paradigm ...
Sep. 30, 2016 07:00 AM EDT Reads: 3,464
Your business relies on your applications and your employees to stay in business. Whether you develop apps or manage business critical apps that help fuel your business, what happens when users experience sluggish performance? You and all technical teams across the organization – application, network, operations, among others, as well as, those outside the organization, like ISPs and third-party providers – are called in to solve the problem.
Sep. 30, 2016 06:00 AM EDT Reads: 2,736
While DevOps promises a better and tighter integration among an organization’s development and operation teams and transforms an application life cycle into a continual deployment, Chef and Azure together provides a speedy, cost-effective and highly scalable vehicle for realizing the business values of this transformation. In his session at @DevOpsSummit at 19th Cloud Expo, Yung Chou, a Technology Evangelist at Microsoft, will present a unique opportunity to witness how Chef and Azure work tog...
Sep. 30, 2016 05:15 AM EDT Reads: 1,847
As applications are promoted from the development environment to the CI or the QA environment and then into the production environment, it is very common for the configuration settings to be changed as the code is promoted. For example, the settings for the database connection pools are typically lower in development environment than the QA/Load Testing environment. The primary reason for the existence of the configuration setting differences is to enhance application performance. However, occas...
Sep. 30, 2016 05:00 AM EDT Reads: 957
Internet of @ThingsExpo, taking place November 1-3, 2016, at the Santa Clara Convention Center in Santa Clara, CA, is co-located with the 19th International Cloud Expo and will feature technical sessions from a rock star conference faculty and the leading industry players in the world and ThingsExpo Silicon Valley Call for Papers is now open.
Sep. 30, 2016 04:45 AM EDT Reads: 4,719
This digest provides an overview of good resources that are well worth reading. We’ll be updating this page as new content becomes available, so I suggest you bookmark it. Also, expect more digests to come on different topics that make all of our IT-hearts go boom!
Sep. 30, 2016 04:15 AM EDT Reads: 5,424
If you’re responsible for an application that depends on the data or functionality of various IoT endpoints – either sensors or devices – your brand reputation depends on the security, reliability, and compliance of its many integrated parts. If your application fails to deliver the expected business results, your customers and partners won't care if that failure stems from the code you developed or from a component that you integrated. What can you do to ensure that the endpoints work as expect...
Sep. 30, 2016 03:15 AM EDT Reads: 1,756
SYS-CON Events announced today that Numerex Corp, a leading provider of managed enterprise solutions enabling the Internet of Things (IoT), will exhibit at the 19th International Cloud Expo | @ThingsExpo, which will take place on November 1–3, 2016, at the Santa Clara Convention Center in Santa Clara, CA. Numerex Corp. (NASDAQ:NMRX) is a leading provider of managed enterprise solutions enabling the Internet of Things (IoT). The Company's solutions produce new revenue streams or create operating...
Sep. 30, 2016 02:00 AM EDT Reads: 2,088
DevOps and microservices are permeating software engineering teams broadly, whether these teams are in pure software shops but happen to run a business, such Uber and Airbnb, or in companies that rely heavily on software to run more traditional business, such as financial firms or high-end manufacturers. Microservices and DevOps have created software development and therefore business speed and agility benefits, but they have also created problems; specifically, they have created software sec...
Sep. 30, 2016 02:00 AM EDT Reads: 1,397
To leverage Continuous Delivery, enterprises must consider impacts that span functional silos, as well as applications that touch older, slower moving components. Managing the many dependencies can cause slowdowns. See how to achieve continuous delivery in the enterprise.
Sep. 30, 2016 01:45 AM EDT Reads: 2,198
SYS-CON Events announced today that Tintri Inc., a leading producer of VM-aware storage (VAS) for virtualization and cloud environments, will exhibit at the 19th International Cloud Expo, which will take place on November 1–3, 2016, at the Santa Clara Convention Center in Santa Clara, CA. Tintri VM-aware storage is the simplest for virtualized applications and cloud. Organizations including GE, Toyota, United Healthcare, NASA and 6 of the Fortune 15 have said “No to LUNs.” With Tintri they mana...
Sep. 30, 2016 01:15 AM EDT Reads: 2,975
In his general session at 18th Cloud Expo, Lee Atchison, Principal Cloud Architect and Advocate at New Relic, discussed cloud as a ‘better data center’ and how it adds new capacity (faster) and improves application availability (redundancy). The cloud is a ‘Dynamic Tool for Dynamic Apps’ and resource allocation is an integral part of your application architecture, so use only the resources you need and allocate /de-allocate resources on the fly.
Sep. 30, 2016 12:45 AM EDT Reads: 2,991
Cloud Expo 2016 New York at the Javits Center New York was characterized by increased attendance and a new focus on operations. These were both encouraging signs for all involved in Cloud Computing and all that it touches. As Conference Chair, I work with the Cloud Expo team to structure three keynotes, numerous general sessions, and more than 150 breakout sessions along 10 tracks. Our job is to balance the state of enterprise IT today with the trends that will be commonplace tomorrow. Mobile...
Sep. 30, 2016 12:00 AM EDT Reads: 4,261
Analysis of 25,000 applications reveals 6.8% of packages/components used included known defects. Organizations standardizing on components between 2 - 3 years of age can decrease defect rates substantially. Open source and third-party packages/components live at the heart of high velocity software development organizations. Today, an average of 106 packages/components comprise 80 - 90% of a modern application, yet few organizations have visibility into what components are used where.
Sep. 29, 2016 10:45 PM EDT Reads: 857
More and more companies are looking to microservices as an architectural pattern for breaking apart applications into more manageable pieces so that agile teams can deliver new features quicker and more effectively. What this pattern has done more than anything to date is spark organizational transformations, setting the foundation for future application development. In practice, however, there are a number of considerations to make that go beyond simply “build, ship, and run,” which changes ho...
Sep. 29, 2016 10:15 PM EDT Reads: 2,815
Throughout history, various leaders have risen up and tried to unify the world by conquest. Fortunately, none of their plans have succeeded. The world goes on just fine with each country ruling itself; no single ruler is necessary. That’s how it is with the container platform ecosystem, as well. There’s no need for one all-powerful, all-encompassing container platform. Think about any other technology sector out there – there are always multiple solutions in every space. The same goes for conta...
Sep. 29, 2016 07:45 PM EDT Reads: 1,279
Let's recap what we learned from the previous chapters in the series: episode 1 and episode 2. We learned that a good rollback mechanism cannot be designed without having an intimate knowledge of the application architecture, the nature of your components and their dependencies. Now that we know what we have to restore and in which order, the question is how?
Sep. 29, 2016 07:00 PM EDT Reads: 1,350
All clouds are not equal. To succeed in a DevOps context, organizations should plan to develop/deploy apps across a choice of on-premise and public clouds simultaneously depending on the business needs. This is where the concept of the Lean Cloud comes in - resting on the idea that you often need to relocate your app modules over their life cycles for both innovation and operational efficiency in the cloud. In his session at @DevOpsSummit at19th Cloud Expo, Valentin (Val) Bercovici, CTO of So...
Sep. 29, 2016 06:00 PM EDT Reads: 1,552