Addressing Dependability
Throughout the SOA Life Cycle
Abstract:
Dependability should be considered throughout the phases of the SOA
life cycle. This article proposes the application of a service level management
approach to address dependability and presents dependability-related activities for
every stage (Model, Assemble, Deploy, and Manage) of the SOA life cycle.
Furthermore, we describe the concepts and the formalisms that are behind these
activities. Following these activities service providers and aggregators can offer
optimized levels of dependability from their existing services and thus better meet
user requirements.
Architecture:
Existing System:
Existing approaches for specification of QoS
characteristics in Web Service environments can be grouped according to their
main focus: software design/process description (e.g., UML Profile for QoS and
QoS Modeling Language (QML)), service/component description (e.g., WSPolicy), and SLA-centric approaches (e.g., Web Service Level Agreements
(WSLA), Web Service Offerings Language (WSOL), Service Level Agreement
definition language, and WS-Agreement).
Disadvantages:
In traditional software engineering dependability can be addressed
both at design time and at runtime.
It doesn’t satisfy the User requirements.
Proposed System:
Parameters impacting dependability of Web Services have been
recently identified and a variety of approaches have been proposed. However, all
of these approaches address only parts of a typical service life cycle. Our objective
is to propose a service level management approach that covers every stage of the
SOA life cycle.
Advantages:
A major advantage of SOA is the ability to compose new services
from existing ones. This dynamic aspect makes NFP assurance even more relevant
than in traditional software systems.
Modules:
1. Model:
The model phase is based on business requirements, and in it the
business process models are designed, business services are identified, processes
are simulated with what-if business conditions, and their subsequent results are
analyzed with respect to business objectives. If the objectives are not met,
processes are redefined with modified business services. From these modeling
aspects, identification of business services is an important activity, which is one-toone mapping to an IT service realization.
2. Assemble:
After defining the IT service, you come to the assemble phase for
design, specification, creation, and testing. The constructed services are tested
independently and with the composition of business processes. The tested and
qualified services are brought into a runtime repository and get published for
service consumers. As different service clients consume these services with little
changes in functional aspects, different versions of the same services with varied
functionality are built after change process approvals.
There we can map the specified dependability requirements
both to actual (technical) Web Services, as well to composed (aggregated) Web
Services. In the first case our objective is to provide dependability at the service
implementation level, while in the second we improve the robustness of the
composed workflow.
3. Deploy:
In the deploy phase, different versions of services are published in
repositories and deployed in service containers with an integrated business
processes. The deployed services can also be dynamically selected at run time to
build composite applications based on some selection criteria from the service
requesters.
4. Manage:
These services are monitored during the manage phase for
timely responsiveness for different service requests, detecting failures at service
levels, and restoring the operational state of the system. During this phase, services
and the overall operational environment are tuned to meet business objectives. The
services are managed for identity and compliance through proper service-level
security design and implementation.
In this SOA development life cycle, the following challenges are likely to be
encountered in the absence of clearly defined and enforced SOA governance
processes:

Struggling to identify new services and prioritize them.

Significant issues with service creation and reuse, such as creation of
redundant and inefficient services.

No systematic way to enforce governance policies for service management,
and services security.
Comparison Algorithm:
A comparison sort is a type of sorting algorithm that only reads the list elements
through a single abstract comparison operation (often a "less than or equal to"
operator) that determines which of two elements should occur first in the final
sorted list. The only requirement is that the operator obey two of the properties of a
total order:
1. if a ≤ b and b ≤ c then a ≤ c (transitivity)
2. for all a and b, either a ≤ b or b < a (totalness or trichotomy).
System Requirements:
Hardware Requirements:
Processor
:
Intel Duel Core.
Hard Disk
:
60 GB.
Floppy Drive
:
1.44 Mb.
Monitor
:
LCD Colour.
Mouse
:
Optical Mouse.
RAM
:
512 Mb.
Software Requirements:
Operating system :
Windows XP.
Coding Language :
ASP.Net with C#
Data Base
SQL Server 2005
: