|
SOA System-oriented Architecture |
From Wikipedia, the free
encyclopedia http://en.wikipedia.org/wiki/Service-oriented_architecture
SOA is a paradigm for organizing and utilizing distributed
capabilities that may be under the control of different ownership domains.
It provides a uniform means to offer, discover, interact with and use
capabilities to produce desired effects consistent with measurable preconditions
and expectations.
SOA is an architectural style rather than a product.
Service-oriented architecture (SOA) expresses a perspective
of software architecture that defines the use of loosely coupled software
services to support the requirements of the business processes and software
users.
SOA is a design for linking computational resources, principally,
applications and data, on demand to achieve the desired results for service
consumers which can be end users or other services.
In an SOA environment, resources on a network are made available as
independent services that can be accessed without knowledge of their underlying
platform implementation. A service-oriented architecture is not tied to a
specific technology and may be implemented using a wide range of
interoperability standards including RPC, DCOM, ORB or WSDL.
The following guiding principles define the ground rules for
development, maintenance, and usage of the SOA. * Reuse,
granularity, modularity, composability, componentization, and interoperability
* Compliance to standards (both common and industry-specific) * Services
identification and categorization, provisioning and delivery, and monitoring and
tracking
The following specific architectural principles for design and
service definition focus on specific themes that influence the intrinsic
behaviour of a system and the style of its design: * Service
Encapsulation * Service Loose coupling - Services maintain a relationship
that minimizes dependencies and only requires that they maintain an awareness of
each other * Service contract - Services adhere to a communications
agreement, as defined collectively by one or more service description documents
* Service abstraction - Beyond what is described in the service contract,
services hide logic from the outside world * Service reusability - Logic is
divided into services with the intention of promoting reuse * Service
composability - Collections of services can be coordinated and assembled to form
composite services * Service autonomy – Services have control over the logic
they encapsulate * Service statelessness – Services minimize retaining
information specific to an activity * Service discoverability – Services are
designed to be outwardly descriptive so that they can be found and assessed via
available discovery mechanisms[5]
In addition, the following factors should also be taken into account
when defining an SOA implementation:
* SOA Reference Architecture - which provides a worked design of an
enterprise-wide SOA implementation with detailed architecture diagrams,
component descriptions, detailed requirements, design patterns, opinions about
standards, patterns on regulation compliance, standards templates etc. *
Life cycle management - introduces the Services Lifecycle and provides a
detailed process for services management though the service lifecycle, from
inception through to retirement or repurposing of the services. It also contains
an appendix that includes organization and governance best practices, templates,
comments on key SOA standards, and recommended links for more information. *
Efficient use of system resources * Service maturity and performance *
EAI Enterprise Application Integration
One area where SOA has been gaining ground is in its power as a mechanism for
defining business services and operating models and thus
provide a structure for IT to deliver against the actual business
requirements and adapt in a similar way to the
business. The purpose of using SOA as a business mapping tool
is to ensure that the services created properly represent the business view and
are not just what technologists think the business services should be. At the
heart of SOA planning is the process of defining architectures for the use of
information in support of the business, and the plan for implementing those
architectures.
Enterprise Business Architecture should always represent the highest and most
dominant architecture. Every service should be created with the intent to bring
value to the business in some way and must be traceable back to the business
architecture. |