Welcome to Scribd. Sign in or start your free trial to enjoy unlimited e-books, audiobooks & documents.Find out more
Download
Standard view
Full view
of .
Look up keyword
Like this
4Activity
0 of .
Results for:
No results containing your search query
P. 1
SOA-technical-whitepaper

SOA-technical-whitepaper

Ratings: (0)|Views: 74|Likes:
Published by api-3727274

More info:

Published by: api-3727274 on Oct 16, 2008
Copyright:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as PDF, TXT or read online from Scribd
See more
See less

05/21/2015

pdf

text

original

Service Oriented Architecture (SOA)
and Specialized Messaging Patterns
1.0 Thesis

Te widespread emergence o\ue005 the Internet in the mid 1990s as a plat\ue005orm \ue005or electronic data
distribution and the advent o\ue005 structured in\ue005ormation have revolutionized our ability to deliver
in\ue005ormation to any corner o\ue005 the world. While the introduction o\ue005 Extensible Markup Language
(XML)i as a structured \ue005ormat was a major enabling \ue005actor, the promise o\ue003ered by SOAP based
webservices triggered the discovery o\ue005 architectural patterns that are now known as Service

Oriented Architecture (SOA).ii

Service Oriented Architecture is an architectural paradigm and discipline that may be used to
build in\ue005rastructures enabling those with needs (consumers) and those with capabilities
(providers) to interact via services across disparate domains o\ue005 technology and ownership.
Services act as the core \ue005acilitator o\ue005 electronic data interchanges yet require additional mecha-
nisms in order to \ue005unction. Several new trends in the computer industry rely upon SOA as the
enabling \ue005oundation. Tese include the automation o\ue005 Business Process Management (BPM),
composite applications (applications that aggregate multiple services to \ue005unction), and the
multitude o\ue005 new architecture and design patterns generally re\ue005erred to as Web 2.0iii.

Te latter, Web 2.0, is not de\ue002ned as a static architecture. Web 2.0 can be generally characterized
as a common set o\ue005 architecture and design patterns, which can be implemented in multiple
contexts. Te list o\ue005 common patterns includes the Mashup, Collaboration-Participation,
So\ue001ware as a Service (SaaS), Semantic \ue004agging (\ue005olksonomy), and Rich User Experience (also
known as Rich Internet Application) patterns among others. Tese are augmented with themes
\ue005or so\ue001ware architects such as trusting your users and harnessing collective intelligence. Most
Web 2.0 architecture patterns rely on Service Oriented Architecture in order to \ue005unction.

When designing Web 2.0 applications based on these patterns, architects o\ue001en have highly
specialized requirements \ue005or moving data. Enterprise adoption o\ue005 these patterns requires special
considerations \ue005or scalability, \ue000exibility (in terms o\ue005 multiple message exchange patterns), and
the ability to deliver these services to a multitude o\ue005 disparate consumers. Architects o\ue001en need
to expand data interchanges beyond simple request-response patterns and adopt more robust
message exchange patterns, triggered by multiple types o\ue005 events. As a result, many specialized
plat\ue005orms are evolving to meet these needs.

Tis white paper discusses specializations \ue005or advanced data exchanges within enterprise service
oriented environments and illustrates some o\ue005 the common architectures o\ue005 these new plat\ue005orms.
i. Te Extensible Markup Language (XML) is a W3C Recommendation - http://www.w3.org/XML/
ii. Service Oriented Architecture is an architectural paradigm expressed as a Re\ue005erence Model by OASIS at
http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=soa-rm
iii. Web 2.0 is de\ue002ned as a set o\ue005 Design Patterns in the O\u2019Reilly book Web 2.0 Design Patterns -
http://www.amazon.com/Web-2-0-Design-Patterns-entrepreneurs/dp/0596514433
Chie\ue000 Editor:
Duane Nickul
Contributors/Editors:

Laurel Reitman
James Ward
Jack Wilber

Table o\ue000 Contents
1.0 Thesis.....................................................................................1
2.0 An Introduction to Service Oriented

Architecture.........................................................................2 2.1 Requirements \ue000or SOA....................................................2 2.2 A Re\ue000erence Model \ue000or Service Oriented

Architecture.........................................................................4 2.3 Decomposing the Interaction Model.......................5 3.0 A Re\ue000erence Architecture \ue000or Service Oriented

Architecture.........................................................................6 3.1 Service Tier..........................................................................7 3.2 Client Tier.............................................................................8 3.3 Architectural Conventions spanning

multiple tiers.......................................................................9 3.4 Events................................................................................. 10 3.5 Objects............................................................................... 10 3.6 Architectural Patterns...................................................11 4.0 Data and Message Exchange Patterns \ue000or

Enterprise SOA..................................................................11 4.1 Request-Response..........................................................11 4.2 Request-Response via Service Registry

(or Directory).....................................................................11 4.3 Subscribe-Push............................................................... 12 4.4 Probe and Match............................................................ 12 4.5 Patterns \ue000or RIAs............................................................. 13 4.6 Data paging..................................................................... 14 4.7 Data push.......................................................................... 14 5.0 A Final Word..................................................................... 14 About the Authors............................................................... 15

Technical White Paper
2.0 An Introduction to Service Oriented Architecture

Service Oriented Architecture (SOA) is a paradigm \ue005or organizing and utilizing distributed
capabilities that may be under the control o\ue005 di\ue003erent ownership domains and implemented
using various technology stacks. In general, entities (people and organizations) create capabili-
ties to solve or support a solution \ue005or the problems they \ue005ace in the course o\ue005 their business. It is
natural to think o\ue005 one person\u2019s needs being met by capabilities o\ue003ered by someone else; or, in
the world o\ue005 distributed computing, one computer agent\u2019s requirements being met by a computer
agent belonging to a di\ue003erent owner. Te term owner here may be used to denote di\ue003erent
divisions o\ue005 one business or perhaps unrelated entities in di\ue003erent countries.

Tere is not necessarily a one-to-one correlation between needs and capabilities; the granularity
o\ue005 needs and capabilities vary \ue005rom \ue005undamental to complex, and any given need may require a
combination o\ue005 numerous capabilities while any single capability may address more than one
need. One perceived value o\ue005 SOA is that it provides a power\ue005ul \ue005ramework \ue005or matching needs
and capabilities and \ue005or combining capabilities to address those needs by leveraging other
capabilities. One capability may be repurposed across a multitude o\ue005 needs.

SOA is a \u201cview\u201d o\ue005 architecture that \ue005ocuses in on services as the action boundaries between the
needs and capabilities in a manner conducive to service discovery and repurposing.
2.1 Requirements \ue000or SOA

Figure 2-1 shows an example o\ue005 an in\ue005ormation system scenario that could bene\ue002t \ue005rom a
migration to SOA. Within one organization, three separate business processes use the same
\ue005unctionality, each encapsulating it within an application. In this scenario, the login \ue005unction,
the ability to change the user name, and the ability to persist it are common tasks implemented
redundantly in all three processes. Tis is a suboptimal situation because the company has paid
to implement the same basic \ue005unctionality three times.

Process 1
Log in / Authenticate
Log in / Authenticate
Log in / Authenticate
Process 2
Process 3
Persist
Name &
Address
Persist
Name &
Address
Persist
Name &
Address
Make Deposit
File to Insurance
Agent
Modify Assembly
Line system
Payroll Calc()
Audit performance
Claim details
Insurance Claim
Configure production
ER Planning
Name
Change
form
Name
Change
form
Name
Change
form
Figure 2.1 \u2013 three business processes within one company duplicating \ue000unctionality

Moreover, such scenarios are highly inefcient and introduce maintenance complexity within I\ue004
in\ue005rastructures. For example, consider an implementation in which the state o\ue005 a user is not
synchronized across all three processes. In this environment users might have to remember
multiple login username/password tokens and manage changes to their pro\ue002les in three separate
areas. Additionally, i\ue005 a manager wanted to deny a user access to all three processes, it is likely
that three di\ue003erent procedures would be required (one \ue005or each o\ue005 the applications). Corporate I\ue004
workers managing such a system would be e\ue003ectively tripling their work \u2013and spending more \ue005or
so\ue001ware and hardware systems.

2

In a more efcient scenario, common tasks would be shared across all three processes. Tis can
be implemented by decoupling the \ue005unctionality \ue005rom each process or application and building a
standalone authentication and user management application that can be accessed as a service. In
such a scenario, the service itsel\ue005 can be repurposed across multiple processes and applications
and the company owning it only has to maintain the \ue005unctionality in one central place. Tis
would be a simple example o\ue005 Service Oriented Architecture in practice. Te resultant I\ue004
in\ue005rastructure would resemble Figure 2.2.

Process 1
Log in / Authenticate
Process 2
Process 3
Persist
Name &
Address
Make Deposit
File to Insurance
Agent
Modify Assembly
Line system
Payroll Calc()
Audit performance
Claim details
Insurance Claim
Configure production
ER Planning
Name
Change
formShared User
Account Tasks
Service Bus
Other Services
Figure 2.2 \u2013 three business processes repurposing one service \ue000or common tasks.

In \ue002gure 2.2, the shared user account tasks have been separated \ue005rom each process and imple-
mented in a way that enables other processes to call them as a service. Tis allows the shared
\ue005unctions to be repurposed across all three processes. Te common service bus is really a virtual
environment whereby services are made available to all potential consumers on a \ue005abric. Tis is
typically re\ue005erred to as an Enterprise Service Bus (ESB) and has a collection o\ue005 specialized
subcomponents including naming and lookup directories, registry-repositories, and service
provider inter\ue005aces (\ue005or connecting capabilities and integrating systems) as well as a standard-
ized collection o\ue005 standards and protocols to make communications seamless across all con-
nected devices. Advanced ESB vendors have tools that can aggregate services into complex
processes and work\ue000ows.

In the preceding example o\ue005 SOA, the complications were relatively minor as the entire in\ue005ra-
structure existed within one domain. In reality, enterprise SOA is much more difcult because
services may be deployed across multiple domains o\ue005 ownership. \ue004o make interactions possible,
mechanisms have to be present to convey semantics, declare and en\ue005orce policies and contracts,
the ability to use constraints \ue005or data passed in and out o\ue005 the services as well as expressions \ue005or
the behavior models o\ue005 services. Te ability to understand both the structure and semantics o\ue005
data passing between service endpoints is essential \ue005or all parties involved.

While most SOA examples are typically shown as are qu e s t- re s p o n s e interaction pattern, more
robust exchanges are required. Additionally, modern service plat\ue005orms also need the \ue000exibility
to support these advanced message exchange patterns. Be\ue005ore discussing the plat\ue005orm and
re\ue005erence architecture, this white paper will brie\ue000y delve into SOA in more detail.

3

Activity (4)

You've already reviewed this. Edit your review.
1 thousand reads
1 hundred reads
am_jalu liked this
preritp liked this

You're Reading a Free Preview

Download
scribd
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->