1.

Understanding SOA
Definition of Service-oriented architecture (SOA)
A loosely-coupled architecture designed to meet the business needs of the organization
The architectural concepts associated with SOA are not new many have evolved from ideas originally
introduced by CORBA, DCOM, DCE and others.
A structured collections of discrete software modules, known as services
A service is a tightly defined function/ set of functions, self-contained, context & state independent of other
services


ref
http://en.wikipedia.org/wiki/Service-oriented_architecture

http://www.service-architecture.com/web-services/articles/service-
oriented_architecture_soa_definition.html

http://msdn.microsoft.com/en-in/library/bb833022.aspx
http://www.ibm.com/developerworks/webservices/library/ws-designsoa/
imp
https://www.ibm.com/developerworks/mydeveloperworks/blogs/AliArsanjani/?lang=en

The Evolution of SOA
Service Orientation (SO) is the natural evolution of current development models. The, 80s saw object-
oriented models; then came the component-based development model in the 90s; and now we have
service orientation (SO). Service orientation retains the benefits of component-based development (self-
description, encapsulation, dynamic discovery and loading), but there is a shift in paradigm from
remotely invoking methods on objects, to one of passing messages between services. Schemas describe
not only the structure of messages, but also behavioral contracts to define acceptable message
exchange patterns and policies to define service semantics. This promotes interoperability, and thus
provides adaptability benefits, as messages can be sent from one service to another without
consideration of how the service handling those messages has been implemented.

The fundamental building block of service-oriented architecture is a service. A service is a program that
can be interacted with through well-defined message exchanges. Services must be designed for both
availability and stability. Services are built to last while service configurations and aggregations are built
for change. Agility is often promoted as one of the biggest benefits of SOAan organization with
business processes implemented on a loosely-coupled infrastructure is much more open to change than
an organization constrained by underlying monolithic applications that require weeks to implement the
smallest change. Loosely-coupled systems result in loosely-coupled business processes, since the
business processes are no longer constrained by the limitations of the underlying infrastructure. Services
and their associated interfaces must remain stable, enabling them to be re-configured or re-aggregated
to meet the ever-changing needs of business. Services remain stable by relying upon standards-based
interfaces and well-defined messagesfor example using SOAP and XML schemas for message
definition. Services designed to perform simple, granular functions with limited knowledge of how
messages are passed to or retrieved from it are much more likely to be reused within a larger SOA
infrastructure.

Problem Domain













Billing
Order Entry
PACS
Cardiology
Lab

MPI

Pharmacy
PACS
Radiology





























Data
Pharmacy
System
Data
Lab 1
System
Data
Patient 1
System
Data
Billing
System
Data
Lab 2
System
Data
Patient 2
System
Integration Service Bus
Patient
Record
Billing
Service
Laboratory
Service
Other
Service
Business Service Bus
Channels
Patient
Management
Marketing Diagnostics




SOA Context in Healthcare

























Architecture
It can be defined as a representation group(s) of relationship between various components of a complex
software solution.
The solution is decomposed into smaller, self-describing components and represented as structural
relationships to provide a high-level overview of the entire system.

a database driven, web-based solution
Without Architecture
Achieve our designed goal
Decompose our requirements into smaller entities Quality solutions
Change management
Re-usable or extendable solutions Achieve business goals




2. NEEDS FOR ENETRPRISE AND IT ARCHITECTURE

Enterprise architecture (EA) is the process of translating business vision and strategy into effective
enterprise change by creating, communicating and improving the key requirements, principles and
models that describe the enterprise's future state and enable its evolution.

A business architecture is a part of an enterprise architecture related to corporate business, and
the documents and diagrams that describe the architectural structure of that business.
Business Architecture articulates the functional structure of an enterprise in terms of its business services
and business information. The business capability is able to perform certain business functionality and
deliver business results or values. The business capability is provided by business services that state
"what" the organization does while the business processes implement business functionality and define
"how" the organization can execute its capabilities.


EDA Enterprise Data Architecture
Building an EDA can give your staff an integrated view of enterprise data organization for strategic and tactical
decision support.
An EDA pulls together, validates, cleanses and integrates data from disparate source application systems, providing
the end-user community with an integrated view of enterprise data.



Enteprise Data


Enterprise Data Architecture





Architecture, software architecture specifically, used to be only defined in terms of components, connectors
and constraints per Shaw and Garlan.
However, it is increasingly evident to those of us who implement architectures on a daily basis for clients
and internally within our own companies
that architecture requires the addition of composition, context and containers to make it operational.


Components -- what are the structural building blocks of a solution, or a style of architecture, of the elements that
can be combined to produce a larger structure
Composition -- How to compose or what are the valid compositions of components
Connectors -- The components need to connect with one another, whether statically (as in an Entity-relationship
kind of relation) or dynamically, as in a composition in an SOA, where you may have orchestration or choreography.
Constraints -- The constraints on the connectors and/or components that provide rules of engagement of what is
permissible and what is not.
Context -- the context of invocation of a component is critical to the designation of how that component will behave
Containers -- the components must live in some runtime container that will provide uniform life-cycle management
capabilities for them







































Architecture




Service
A service is a unit of solution logic (Figure 3.8) to which service orientation
has been applied to a meaningful extent. It is the application
of service-orientation design principles that distinguishes a
unit of logic as a service compared to units of logic that may exist
solely as objects or components.


3.3 Service Implementation Mediums
It is important to view and position SOA as an architectural model that is neutral to any one
technology platform.
Currently, a service can be built and implemented as a:
component
Web service
REST service

Essentially, any implementation technology that can be used to create a distributed system
may be suitable for service-orientation
Services as Components
A component is a software program
designed to be part of a distributed system.
It provides a technical interface
comparable to a traditional application
programming interface (API) through
which it exposes public capabilities as
methods, thereby allowing it to be
explicitly invoked by other programs
(Figure 3.13).
Components typically rely on platformspecific
development and runtime technologies. For example, components can be built
using Java or .NET tools and are then deployed in a runtime environment capable of
supporting
the corresponding component communications technology requirements, as
implemented by the chosen development platform


Services as Web Services
A Web service is a body of solution logic that provides
a physically decoupled technical contract
consisting of a WSDL definition and one or
more XML Schema definitions and also possible
WS-Policy expressions. The Web service contract
exposes public capabilities as operations,
establishing a technical interface but without
any ties to a proprietary communications framework
(Figure 3.14).
Service-orientation can be applied to the design
of Web services. The fact that Web services provide an architectural model whereby the
service contract is physically decoupled and vendor-neutral is conducive to several of the
design goals associated with service-orientation.