Introduction

Logging is a vital part of many applications, and there are at least two kinds of logging activities: informational and business critical.

Informational logging is needed to track an application's steps and operations. Depending on the purpose of informational logging, it might be more or less critical for the successful operations of applications. For instance, if log records are input to statistical analysis, a low number of failed log operation might be tolerable. If, however, logging is used for auditing purposes, missing log entries might not be tolerable, which leads to the second kind of logging: business critical logging.

Here, logging output influences other parts of a system in terms of business relevance, in other words, other applications read business critical log records and use those in their business logic. This kind of logging is to be treated as carefully as other business operations. An example for this type of logging activity is logging within financial applications, where log records logging financial transactions might be used for interest calculation, fee collection, or simply to satisfy legal requirements such as traceability.

Unfortunately, critical log messages -- informational and business-critical logging -- are seldom treated with care in today's systems. The reason for this is that logging activities are seen as a side activity and logging resources are regarded as write-only devices which just have to be fast and cheap.

Due to the nature of logging, it is an excellent candidate for a web service, as businesses interested in business-critical logging also have an interest in using one enterprise-wide logging service that all applications can use, thus giving the ablity to centrally manage log records and their life cycle.

In the course of this paper, we are going to propose an architecture for an enterprise-wide logging web service focusing on two critical design aspects of distributed systems: reliability and fault tolerance and logging with transactional semantics.

Back to top

Fault tolerance and reliability issues with logging

In this section we discuss WS-Reliability issues in conjunction with logging and propose -- based on the WS-Reliability standard -- an architectural solution for a reliable logging web service.

Requirements for reliable logging

Before going into technical details, let’s define reliability as well as the requirements that a logging web service needs to fulfill.

Definition of reliability

From a user point of view, reliability is often a requirement. These two citations give a good definition of what reliability is:

• According to the book Distibuted Systems -- Concepts and Design (see Resources), a computer system's reliability is a measure of how small the likelihood is of its deviating from behaving as it was designed to do -- that is, according to a specification of its correct behavior -- is. This includes the case of the system stopping, without having taken any individual incorrect actions. Reliability can be enhanced by designing the system so that deviations -- known as failures -- can be detected and recovered from.
• A second definition of reliability given in the book Distributed Systems -- Principles and Paradigms (see Resources) is that a system can run continuously without failure. A highly reliable system is one that will most likely continue to work without interruption during a relatively long period of time.

Those two definitions basically say that you want to create a logging web service that works without interruption during a relatively long period of time, but also has the ability to detect or recover from interruptions.

Logging requirements

Keeping in mind the above definitions, it is not too difficult to identify requirements for a reliable logging web service. The following list describes the mandatory requirements for a reliable logging web service:

• Allow guaranteed message delivery: The underlying design and technical solution needs to be able to guarantee that logging messages submitted to the logging web service are delivered to and processed on the server side.
• Eliminate duplicate messages: The logging web service needs to ensure that messages submitted -- even if submitted multiple times -- are only processed once.
• Guarantee message order: The protocol, design and technical solution need to ensure that logging messages submitted to the web service are processed in the order in which they are sent.
• Logging client and web service fault tolerant: The logging client and web service need to be able to detect or recover from failure.

This means that, for a reliable logging web service, the underlying technical solution needs to guarantee that messages are being delivered and persisted once (and only once) as well as in the right sequence. Further, a logging solution needs to guarantee that messages submitted for logging are actually persisted at some point, for example, even in the event of failure on the server or client side.

High-level architecture

Before finally going into detail, we need to make a few more definitions. In this section we create a high-level architecture for the logging web service, identify the components of this architecture, and define common terminology used throughout this section.

Interaction

Figure 1 shows the high-level components constituting the logging solution and defines the two basic scenarios where logging clients and web services can interact with each other.

The top half of Figure 1 shows the most basic scenario. Here, the logging client interacts directly with the logging web service.

The bottom half of Figure 1 shows a scenario where the logging client does not interact directly with the logging web service. Here, the logging message is passed through a series of intermediate services, called hops. Whether the communication partner of the logging client or logging web service is a Hop needs to be kept transparent.

Hops will not be discussed separately in this document, but from an architectural point of view, hops behave like a logging web service if they interact with a logging client and behave like a logging client if they interact with a logging web service.

Components

In the previous section we identified the main components -- logging client and logging web service. In this section, we create a more detailed architectural view of the logging web service discussed here.

The high-level diagram shown in Figure 2 does not give much technical detail, but it does identify the two major components that comprise the logging web service.

Basically, the logging web service outlined contains two components:

• Logging client: This component encapsulates a reliable logging client that an application can use through the logging API provided. This component receives messages to be logged from the application and then submits those to the logging server in a reliable manner. In this paper this component is generally referred to as client or logging client.
• Logging server: This component is the heart of the application. It provides a web service for reliable logging to logging clients. The logging server receives logging messages from the client and processes those in a reliable manner. In this paper, this component is generally referred to as server or logging server.

Application is the third component shown in Figure 2. The application does not belong to the logging web service discussed here, but is important in this context as it uses the logging client.

Throughout the document, this component is referred to as the business application.

Back to top

WS-Reliability standard

As a basis for this discussion, we outline the WS-Reliability standard (see Resources) and describe its key elements and mechanisms. However, you will see that the WS-Reliability standard covers reliability issues on the protocol level very well, but doesn't touch reliability issues on the application level. Those are the items we focus on in this document to bridge the gap.

Goal of WS-Reliability standard

The goal of the WS-Reliability standard is to define a mechanism for client-server communication through web services that accomplishes the following:

• Allows guaranteed message delivery (at-least-once semantics)
• Eliminates duplicate messages (at-most-once semantics)
• Guarantees message order.

Message key elements as defined by WS-Reliability

WS-Reliability proposes a reliability scheme based on the message/acknowledgment model. This means that every sender sending a message expects a reply message -- the acknowledgement -- from the server.

Figure 3 shows a messaging scenario as defined by the WS-Reliability specification. We refer to the messages exchanged as logging messages. The WS-Reliability standard is not tailored just to logging but to messaging in general. For our purpose though, only the logging application is of relevance.

A logging client sends a logging message to a web service. The web service receives the logging message, performs duplicate elimination if necessary, and processes the message. Once it has completed, it sends an acknowledgement message back to the client.

For the purpose of this paper we won't discuss the whole standard as it is defined, but we discuss the key elements of it, in particular the features required for a reliable logging service.

First, we show the key elements contained in the logging request message:

• Message-ID: This is the sequence number assigned to a message before sending. This way the web service can eliminate duplicates in case a message has been submitted multiple times and can also guarantee -- if not ensured otherwise -- the proper message order.
• Ack-Requested: This element lets the client determine whether an acknowledgement should be returned for a message sent. In the case of a reliable logging web service, this flag must be turned on.
• Duplicate-Elimination: With this attribute the client can determine whether it wants the server to eliminate duplicates or not. In the case of a reliable logging web service, this flag must be turned on.

The only element in the reply message important for this purpose is the field Ref-To-Message-ID. This field contains the logging message's sequence number (Message-ID) that this acknowledgement message is acknowledging.

Having listed those few elements you can already see that the WS-Reliability specification covers three of the requirements listed in the section "Requirements for reliable logging." All the features listed above provide solutions on a reliable messaging protocol level. It does not provide solutions or solution approaches on the application level, such as the fourth logging requirement listed. It does, however, provide the basis for a solution of the application layer problems.

In the following sections we identify failures that can occur on the application level and outline an architectural solution to tackle these.

Back to top

Reliability issues with logging on the application layer

In order to be able to identify reliability issues on the application layer let’s revisit the logging scenario shown in Figure 3:

1. A client sends logging request to server
2. Server receives logging request
3. Server persists logging request
4. Server sends acknowledgement to client
5. Client receives acknowledgement from server

The flow described above principally provides a mechanism for reliable messaging: a client sends a logging request and the server sends an acknowledgement once it has persisted the message. However, this is not completely fail-safe because there are scenarios where the process described will break, and consequently no acknowledgement message will be returned to the client:

• What if the client can't locate the server?
• What if the request message gets lost?
• What if the server crashes? Before or after logging the message?
• What if the acknowledgement message gets lost?
• What if the client crashes?

In each one of the cases listed above you want to be sure that the message gets persisted and that the client receives an acknowledgement. In some of the cases this isn't easily possible. We explore some of these cases below.

Client can't locate the server

If the client can't locate the server it causes the logging service to fail. However, this is an issue that can be controlled on the client side and, therefore, no particular mechanism on the server side or on the protocol level is required to remedy this situation.

As defined above, logging messages must not get lost after those have been submitted to the logging server by the logging client. In cases where the client can't locate the server, the following two scenarios are likely:

1. The server is unavailable temporarily.
2. The server is, or seems to be, unavailable permanently.

One of the base design assumptions is to keep the unavailability of the server as transparent to the business application as possible.

In the first case, the logging client is able to keep the unavailability of the server transparent to the business application. Here, the logging client keeps resending the logging message (using the same sequence number) received from the business application to the logging server for a defined number of attempts -- n. If the client experiences a temporary server outage, the server processes the logging message as soon as it is back up.

If the server can't be contacted after n attempts, the client can safely assume that the server is unavailable permanently and needs to report this situation back to the business application invoking the client.

The request message gets lost

Messages between the client and the server can get lost under certain circumstances. For example, this might be the case if a packet oriented transport protocol is used or if a message is transmitted over a chain of hops and one of the hops breaks.

The design feature enabling the client to determine whether the request message got lost is the acknowledgement message. If a request message got lost on the way to the server, or if the server crashed before processing it, the client doesn't receive an acknowledgement message.

In order to hide temporary outages between the client and the server the client resubmits the message n times. If the outage persists, the client stops resubmitting the logging message after n resubmits and reports the error back to the business application calling the client.

The server fails

If the server fails, the client gets no acknowledgement message from the server. There are two possible scenarios:

• The server crashes after receiving and before persisting the message.
• The server crashes after persisting the message and before sending the acknowledgement.

In both cases you want the client to be able to resubmit the logging messages to the server without those getting processed multiple times, as you want any faults occurring on the server to be transparent to the client.

In the first case, the client can simply resubmit the message and no particular action need be taken on the server as the message has not yet been processed.

If you think through the second scenario, you notice that a logging message sent gets processed twice as it has already been logged when the logging message was submitted for the first time. Here, the client needs to be able to resubmit the logging message without the server logging it twice. In order to solve this problem, the server needs to contain a state to be able to determine that the message sent was already processed, but that no acknowledgement was sent.

The architectural solution put in place for this scenario on the protocol layer is the message sequence number, or Message-ID as it is referred to in WS-Reliability. With the help of the message sequence number and a server-side persistence log, the server is able to identify duplicates.

Based on this architecture, you can see that the logging web service works as required without processing already submitted messages multiple times. A logging client submits a logging message to the server. The server receives the message and checks the persistence log to see if the message was previously processed. If not, in other words an entry does not exist, the server processes the log message and, if successful, creates an entry in the persistence log before the acknowledgement message is sent. If the message was already processed, in other words an entry exists in the persistence log, the server doesn't process the message and sends the acknowledgement immediately.

Make sure that, with the solution put in place, the file-system containing the persistence logs can't overrun.

The acknowledgement message gets lost

Like logging messages, acknowledgement messages can also get lost for the same reasons. Here as well, the client can't tell where exactly the failure occurred. However, by making the server fault-tolerant, as discussed above, the client can simply resubmit the log message and wait for the acknowledgement message to arrive.

In order to separate temporary failures from permanent failures, the client can employ the same strategy as described above. The client submits the log message n times. If no acknowledgement is received after n times, the client can safely assume that the system experienced a permanent problem and can report the problem back to the caller, or the business application.

The client crashes

In the case of reliable logging, the logging client needs to be an integral part of the business application. Many operations or every operation on the business application is coupled with a logging operation. Due to the synchronous nature of the logging client, the business application needs to fail in case the logging application fails.

Back to top

Proposed Architecture

Components

Considering what has been discussed in the sections above, we arrive at the architecture shown in Figure 4.

The client provides an API through which the business application can access the logging client. The controller contains the operational logic of the logging client. At the bottom layer on the client side you find the communication API that the logging client uses, implementing the transport protocol used.

The server contains a communication API for communication with the client, a persistence log for storing the state, and the log message store. To cover the business rules identified in the sections above, the controller component clamps together all of these components.

Correlating logging requirements and architecture in place

Before we conclude this section, let’s see how the architecture in place covers the logging requirements stated above.

• Allows guaranteed message delivery: The request/acknowledgement protocol enables the client to determine whether a message transmitted has been delivered.
• Eliminates duplicate messages: Since the server contains a state even duplicate messages can be identified.
• Guarantees message order: Since the logging client is of a synchronous nature and no new logging messages are being transmitted before an acknowledgement for the previous message has been received, the log messages are inherently processed in the correct order.

Message numbering

One design aspect that has not been discussed yet, but is an integral part of the architecture proposed, is message numbering. The best approach for message numbering for the architecture proposed is to combine the HTTP session-identifier with the timestamp of the point in time the message was submitted. This guarantees that different messages will have unique sequence numbers -- due to the timestamp -- and the server is able to identify which messages came from which client (important for duplicate elimination and uniqueness across concurrent clients) by using the HTTP session- identifier.

Back to top

Logging with transactional semantics

A transactional runtime environment assures atomicity, consistency, isolation, and durability of applications. This has the effect that concurrently running applications that access common resources are protected against system crash and errors that come from resource conflicts. If an application crashes, its operations are backed out (atomicity). If an application succeeds, all of its operations are guaranteed to survive (durability). The transactional system can guarantee that the resources remain consistent, even if they are accessed concurrently (consistency). The system can also guarantee that applications need not take care of other applications running; they can act as if they were running alone (isolation).

Logging is a vital part of applications, and there are at least two kinds of logging activities. Informational logging is needed to track an application’s steps and operations. Depending on the purpose of informational logging, it might be more or less critical for the successful operation of applications. If, for instance, log records are input to statistical analysis, a low number of failed log operations might be tolerated. If log files are used for auditing purposes, missing log entries might not be tolerated.

The other kind of logging, called business-critical, influences other parts of the system in a business-relevant sense. That means that other applications read business critical log records and use them for their business logic. This kind of logging activity is to be treated as carefully as the other business operations of applications. An example is a financial log record, where money transfers are logged and the log is used for interest calculation or fee collection.

In this paper, we define a log service with some transactional semantics and concentrate on the atomicity semantics. That does not mean we try to force all logging activity to be treated as part of an atomic transaction, but we give applications the ability to specify for each log message whether it is transaction-critical or not.

Transactional executions

If several applications run concurrently, and each of them executes some operations in a serial order, an overall system execution consists of various operations from various applications, in some order. If the applications access common data, they have potential conflicts which can cause inconsistencies. The notations of consistency and predicate locks in a database system (see Resources) gives a precise definition of consistency in such a concurrent environment. Concurrency Control and Recovery in Database Systems (see Resources) gives the properties of successful executions, which, if fulfilled, prevent a system from producing inconsistencies.

Atomicity

Atomicity is perhaps the most basic property of successful transaction executions. A transaction’s execution is called atomic if either all of it's update operations succeed or all fail. This is often called the all-or-nothing property as well. If you assume that one transaction is always a consistent piece of work, it is clear that the system remains consistent if all of its updates are applied. When the execution of a transaction is started but not yet finished, and only a part of its updates are actually done, you can't assume that the overall system’s state is consistent. You can assume consistency for the whole system only if all of the transactions are either executed completely or not at all.

Atomicity, as a basic transaction property, is implemented in various systems. In distributed systems, atomicity means also that a transaction should succeed either in all or in none of the participating nodes. To make this happen, the 2-phase-commit protocol was invented (see Principles of Distributed Database Systems in Resources) and is also implemented in various systems.

Atomic Logging Operations

You can divide logging operations into three categories:

1. A log operation might not participate in atomicity at all. The failure of a log operation does not cause the transaction to fail, and the log operation can succeed even if the transaction itself is aborted. This category of log operations does not consume transaction manager resources nor does it require the log service to be aware of transactions.
   
   
2. Log operations can be treated as well as other updates to participate in atomicity. This requires that the transaction be rolled back if the log operation fails and that the log operation succeed only if the transaction succeeds as a whole.
   
   
3. Log operations can be treated in a semi-atomic manner. The log operation succeeds only on transaction commit, but a failure of the log operation doesn't cause the transaction to abort. In that case, some log records could be missing, but the log device is not polluted with records from aborted transactions. In other words, there are no dirty log records. This variant is a compromise between atomicity and cost of transaction overhead. Be aware that no normal transaction operation is affected if such a log message should fail, but the log message itself is affected by the transaction's failure.

Web services are a relatively new messaging infrastructure for distributed computing. The transactional aspects of web services were not regarded for a while. Recently, the community came up with two proposals (Business Transaction and Web Services Transaction -- see Resources) of how distributed transactions can be coordinated within a web services architecture. We do not compare the two propositions here. Instead, we concentrate on the WS-Transaction specification because it is a more promising approach, but we invite you to read both to get his your own opinion. The WS-Transaction specification defines a protocol for 2-phase-commit among participants of distributed transactions, thus enabling atomicity.

WS-Transaction

The WS-Transaction specification applies to web services-based distributed systems. Applications communicate with each other and with the system's services through web services, and the same holds for communication between system services. The specification describes the protocols for atomic transactions in terms of web services descriptions. The protocols are the following:

• Completion: Applications use this protocol to initiate the distributed transaction's commit cycle.
  
  
• 2 Phase Commit: An application participating in a distributed transaction has to delay its updates at first. When completion is requested, a coordinator sends any participant a Prepare-message. After having received Prepare, each participant decides whether it can apply its updates that it had delayed so far, and responds with Prepared or Aborted. If all of the participants voted with Prepared, they all receive a Commit, which causes the updates to be applied. Otherwise, they receive the Abort message which causes all updates to be discarded.
  
  
• Phase Zero: Once a 2-phase-commit cycle starts, no application activity can be done any more, except the execution of the Prepare, Commit, or Abort. But imagine a service that holds some updates in a cache and wants to store them in a database at last, which requires a call to a database service. As it is forbidden to call the database service after having received a Prepare, how can the caching application store its cached data at the end but before the commit? Well, this is achieved by the phase zero-protocol, where the coordinator sends the PhaseZero message to the participants before starting a commit cycle.
  
  
• Outcome Notification: Some applications that are not part of a distributed transaction just want to know the outcome -- either Commit or Abort -- and can use the outcome notification protocol to get that information.

The WS-Transaction specification builds on another proposition, WS-Coordination (see Resources). Each of the above protocols is implemented as web services interfaces between a protocol coordinator and a protocol participant. Thus there is a 2-phase-commit coordinator service and a 2-phase-commit participant service, as well as a phase zero coordinator and participant service, and so on. Those coordinator and participant services are described as port types as defined by the Web Services Definition Language (WSDL) in the WS-Transaction specification.

Back to top

Architecture for a transactional logging service

Figure 5 shows the participating nodes and protocols, as well as their essential interactions. We suppose there are two application nodes (Appl1 and Appl2), a database node (DB), and a node containing a log service (LogService).

Nodes and their services

• Appl1 is the initiating application, and, because it wants to finish the distributed transaction, it registers with the coordinator for the completion protocol of the transaction. Thus it exposes the participant service for the completion protocol (P-c) and uses the coordinator’s service for the completion protocol (C-c). It also uses the log service (Logging) on the log service node, sending log messages with different atomicity levels. Furthermore, it sends application messages to node Appl2 and database requests to the database node DB.
  
  
• Appl2 is initiated by Appl1 and works on behalf of it. It caches some of its updates in local memory and wants to flush them into the database at the end. Therefore, it registers for the phase zero protocol with the coordinator and thus must expose the participant service of the phase zero protocol (P-pz).
  
  
• DB is the database node. It receives updates of the applications and therefore registers as a participant for the 2-phase-commit protocol. So it has to expose the participant service (P-2pc).
  
  
• LogService is the log service node. It receives log messages, each of which might require a certain atomicity level. If one of the log messages requires atomicity or semi-atomicity, the log service registers itself as a participant for the 2-phase-commit protocol and thus exposes the participant service of 2-phase-commit (P-2pc). Depending on caching strategy, it might also register for the phase zero protocol to flush log messages upon transaction completion.
  
  
• Coordinator is the WS-transaction coordinator node. It exposes the coordinator services of the completion, phase zero and 2-phase-commit protocols, C-c, C-pz, and C-2pc.

Sequence of Messages

We do not include here the messages for protocol registration for the various protocols between participants and coordinator because of space limitations, but you can find more information from the WS-Coordination specification (see Resources). In the following, assume that each node has already successfully registered itself with the coordinator for the protocols it uses.

It is essential to say that, for each message, a transaction coordination context as it is defined in WS-Transaction is included. Because message passing is in a web services environment, the transaction coordination context is contained in the SOAP header. The context in the specification is extensible; you want to extend it with an element indicating the required level of atomicity for log messages. The required level could be none, semi-atomic or atomic. Be aware that the transaction coordination context is part of each message, even messages between applications and messages from applications to the database service.

1. There are messages from one application to the other, from the applications to the database service, and from the applications to the log service. Each log message contains the required atomicity level within the transaction coordination context. The log server always checks the required atomicity level. If the required level is either atomic or semi-atomic, LogService does not persist the log message immediately. Instead, it keeps it in a safe area from where it can be retrieved during commit. If the atomicity level is none, the log message is written immediately to the permanent log media.
   
   
2. Node Appl1, the initiating application, decides to finish work and calls the coordinator’s completion service, C-c.
   
   
3. Before initiating the 2-phase-commit cycle, the coordinator calls the phase zero participant service of Appl2. In response to this message, Appl2 writes its cached updates using the database service and reports the success of phase zero to the coordinator. Should Appl2 fail to complete phase zero, the coordinator aborts the whole transaction.
   
   
4. If phase zero succeeds, the coordinator starts the 2-phase-commit cycle:
   • The Coordinatior calls the Prepare operations of the LogService and the db server. The logging server checks the logging device if it is ready to persist all log messages that require atomicity (not semi-atomicity), and reports Abort to the coordinator if this check fails. Otherwise, it reports Prepared. Sending Prepared to the coordinator is like a promise to be able to commit, so the log messages that require level atomic should be pre-persisted to stable storage so that a later Commit can be fulfilled even if the log service should crash in the meantime.
   • If every participant reports Prepared, the coordinator sends Commit to each of them. The logging server then persists all log messages that require atomicity or semi-atomicity. If finished, it reports Commit to the coordinator.

Coordination Context

In the WS-Transaction specification, a coordination context is defined as a container for transaction-specific header attributes. Listing 1 gives the structure of this coordination context, which is in the SOAP header. The context structure contains an element, <wscoor:CoordinationType>, denoting a kind of coordination, which is a URL for WS-Transaction. This means that this coordination context contains WS-Transaction protocol messages. Within this context, we introduce the new element, <logging:AtomicityLevel xmlns:logging="http://schemas.logging.org/logging">, from which the namespace is hypothetical. The content of this element is the atomicity level required for the logging message, which is either none, atomic, or semi-atomic.

<?xml version="1.0" encoding="utf-8"?>
<S:Envelope xmlns:S="http://www.w3.org/2001/12/soap-envelope">
<S:Header> 
. . . 
<wscoor:CoordinationContext 
    xmlns:wsu="http://schemas.xmlsoap.org/ws/2002/07/utility"
    xmlns:wscoor="http://schemas.xmlsoap.org/ws/2002/08/wscoor" 
    xmlns:logging="http://schemas.logging.org/logging"> 
  <wsu:Expires> 2002-06-30T13:20:00.000-05:00 </wsu:Expires> 
  <wsu:Identifier>http://Fabrikam123.com/SS/1234</wsu:Identifier>
  <wscoor:CoordinationType>
      http://schemas.xmlsoap.org/ws/2002/08/wstx 
  </wscoor:CoordinationType>
  <wscoor:RegistrationService> 
  <wsu:Address>
      http://Business456.com/registration               
  </wsu:Address> 			
  ...
  </wscoor:RegistrationService> 
  <logging:AtomicityLevel>semi-atomic</logging:AtomicityLevel> 
</wscoor:CoordinationContext>
... 
</S:Header>
		

Back to top

Conclusion

This paper demonstrated that logging is an important part of today's business applications and needs to be treated with great care, just like any other business-relevant piece of an application. If businesses require logging as an integral part of their processes and enterprise, a centralized logging service makes sense and is an ideal candidate for a logging web service

Back to top

Further work

This paper focused on two important design aspects for distributed systems applied on a logging web service. However, for crucial logging applications other design aspects, such as performance, scalability, and security, are of equal relevance and build the basis for future work in this area.

Resources

• You can find the following specifications and standards on developerWorks:
  • Web Services Transaction (WS-Transaction)
  • Web Services Coordination (WS-Coordination)
  
  
  
• Download the WS-Reliability standard from the Oracle(TM) technology network.
  
  
• Learn more about the Business Transaction Protocol, an OASIS Committee Specification.
  
  
• Refer to the following books for more information on the material in this paper:
  • Distributed Systems -- Concepts and Design by G. Coulouris, J. Dollimore, and T. Kindberg (2002)
  • Concurrency Control and Recovery in Database Systems by P. Bernstein, V. Hadzilocs and N. Goodman (1987)
  • Principles of Distributed Database Systems 2nd. ed by M. Tamer Özsu and Patrick Valduriez (1999)
  • Distributed Systems -- Principles and Paradigms by A. Tanenbaum and M. v. Steen (2002)
  
  
  
• You can find more related information in the following resources:
  • Reliable message delivery in a web services world : A proposed architecture and roadmap (developerWorks, March 2003)
  • A comparison of web services transaction protocols (developerWorks, October 2003)
  • Approaching web services transactions (developerWorks, February 2003)
  • Transactions in the world of web services, Part 1 (developerWorks, August 2002)
  • Transactions in the world of web services, Part 2 (developerWorks, August 2002)
  • Tour Web Services Atomic Transaction operations (developerWorks, September 2004)
  
  
  
• Access web services knowledge, tools, and skills with Speed-start web services, which offers the latest Java-based software development tools and middleware from IBM (trial editions), plus online tutorials and articles, and an online technical forum.
  
  
• Browse for books on these and other technical topics.
  
  
• Want more? The developerWorks SOA and web services zone hosts hundreds of informative articles and introductory, intermediate, and advanced tutorials on how to develop web services applications.
  
  

About the authors

Rate this article

Comments

Back to top

Table of contents

• Introduction
• Fault tolerance and reliability issues with logging
• WS-Reliability standard
• Reliability issues with logging on the application layer
• Proposed Architecture
• Logging with transactional semantics
• Architecture for a transactional logging service
• Conclusion
• Further work
• Resources
• About the authors
• Comments

Local resources

• IBM Innovation Center - Austin, TX
• IBM Innovation Center - Chicago, IL
• IBM Innovation Center - Dallas, TX
• IBM Innovation Center - San Mateo, CA
• IBM Innovation Center - Waltham, MA
• Technical Briefings in North America

Dig deeper into SOA and Web services on developerWorks

Try IBM PureSystems. No charge.

Experience today!

---

Get started with the cloud-based trial and pattern development kit.

Special offers