SOA is an architectural framework for software design that works around the
concept of services. In our day-to-day life, we take the concept of services as a given:
if we are sick, we seek the service of a doctor, if a faucet is leaking in our home,
we rely on a plumber's service to get that fixed, our children's education depends
on the services of teachers, and so on. While services span nearly all the things
imaginable, they exhibit a rather simple interaction pattern. When a consumer makes
a request to the provider for something to be done, the provider provides a service
by executing that request. At a high level, services in SOA would be quite similar
to those in our daily lives. Of course, in SOA, the consumers and providers would
be some computer applications and the service would be a suitable unit of business
or technical functionality that is digitally accomplished. SOA is about working with
such services. It is the architectural component of a bigger philosophy, the so-called
service orientation, and its adoption has a multi-fold impact on an organization in
the way it builds and leverages IT assets for ultimate business benefit. SOA impacts,
for example:
• Application architecture: The way services are used (consumed) by other
applications such as business processes or integration processes or portals.
• Enterprise architecture: The embellishment of standard enterprise
architecture by components specific to handling and management of
services, for example, service orchestrator for composition of business
processes or composite applications using services, service bus for service
request mediation and protocol and format translations, service portfolios,
and repositories for service asset management, service repositories, and
registries for service look-ups, service security, policy, and quality-of-service
management components, and so on. (The following figure shows some of
the essential elements of SOA.)
• Business architecture: The way a business's activities are to be organized
or modified in order to implement and best leverage SOA.
• Organizational architecture: The organization roles, responsibilities,
and governance as they pertain to SOA-related activities.
For a successful SOA adoption, you need to attend to each of the above aspects,
which are not all technology related. This is the reason why you may hear remarks
like "SOA is not only technology" or "You cannot buy SOA off-the-shelf". While
we acknowledge this comprehensive approach to successful SOA adoption, and
Oracle's SOA Methodology delves into details of how SOA may be adopted in
a comprehensive manner, in this book, we have chosen to keep our focus on the
implementation aspects of SOA solutions.
concept of services. In our day-to-day life, we take the concept of services as a given:
if we are sick, we seek the service of a doctor, if a faucet is leaking in our home,
we rely on a plumber's service to get that fixed, our children's education depends
on the services of teachers, and so on. While services span nearly all the things
imaginable, they exhibit a rather simple interaction pattern. When a consumer makes
a request to the provider for something to be done, the provider provides a service
by executing that request. At a high level, services in SOA would be quite similar
to those in our daily lives. Of course, in SOA, the consumers and providers would
be some computer applications and the service would be a suitable unit of business
or technical functionality that is digitally accomplished. SOA is about working with
such services. It is the architectural component of a bigger philosophy, the so-called
service orientation, and its adoption has a multi-fold impact on an organization in
the way it builds and leverages IT assets for ultimate business benefit. SOA impacts,
for example:
• Application architecture: The way services are used (consumed) by other
applications such as business processes or integration processes or portals.
• Enterprise architecture: The embellishment of standard enterprise
architecture by components specific to handling and management of
services, for example, service orchestrator for composition of business
processes or composite applications using services, service bus for service
request mediation and protocol and format translations, service portfolios,
and repositories for service asset management, service repositories, and
registries for service look-ups, service security, policy, and quality-of-service
management components, and so on. (The following figure shows some of
the essential elements of SOA.)
• Business architecture: The way a business's activities are to be organized
or modified in order to implement and best leverage SOA.
• Organizational architecture: The organization roles, responsibilities,
and governance as they pertain to SOA-related activities.
For a successful SOA adoption, you need to attend to each of the above aspects,
which are not all technology related. This is the reason why you may hear remarks
like "SOA is not only technology" or "You cannot buy SOA off-the-shelf". While
we acknowledge this comprehensive approach to successful SOA adoption, and
Oracle's SOA Methodology delves into details of how SOA may be adopted in
a comprehensive manner, in this book, we have chosen to keep our focus on the
implementation aspects of SOA solutions.
the key focus areas for a comprehensive and successful
SOA adoption
SOA adoption
A service in SOA is basically an encapsulation of data and business logic. A service
consists of an interface, has an implementation, and exhibits certain pre-defined
behavior. The service interface defines a set of operations, which portrays its
capabilities; operations are the things that a service can do. The provider of the
service offers one or more contracts based on the interface and behavior details,
and is responsible for creating a service implementation capable of fulfilling such
contract(s). The consumer of the service is only concerned with the contract for use
of this service. The service functionalities may be derived from diverse sources, for
example, databases, legacy applications, packaged enterprise applications, or bespoke
applications developed in traditional programming environments like C/C++, Java,
or .Net. Mature technologies and tools exist today that can easily package and expose
these functionalities as services. A wide variety of service consumers are possible, for
example, composite applications, user interaction modules, or business-to-business
gateways. Service and IT infrastructures bridge service consumers and the providers
and provide mechanisms to apply adequate security and other policies (see the
following figure for a high-level SOA Reference Architecture schematic, ref. Oracle
SOA Methodology).
consists of an interface, has an implementation, and exhibits certain pre-defined
behavior. The service interface defines a set of operations, which portrays its
capabilities; operations are the things that a service can do. The provider of the
service offers one or more contracts based on the interface and behavior details,
and is responsible for creating a service implementation capable of fulfilling such
contract(s). The consumer of the service is only concerned with the contract for use
of this service. The service functionalities may be derived from diverse sources, for
example, databases, legacy applications, packaged enterprise applications, or bespoke
applications developed in traditional programming environments like C/C++, Java,
or .Net. Mature technologies and tools exist today that can easily package and expose
these functionalities as services. A wide variety of service consumers are possible, for
example, composite applications, user interaction modules, or business-to-business
gateways. Service and IT infrastructures bridge service consumers and the providers
and provide mechanisms to apply adequate security and other policies (see the
following figure for a high-level SOA Reference Architecture schematic, ref. Oracle
SOA Methodology).
Oracle SOA Methodology
Tidak ada komentar:
Posting Komentar