Transactional Behavior Verification in Business Process as a

Service Configuration

ABSTRACT

 The industrial rise of Web services and cloud services provides ample opportunities for
business processes to be implemented with third-party components in a way that is rapid
to develop, low- cost, and with reduced start-up risk.
 Cloud computing has become a popular paradigm for delivering a wide range of services,

such as software applications, computing capacity, storage, and virtual platforms.

 Cloud service providers can offer these utilities to clients over the Internet in a pay-by-
use manner.
 The traditional hierarchy of cloud service types is comprised of three layers, where each
layer can provide the base (infrastructure or platform) for running services within the
layer.

INTRODUCTION

 Computing capacity offered by Amazon EC21 or IBM Smart Cloud Enterprise+2 are
examples of IaaS offerings.
 Platform as a Service (PaaS) provides access to utilities such as software development
and hosting frameworks.
 For example, Google App Engine3 and Microsoft Azure4 both contain PaaS features for
web application development and hosting.
 Finally, Software as a Service (SaaS) is software applications deployed in a way that is
Internet accessible, automatically scaling, and multi-tenant.
 SaaS enables clients to remotely use software complex systems, such as customer
relationship management through Sales force.

LITERATURE SURVEY

Uncovering and resolving transactional behavior issues in service-oriented processes at

design time

1
  Firstly, we will aim to develop a design-time verification method for service-oriented
process that allows developers to ensure reliable transactional behavior.
 This will require a formal model for service-oriented processes that includes a detailed
view of the transactional behavior.
 Rules or correctness criteria that express well-formed transactional behavior must also be
defined.
 Finally, an appropriate use of formal methods for verification will allow transactional
design issues to be identified in the model.
 The end result will be an easy-to-use verification process and its associated tool that
helps developers find and resolve critical problems, such as deadlocking or incomplete
transactional behavior, before starting development.

Formalizing complex transactional requirements for the verification of service-oriented

processes

 Secondly, we aim to create a design-time verification approach that can elicit application-
dependent transactional requirements from developers, in order to verify service-oriented
processes against them.
 This method will include a requirement specification method that is easy-to-use, capable
of both simple and complex requirements, and scalable to large process models.
 This will enable developers to verify complex transactional behavior before
development, and will provide greater flexibility and scalability over state-of-the-art
approaches, through the breadth and depth of behavior coverage offered by our
requirements.

A BPaaS configuration method that preserves provider constraints and client transactional
requirements

 Finally, we will develop a configuration process and associated tool for clients to use
when provisioning a BPaaS. This process will ensure the satisfaction of transactional
requirements and feature selections from the client, while preserving domain constraints
over configuration
 . The BPaaS will be able to be configured from numerous perspectives, including
activities, resources, and data objects.

2
  Therefore, it requires an expressive model of configurable and transactional BPaaS,
formalization of configuration constraints, and formal methods capable of handling large
and complex models in a timeframe reasonable for clients. Ensuring transactional
requirements will be able to provide clients with a greater level of trust to outsource
business operations to BPaaS.
 Our model will also be able to offer high configurability, to increase the potential market
of the service.

An expressive design-time model for transactional service-oriented processes

 Our service-oriented process model uses state charts and provides separate views of the
transactional and functional views of the process behavior.
 This allows each perspective to be designed and modified by domain experts, and
enabling formal methods to be applied for verification.

Rules for well-formed transactional behavior

 We propose a set of rules that can be applied to our service-oriented process model in
order to verify that the transactional behavior is well-formed.
 These rules ensure that the transactional behavior of the process always
i) Initiates correctly,
ii) Avoids deadlocking scenarios, and
iii) Terminates in a valid state. These rules can be expressed in temporal logic [56] for
formal verification.

Temporal logic templates as a transactional requirement specification method

 We develop a set of temporal logic templates to enable formalization of simple or

complex transactional requirements over service-oriented processes.
 These templates do not require expertise in any formal languages to use, and can be used
in verification.
 Compared to existing specification methods, the template set is easy-to-use, scalable for
large process models, and capable of expressing a diverse range of transactional
requirements.

A BPaaS modeling approach that combines transactional behavior, domain constraints,

and configurable activities, resources, and data objects

3
  At the core of our BPaaS configuration process we propose a modelling approach that in-
corporate all these necessary properties in a way that allows formal methods.
 Business Process Modelling and Notation (BPMN) is utilized in conjunction with
statecharts, feature models, and Binary Decision Diagrams (BDDs).

A BPaaS configuration process that preserves service provider domain constraints and
client transactional requirements

 We compose a multi-step configuration process for BPaaS that applies BDD analysis for
ensuring domain constraints, and model checking with temporal logic templates for
verification against client transactional requirements.
 This allows clients to configure a BPaaS from activity, resource, and data object
perspectives, while ensuring the process satisfies their requirements.

A prototype tool for verification of service-oriented process designs and BPaaS

configuration

 Our proposed verification and configuration approaches are implemented in a Java-based

proto- type tool called TL-VIEWS.
 The prototype integrates a statechart modelling programs with formal verification tools
for model checking and BDD analysis.
 It contains interfaces for process modelling and verification, and for client-driven
configuration of BPaaS.

EXISTING SYSTEM

 In Existing System, Infrastructure as a Service (IaaS) is the bottom service layer,

providing access to virtualized physical resources, such as storage and computation
capacity.
 The traditional hierarchy of cloud service types is comprised of three layers, where each
layer can provide the base (infrastructure or platform) for running services within the
layer above.
 Infrastructure as a Service (IaaS) is the bottom service layer, providing access to
virtualized physical resources, such as storage and computation capacity.

4
  Computing capacity offered by Amazon EC2 or IBM Smart Cloud Enterprise+ are
examples of IaaS offerings.

DISADVANTAGES
 Unacceptable delay has occurred during execution.
 Increase their state space.

PROPOSED SYSTEM

 In Existing System, several modeling techniques, including BPMN for business process
structure, state charts for transactional state, and feature models for configuration
constraints.
 Using these models, we develop a BPaaS configuration process that applies Binary
Decision Diagram (BDD) analysis and model checking.
 BDD analysis ensures that BPaaS features selected during configuration do not violate
the domain constraints of the service provider, while model checking verifies the
configured BPaaS against transactional requirements provided by the client.
 To reduce the impact of state-space explosion, we employ a state-space reduction
algorithm and split the model checking into two phases.
 These phases verify different configuration perspectives separately, and allow for the
state space and temporal logic properties to be reduced further.
 Our performance analysis shows that the proposed configuration method is capable of
verifying models with hundreds of activities, resources, data objects, and requirement sets
within seconds.
 A proposed fourth layer of the cloud service architecture residing above SaaS has been in
the form of Business Process as a Service (BPaaS), which has had in-creasing research
interest in recent years.
 The driving idea behind BPaaS is to mash-up services from numerous providers into a
business process structure, which can then be offered to clients as its own service.
 BPaaS providers will naturally target common or proven business processes that apply
to a large potential market, or require management of several complex components.

ADVANTAGES
• It provides a low-cost, low-risk outsource option for integral business.
• Configuring BPMN is also less complex.

5
SYSTEM ARCHITECTURE

SYSTEM REQUIREMENTS

H/W System Configuration:-

Processor: Pentium –IV
RAM : 256 MB (min)
Hard Disk: 100 GB

S/W System Configuration:-

Operating System : Window87/*
Application Server : IIS
Front End : HTML, ASP.net
Scripts : JavaScript.
Database: MS SQL SERVER 2005
Database Connectivity: ADO.NET

6
CONCLUSION

The increase in cloud computing adaptations in recent years has produced the concept of
Business Process as a Service (BPaaS), whereby service providers are able to offer common or
proven business processes to clients looking to automate and/or outsource parts of their
operations.

We address the problem of managing BPaaS configuration in a way to ensure that the resulting
service

i) is valid with respect to configuration constraints of the provider, and

ii) Satisfies transactional requirements drawn from the business rules of the client. Our
approach utilizes several modelling techniques, including BPMN for business process
structure, state charts for transactional state, feature models for configuration
constraints.