Kz2519141921

R.Soujanya, Guide: K.Venkateshwarlu / International Journal of Engineering Research and
Applications (IJERA) ISSN: 2248-9622 www.ijera.com
Vol. 2, Issue 5, September- October 2012, pp.1914-1921
The Transaction Concept: Integrated With BPEL and WS-AT,
WS-BA Coordination Protocols
R.Soujanya (M.Tech) Guide: M.Venkateshwarlu M.Tech
Department of SE, Department of CSE,
Sri Kottam Tulasi Reddy Memorial College, Associate Professor CSE Department,
Kondair. Andhra Pradesh. Sri Kottam Tulasi Reddy Memorial College,
Kondair. Andhra Pradesh.

ABSTRACT remote operation invocation is not the revolution
Service-Oriented Computing (SOC) is brought by Service-Oriented Computing (SOC),
becoming the mainstream development paradigm
of applications over the Internet, taking though. Rather, it is the possibility of having
advantage of remote independent functionalities. programs that perform complex tasks coordinating
When the control over the communication and and reusing many loosely coupled independent
the elements of the information system is low, services.
developing solid systems is challenging. In
particular, developing reliable web service Business processes are now able to execute
compositions usually requires the integration of seamlessly across organizations and to coordinate
both composition languages, such as the Business the interaction of loosely coupled services. Often it
Process Execution Language (BPEL), and of is necessary to have transactionality for a set of
coordination protocols, such as WS-Atomic business operations,
Transaction and WS-Business Activity. But the loosely nature of such systems calls for
Unfortunately, the composition and coordination techniques and principles that go beyond traditional
of web services currently have separate languages ACID transactions.
and specifications.
The goal of this paper is twofold. First, In the present treatment, a service is a
we identify the major requirements of transaction standard XML description of an autonomous
management in Service-oriented systems and software entity, it executes in a standalone container,
survey the relevant standards. Second, we it may have one or more active instantiations, and it
propose a semiautomatic approach to integrate is made of possibly many operations that are
BPEL specifications and web service invoked asynchronously. A service composition is a
coordination protocols, that is, implementing set of operations belonging to possibly many
transaction management within service services, and a partial order relation defining the
composition processes, and thus overcoming the sequencing in which operations are to be invoked.
limitations of current technologies. Such a partial order is adequately represented as a
direct graph. A service transaction is a unit of work
Keywords: Web services, transaction comprehending two or more operations that need to
management, WS-Business Activity, WS-Atomic be invoked according to a specific transaction
Transaction, ACID properties, Service policy. The coordination of a service transaction is
composition languages, and Business process the management of the transaction according to a
execution language. given policy. A service transaction can span over
operations of one service or, more interestingly, of
1. INTRODUCTION several services.
The widespread adoption of Web services
is feeding the promises of the new field of Service One may argue that transaction
Centric Systems. As Service Centric (SC) Systems management is a well-known Technique for the new
are being increasingly adopted, new challenges and features of transactions executed by web services;
possibilities emerge. Standardized web service various web transaction specifications have been
technologies are enabling a new generation of developed. WS-Coordination [1] specification
software that relies on external services to describes an extensive framework for providing
accomplish its tasks. The remote services are usually various coordination protocols. The WS-
invoked in an asynchronous manner. They are AtomicTransaction (WS-AT) [2] and WS-Business
known by their published interfaces, and await Activity (WS-BA) specifications [3] are two typical
invocations over a possibly open network. Single web transaction protocols. They leverage WS-
Coordination by extending it to define specific

1914 | P a g e

coordination protocols for transaction processing. effects should be durable in time. Given the nature
The former is developed for simple and short-lived of Service-Oriented Systems, satisfying these
web transactions, while the latter for complex and properties is often not possible and, in the end, not
long-lived business activities. Finally, the Business necessarily desirable. In fact, some features are
Process unique to Service-Oriented Systems:
Execution Language (BPEL) [4] is a  Long-lived and concurrent transactions, not
process-based composition specification language. only traditional transactions which are
In order to develop reliable web services usually short and sequential.
compositions, one needs the integration of  Distributed over heterogeneous
transaction standards with composition language environments.
standards such as BPEL [5], [6]. Unfortunately,  Greater range of transaction types due to
these are currently separate specifications. different types of business processes,
service types, information types, or product
This paper has a double goal: the first one is flows.
to look at the requirements of transaction  Unpredictable number of participants.
management for Service-oriented systems. The  Unpredictable execution length.
systematization of requirements is the starting point For example, information query and
for an analysis of current standards and technologies flight payment need 5 minutes; while e-
in the field of web services. The second goal of the shopping an hour; and a complex business
paper is to propose a framework for the integration transaction like contracting may take days.
of BPEL with transaction protocols such as WS-  Greater dynamism. Computation and
AtomicTransaction and WS-Business Activity. We communication resources may change at
use a simple but representative example across the runtime.
paper, the drop-dead order (DDO) one, to illustrate
 Unavailability of undo operations, most
requirements and the proposed approach. often only compensating actions that return
the system to a state that is close to the
2. The Drop Dead Order Example initial state is available.
The drop-dead order describes a scenario
Furthermore, transactions may act differently when
where a customer wants to order products from a exposed to certain conditions such as logical
distributor under the condition that the products are
expressions, events expressed in deadlines, and even
delivered before the drop-dead date (Figure). errors in case of a faulty web service. To make sure
In the scenario, the distributor tries to find a
that the integrity of data is persistent, the two
supplier that has the products available. If he finds
transaction models used are, namely, Composite and
such a supplier, he will search for a carrier that is
distributed that allow smooth recovery to a previous
able to deliver the products before the drop-dead
“safe” state.
date. If both the supplier and the carrier are able to
The set of emerging features mentioned
fulfill the demands of the customer, the distributor
earlier, which combinations of requirements are
reports to the customer that he can fulfill the order. mostly coming from the areas of databases and
After the customer has acknowledged, the distributor workflows provide the basis for identifying the most
sends a confirmation to the supplier and the carrier. relevant requirements for transactions in Service-
Oriented Systems.
FIGURE: The Drop Dead Order Example
3.1 ACID Properties
3.1.1 Atomicity
Atomicity is the property of a transaction to
either complete successfully or not at all, even in the
event of partial failures.
3.1.2 Consistency
Consistency is the property of a transaction
to begin and end in a state which is consistent with
the intended semantics of the system, i.e., not
breaking any integrity constraints.
3.1.3 Isolation
3 TRANSACTION REQUIREMENTS Isolation is the property of a transaction to
In the field of databases, transactions are perform operations isolated from all other
required to satisfy the so-called ACID properties, operations. One transaction can therefore not see the
that is, the set of operations involved in a transaction other transaction‟s data in an intermediate state.
should occur atomically, should be consistent, 3.1.4 Durability
should be isolated from other operations, and their Durability is the property of a transaction to
record the effects in a persistent way. Whenever a

1915 | P a g e

transaction notifies one participant of successful application memory by locking it in the transaction
completion, the effects must persist, even when for the entire time. While the optimistic simply
subsequent failures occur. chooses to detect collisions and then resolves the
3.2 Transaction Behaviors collision when it does occur. This scheme has better
3.2.1 Rollback performance. When two transactions are concurrent,
Rollback is the operation of returning to a they should not both claim the same supply of goods
previous state in case of a failure during a from one Supplier.
transaction. This may be necessary to enforce
consistency. TRANSACTION STANDARDS AND
3.2.2 Compensating Actions SERVICE COMPOSITION LANGUAGES
Compensating actions are executed in the WS-Transactions and Business Transaction
event of a failure during a transaction, all changes Protocol (BTP) are the two most representative
performed before the failure should be undone. standards that directly address the transaction
3.2.3 Abort management of web service-based systems, while
Abort is the returning to the initial state in for representing compositions of services, the
case of failure or if the user wishes so. Business Process Execution Language and the
3.2.4 Adding Deadlines Choreography Description Language (WS-CDL) are
Adding deadlines to transactions involves most widely known and adopted. WS-Transactions
giving timeouts to operations. consist of two coordination protocols: WS-Atomic
3.2.5 Logical Expressions Transaction and WS-Business Activity which live in
Logical expressions for specifying the WS-coordination framework. WS-AT provides
constraints are used for giving unambiguous and the coordination protocols for short-lived simple
semantically defined rules for guaranteeing operations, while WS-BA provides the coordination
consistency. protocols for long-lived complex business activities.
The WS-coordination framework is extensible and
3.3 Transaction Models incremental. That is, WS-coordination can enhance
3.3.1 Composite Transactions existing Service-Oriented Systems with transaction
Composite transactions are nested properties by wrapping them with a specific
transactions. These transactions depend on the coordination.
global outcome, that is, all three succeed or the BTP is a model for long-lived business
whole composite transaction fails. transaction structured into small atomic transactions,
3.3.2 Distributed Transactions and using cohesion to connect these atomic
Distributed transactions are transactions operations. Its motivation is to optimize the use of
between two or more parties executing on different resource involved in a long-lived transaction under
hosts. The transaction should support transactions loosely coupled web service environments and
through a network between two different hosts. avoiding the use of a central coordinator.
BPEL provides the facilities to specify
3.4 Transaction Behavior—Alternatives executable business processes with references to
3.4.1 Transaction Recovery services‟ interfaces and implementations. It does
Transaction recovery by dynamic rebinding handle some basic issues of transactions, such as
and dynamic recomposition at runtime is the compensation, fault, and exception handling, but
possibility of replacing a faulty web service when other transaction requirements are not managed.
the current service is not able to fulfill its promises. WS-CDL provides the infrastructure to describe
Dynamic recomposition is the forming of a new cross-enterprise collaborations of web services in a
composition by replacing one or several services by choreographic way.
another composition that fulfills the same function. Consider the proposed protocols that take
Imagine that the first Carrier somehow fails and is the transaction and the business perspective of
unreachable. If this happens during a transaction, Service-Oriented Systems with respect to the
then automatic rebinding with a service that offers requirements. In Table 1, we summarize the results
the same service should take place. Recomposition of the evaluation for all requirements—each row—
through rebinding with a third Carrier through the and for all protocols—each column—by denoting
Supplier is also a possibility. the satisfaction with the “⨁” symbol, the partial
satisfaction with “⨀” and no support with ”Ө”.
3.4.2 Optimistic or Pessimistic Concurrency
Control
Optimistic or pessimistic concurrency
control refers to the support of different types of
concurrency control to enforce consistency. This
control could either be optimistic or pessimistic. The
pessimistic approach prevents an entity in

1916 | P a g e

The above survey shows that there are
standardized protocols for describing transactions
and languages for describing processes in terms of
TABLE-1 Evaluation Results flows of activities. The connection among these is,
to say the least, very loose. The problem is that
processes are described in terms of activities and
roles capable of executing the activities, but
semantic dependencies among these activities are
not represented beyond message and flow control. It
may happen that several operations from a single
web service are invoked within a BPEL process, and
dependencies among these operations may exist.
Our proposal consists of making the
dependencies among the activities explicit via an
automatic procedure and performing a restructuring
step of the process, where necessary. The identified
dependencies among activities can be then identified
by the designer of the process as being transactions
or not. In case they are, the designer will decide
which kind of transactions they are and simply
annotate them. The execution framework then takes
care that transaction annotations are correctly
managed at runtime. The need for the human design
WS-AT is a traditional protocol which
decision in the process is necessary due to the lack
satisfies the basic ACID properties. WS-BA, on the
of semantic annotations of the BPEL processes.
other hand, renounces atomicity to accommodate
Only the designer can decide whether a set of
long-lived transactions. BTP has included confirm
activities that seem to have a dependency in the
sets. These confirm sets let the application element
process are to be executed transaction ally or not.
choose which operations with parties in the
transaction are to be canceled and which are to be
Fig 3 Approach to integrating transactions into
confirmed. In this way, the application element is
BPEL processes.
able to contact more services which perform the
same task and to choose the best option.
Unfortunately, BTP is not part of the WS-Stack,
which limits its compatibility with other web service
technologies. In addition, BTP does not support
long-lived transactions. There is also a difference in
granularity between the above transaction standards.
WSAT contains simple two-phase commit protocols,
WS-BA contains nonblocking protocols and BTP
consists of a Sequence of small atomic transactions.
As for security, WS-Security can be combined with
WS-Transaction as well as with BTP.
Dynamic rebinding is supported only by
BPEL, though only at the implementation level. WS-
CDL supports most requirements, while its major
disadvantage is that the large players in the field do
not support it and that no implementation is
available. Consider Fig. 3, where data transformation
WS-AT is a very conservative business goes from left to right and we distinguish three
transaction model especially with respect to layers: the data layer at the bottom, the middle
blocking. WS-BA is more appropriate for services, execution layer defining the data transformation, and
by renouncing to the concept of the two-phase the knowledge level indicating from where the
commit. BTP places itself in the middle (two-phase knowledge to transform the data comes. We start
commit is followed in a relaxed way). As for BPEL with a generic business process designed to solve
and WS-CDL, they address the business process some business goal. An automatic processing step,
perspective with limited transaction support. which we define next, identifies dependencies
among activities. These are then reviewed by an
5 PROPOSALS FOR INTEGRATING expert that decides which actually transactions are
TRANSACTIONS INTO BPEL and which not. For those who qualify, he further
decides what kind of transactions they are and

1917 | P a g e

annotates them. For instance, some may be long Figure 4: Representation of activities and the link
running while others may be atomic ones. We that connects them.
remark how this is a design step performed by an
expert who understands the domain, the specific
process, and the consequences of choosing a
transaction policy in favor of another. This step
cannot be automated unless further semantic
annotations are made on the BPEL. The restructured
and annotated process is then ready to be sent for
execution. Next the execution phase and will be
handled by the execution framework. We consider
the three phases of the approach individually.

5.1 Preprocessing
Preprocessing the BPEL specification is
performed in two steps, namely, 1) identification and
2) resolution of transaction dependencies. In order to
illustrate the two steps, we introduce an abstract
model of BPEL.

5.1.1 Abstract Model of BPEL Specifications
A BPEL process specification describes the
interaction between services in a specific composite
web service. Its abstract model, known as behavioral
interface, defines the behavior of a group of services
by specifying constraints on the order of messages to
be sent and received from a service.
A BPEL specification „S‟ is a set of
activities „A‟ and its associated links „L‟, represented
by S = (A, L). The links, which are directed, define a 5.1.2 Dependencies Identification Algorithm
partial ordering over the set of activities and are thus
well represented as a directed graph (e.g., Fig. 4). If one specifies a set of activities within a
 An activity „a‟ in A having a type represented given BPEL specification S, there may exist
by Ta, has the following properties: dependencies among activities that can hinder the
- Name Na. application of transaction management as described
- Operation OPa, which is usually implemented above. Assume that
by the web service at a specific port. St = { ai│ ai is a transactional activity of a
- Input variable IVa and output variable OVa, transaction t} is a transaction t specified within the
which specify the parameters required and BPEL specification S.
produced by the OPa, respectively. For any two activities am and an where am,
- Set of source links SLa and set of target links 𝒍𝒋𝟏 𝒍𝒋𝒌
an ∈ St and am ≠ an, if there exists a path am ….
TLa, which specify the outgoing and incoming
links (transitions), respectively. an where lj1 and ljk are some links connecting
activities, we say that an is reachable from am,
A link l in S has a unique name Nl and is ∗
indirectly defined through two activities a1 and denoted as am an, and {lj1…. ljk} is a link chain of
∗ ∗
a2 which indicates not only the direction ld of am an denoted as LC { am an }. For any two
the transition, but also the conditions lc for the activities am and an in a transaction St that are
transition to take place. ∗
implemented by the same web service, if am an
Furthermore, the Customer-to-distributor ∗
link lc-d is one of the source links of the and OVam ∈ lc where l ∈ LC {am an}, then a
ReceiveOrder activity a1, namely, lc-d ∈ SLa1. transaction dependency exists between am and an.
Furthermore, lc-d ∈ TLa6, where TLa6 is the target To identify the existence of transaction dependencies
link of the CompleteDistribution activity a6. within a given BPEL specification S, we propose
Therefore, the link lc-d connects the transition Algorithm 5.1.
between a1 and a6, denoted as
𝒍𝒄−𝒅
a1 _ → a6. Fig. 4 provides an illustration of
𝒍𝒄−𝒅
a1 → a6.
_

1918 | P a g e


5.2 Declaration of Transaction Policies

Once transactions are identified and BPEL
has been accordingly restructured, one needs to
The algorithm is a standard graph algorithm define the desired transactional behavior. To this
similar to those for reachable set construction. The end, we introduce a reference transaction policy
function IdentifyDependency takes S as input and declaration schema, shown in Fig. 7.
outputs a Boolean value that represents the existence With this schema, one can declare the
of transaction dependencies. The function first transaction policy using the following elements:
creates a path p for any two activities am and an. 1. Trans ID is a nonzero integer, representing
Then, traverses the links in the link chain ls obtained transactions within a business process.
from p. When a link l is detected and its transition 2. Trans Protocol specifies a protocol for the
condition lc contains the output variable OVam of the transaction, such as WS-AtomicTransaction or WS-
first activity am, or if it contains an output variable BusinessActivity.
OVai which is identical to OVam semantically, the 3. Trans Root indicates the parent transaction
algorithm stops and returns TRUE. Otherwise, it identified by Trans_ID. The value 0 is used to
continues until all pairs of activities in St have been indicate the root transaction within the business
visited. Finally, if no transaction dependencies are process. One can specify the hierarchy of
detected, the algorithm returns FALSE. transactions by assigning appropriate Trans_IDs and
Trans_Roots.
5.1.3 Resolution of Dependencies With such a schema, one can annotate
Once transaction dependencies are constraints or preferences to a specific activity in the
identified, it is necessary to handle them. To solve BPEL specification. The annotated activity must be
this problem, we merge the dependent activities into an invoke activity. One can separately specify the
one transaction. Algorithm 5.2 resolves the desired constraints or preferences in the design-time-
transaction dependencies within a BPEL info or runtime-info sections. For transaction
specification S. It employs Algorithm 5.1 to detect management, we declare the transaction policies in
transaction dependencies and it asks the user for the section of the transinfo which is embedded
confirmation that it is indeed a transactional within the section of runtime info, since a
dependency. The output is a new transaction policy is a runtime constraint. Together
BPEL specification referred to as preprocessed with the other types of process information,
BPEL where conflicts are resolved. transaction policies are stored in an XML file for use
at runtime.

1919 | P a g e

Figure 7: A transaction policy declaration schema. T.M. happens just before the binding.
Currently,ODE and ActiveBPEL are two
BPEL engines supported by the SCENE
platform.
 The Event Adapter maps the low-level
events from the BPEL engine onto the
binding-related events. The first version of
SeCSE event adapter is extended to support
the mapping of transaction-related events.
 The Transaction Manager is a separate
component in the executor and deployed in
the Mule container (Mule is a messaging
platform based on ideas from Enterprise
Service Bus (ESB) architectures).
The Transaction Manager consists of the following
two transaction-specific components:
5.3 The Execution Framework - TransLog is responsible for managing the lifecycle
The proposed approach transforms a of transactions, such as creating transaction
generic business process into a restructured one in
instances, maintaining the status of transaction
which transactions are identified and annotated. instances, and destroying transaction instances.
Now, one needs an execution framework that is TransLog is also responsible for transferring the
richer than a simple BPEL engine. In fact, one needs information among the components in the executor.
to interpret the annotations, make sure that activities For example, it listens the transaction-
are executed according to the transaction conditions related events from the Event Adapter, and it is
and also that the binding among dependent activities responsible for the communication between
is consistent with the transaction semantics. To
Transaction Manager and JBoss Transaction Server.
achieve this, we rely on the Service Centric System
- PolicyOperator retrieves the transaction policies
Engineering (SeCSE) platform in the context of
from the XML file, and parses the transaction
which the current approach has been developed. policies, and then maps transaction policies onto the
Service Centric System Engineering is a
coordination context. It provides a set of APIs which
European sixth framework integrated project, whose are to be called by the TransLog.
primary goal is to create methods, tools, and
techniques for system integrators and service As for the implementation of transaction
providers and to support the cost-effective protocols, we rely on JBoss Transaction Server.
development of service-centric applications. The JBoss Transaction Server is an open source
SeCSE service composition methodology supports implementation of WS-Coordination,
the modeling of both the service interaction view
WSAtomicTransaction, and WS-BusinessActivity. It
and the service process view. A service integrator
provides a set of APIs to support the coordination
needs to design both the abstract flow logic and the services and transaction protocols. JBoss
decision logic of the process-based composition. Transaction Server is selectedfor this purpose
Therefore, the SeCSE composition language allows because it 1) is a complete, standalone, open source
the definition of a service composition in terms of a software tool, 2) has sufficient documentation and 3)
process and some rules that determine its dynamic and supports WS-Coordination and WS-Transaction.
behavior. Correspondingly, the flow logic can be
represented by a BPEL specification, while the
decision logic is defined by rules.
6. CONCLUSION:
Web services are being increasingly
Based on the architecture of the SeCSE
adopted by organizations in order to run their
platform, we built a transaction management tool
business more effectively and efficiently. However,
called DecTM4B. It consists of three modules,
current technologies lack the support often required
namely,
by such organizations. The success of web services
 The Preprocessor for Transaction
lies, among other factors, in their reliability,
Management is used to identify and
especially when economic interests are involved.
eliminate transaction dependencies
One key feature is that of being able to deal
occurring in the original BPEL
transactionally with a set of operations, but this is far
specification. The output is the
from being easy, especially when the operations in
preprocessed BPEL specification. The
the transaction come from different remote service
SeCSE platform will deal with the binding
instances.
of abstract services before the BPEL engine
In this paper, we highlight the key requirements of
executes the BPEL specification. The
transaction management in Service-Oriented
preprocessing executed by Preprocessor for
Systems and propose a novel declarative transaction

1920 | P a g e

management approach for web service compositions. Proc. 19th Int‟l Conf. Very Large Data
The key to implementing transaction management Bases, R. Agrawal, S. Baker, and D.A. Bell,
into BPEL processes is to consider the combination eds., pp. 581- 591, 1993.
of business logic with transactions, taking into 10) C. Sun and M. Aiello, “Requirements and
account the challenges that make it impossible to Evaluation of Protocols and Tools for
directly apply transaction models to all Transaction Management in Service Centric
BPEL processes. Systems,” Proc. Ann. Int‟l Computer
The proposal consists of first a Software and Applications Conf.
preprocessing of the BPEL to identify and manage (COMPSAC ‟07), pp. 461-466, 2007.
transaction dependencies among a group of 11) A. Lazovik, M. Aiello, and M. Papazoglou,
activities. Then, it proceeds with the annotation with “Planning and Monitoring the Execution of
transaction policies. Finally, the interpretations of Web Service Requests,” Int‟l J. Digital
the declared transaction policy are specified as Libraries, vol. 6, no. 3, pp. 235-246, 2006.
event-action condition rules to be processed at 12) M. Aiello and A. Lazovik, “Monitoring
runtime. Assertion-Based Business Process,” Int‟l J.
Cooperative Information Systems, vol. 15,
REFERENCES no. 3, pp. 359-390, 2006.
1) WS-C, “Web Services Coordination (WS- 13) B. Haugen and T. Fletcher, “Multi-Party
Coordination),” technical report, Arjuna Electronic Business Transactions. Version
Technologies Ltd., BEA Systems, Hitachi 1.1,” technical report, UN, 2002.
Ltd., IBM, IONA Technologies, and
Microsoft, 2007. AUTHOR BIOGRAPHIES:
2) WS-AT, “Web Services Atomic
Transaction (WS-AtomicTransaction),
Version 1.1,” technical report, Arjuna
Technologies Ltd., BEA Systems, Hitachi
Ltd., IBM, IONA Technologies, and R.Soujanya received her B.Tech,
Microsoft, 2007. Degree in Computer science and information
3) WS-BA, “Web Services Business Activity technology from G.Pulla Reddy Engineering
Framework (WSBusinessActivity), Version College, Kurnool India, in 2010. She is pursuing
1.1,” technical report, Arjuna Technologies her M.Tech in Software Engineering in Sri Kottam
Ltd., BEA Systems, Hitachi Ltd., IBM, Tulasi Reddy Memorial College, Kondair India. Her
IONA Technologies, and Microsoft, 2007. area of interest is in the field of Service oriented
4) BPEL, “Business Process Execution computing, Wireless Sensor Networks and Software
Language for Web Services Version 1.1,” Testing.
technical report, IBM, Microsoft, BEAT,
SAP, and Siebel Systems, 2003.
5) C. Sun and M. Aiello, “Requirements and
Evaluation of Protocols and Tools for
Transaction Management in Service Centric
Systems,” Proc. Ann. Int‟l Computer
Software and Applications Conf.
(COMPSAC ‟07), pp. 461-466, 2007. Mr.M.Venkateshwarlu Associate Professor,
6) A. Erradi, P. Maheshwari, and V. Tosic, completed B.Tech in Computer Science &
“Recovery Policies for Enhancing Web Engineering in Sri Kalahastheeshwara Institute of
Services Reliability,” Proc. IEEE Int‟l Technology, Sri Kalahasthi, and M.Tech in
Conf. Web Services (ICWS ‟06), pp. 189- Computer Science & Engineering in Sri Kottam
196, 2006. Tulasi Reddy Memorial College of Engg, Affiliated
7) A.Portilla, “Providing Transactional to JNTU Hyderabad. His interested areas are
Behavior to Services Coordination,” Proc. Wireless Sensor Networks, Artificial Intelligence.
Very Large Data Bases (VLDB) PhD He attended two international conferences on
Workshop, vol. 170, 2006. MANET`s and one national level conference on
8) S. Loecher, “Model-Based Transaction Networks. He attended Mission 10x program
Service Configuration for Component- conducted by Wipro. Presently he was acting as The
Based Development,” Component-Based Convener of R&D cell in SKTRMCE. Kondair,
Software Eng., pp. 302-309, 2004. Mahaboob Nagar (Dt). He had total 07 years of
9) P.W.P.J. Grefen, “Combining Theory and teaching experience. Currently he was working as
Practice in Integrity Control: A Declarative Associate Professor in CSE Department in KTM
Approach to the Specification of a College of Engineering,
Transaction Modification Subsystem,”

1921 | P a g e

Kz2519141921

Recommended

Recommended

More Related Content

What's hot

What's hot (18)

Similar to Kz2519141921

Similar to Kz2519141921 (20)

Kz2519141921