Service Oriented Architecture

Service Oriented Architecture (SOA)
Contents
• Overview
• SOA Projects and Initiatives
• SOA Random Links
• General: Books, Articles, Papers, News
Overview
SOA Mini FAQ: What is SOA?
• Acronym : ServiceOriented Architecture
• Acronym also: Save Our Assets, School of the Americas, safe operating area,
Society of Actuaries, Start of Authority
• Neighbor: Related to Serviceoriented analysis and design (SOAD); enterprise
service bus (ESB); ServiceOriented Software Engineering (SOSE).
• Possibly pretentious labeling: According to some, SOA does not involve an
"architecture" at all, but represents a collection of (evolving, notagreedupon)
vintage2004 best practices principles and patterns related to serviceaware
enterpriselevel distributed computing.
• The next big thing: successor to the preceding label "Web Services" with focus upon
workflows, translation coordination, orchestration, collaboration, loose coupling,
business process modeling, and other notions supporting agile computing.
SOA Projects and Initiatives
OASIS Open Composite Services Architecture (CSA) Member Section
On August 09, 2007, OASIS announced the formation of six new technical committees to simplify
SOA application development by advancing the SCA family of specifications. Each of the six new
OASIS committees will address a different aspect of SCA. The corresponding OASIS Open
Composite Services Architecture (CSA) Member Section advances open standards that simplify
SOA application development. Open CSA brings together vendors and users from around the
world to collaborate on the further development and adoption of the Service Component
Architecture (SCA) and Service Data Objects (SDO) families of specifications...
"The SCA model encompasses a wide range of technologies for service components, access
methods that connect them, and policy that provides declarative qualities of service. For
components, this includes not only different programming languages, but also frameworks and
environments commonly used with those languages. For access methods, SCA compositions
allow for the use of various communication and service access technologies in common use. For
policy, this includes a framework for integrating commonly used policy languages and quality of
service expressions."
References:
• OASIS Service Component Architecture Member Section and Technical Committees
• "Six Technical Committees Proposed for the OASIS Open CSA Member Section."
News story 20070706.
• Announcement 20070809: "Six OASIS Committees Form to Standardize Service
Component Architecture (SCA) for SOA. Axway, BEA Systems, IBM, Oracle,
Primeton Technologies, Progress Software, Red Hat, SAIC, SAP, Sun Microsystems,
TIBCO, and Others Collaborate on Standards to Simplify SOA Application
Development."
• Open Service Oriented Architecture (OSOA) Collaboration
• OASIS SOA TCs . "SOA standardization efforts at OASIS focus on workflows,
translation coordination, orchestration, collaboration, loose coupling, business
process modeling, and other concepts that support agile computing."
CBDI / 7irene SOA Reference Model
By John Cheesman and Georgios Ntinolazos. Part 1, "Overview and Concepts": "Not surprisingly
SOA is not a completely new approach; in fact it has firm foundations in Design by Contract (DbC)
and Component Based Development (CBD). However whilst there are good lessons to be learnt
from these disciplines, they are incomplete in their support for a SOA, requiring new and or
revised concepts to address the significant differences between the 'interface' and 'service'
concepts, as well as issues such as loose coupling of components, runtime discovery, use and
replacement, and technology independence... This article sets out a reference model for SOA as
a whole [...] takes a brief tour through some of the areas, particularly looking at the underlying
concepts and the SOA Application Reference Model..."
Part 2, "The Flexible Service Runtime, examines further the SOA concepts with a particular focus
on the patterns and software roles needed for flexible coupling in the service runtime. We
compare these patterns with existing technologyfocused approaches for EJB, .NET and Web
Services, and provide a systems integration scenario to support the flexible coupling
requirement..." [Part 1 first published in the CBDi Journal, March 2004; Part 2 first published in
the CBDi Journal, June 2004]
References:
• Reference Model (articles)
• Download . Part 1 (Overview and Concepts) and Part 2 (The Flexible Service
Runtime). See also below from CBDI Service Oriented Architecture Practice Portal.
• 7irene Case Studies
OASIS SOA Reference Model Technical Committee
On February 04, 2005, OASIS issued a Call for Participation in a new OASIS Service Oriented
Architecture Reference Model Technical Committee. The goal of the TC is to "establish a
Reference Model to encourage the continued growth of specific and different SOA
implementations whilst preserving a common layer that can be shared and understood between
those or future implementations."
The new TC is a spinoff and partial successor to the Electronic Business Service Oriented
Architecture (ebSOA) TC, chartered in February 2004. Proposers of the the new TC include
representatives from Adobe Systems, BAE Systems, Boeing, Booz Allen Hamilton, Cisco
Systems, ECOM, Fujitsu, and Lockheed Martin.
The TC proposers believe that "Service Oriented Architecture" (SOA) as a term "is being used in
an increasing number of contexts and specific technology implementations, sometimes with
differing or conflicting understandings of implicit terminology and components. The proposal to
establish a Reference Model is intended to encourage the continued growth of specific and
different SOA implementations whilst preserving a common layer that can be shared and
understood between those or future implementations."
Abstract for Working Draft 08 of the TC's Reference Model for Service Oriented Architectures
document, published September 09, 2005: "This Service Oriented Architecture Reference Model
is an abstract framework for understanding significant entities and relationships amongst them
within a serviceoriented environment, and for the development of consistent standards or
specifications supporting that environment. It is based on unifying concepts of SOA and may be
used by architects developing specific services oriented architectures or for education and
explaining SOA. A reference model is not directly tied to any standards, technologies or other
concrete implementation details, but it does seek to provide a common semantics that can be
used unambiguously across and between different implementations. While serviceorientation
may be a popular concept found in a broad variety of applications, this reference model scopes
itself to the field of software architecture."
SOARM TC Links:
• "OASIS Creates TC to Define Service Oriented Architecture (SOA) Reference
Model." News story 20050208.
• Announcement 20050503: "OASIS Forms Committee to Develop SOA Reference
Model. Adobe Systems, AmSoft, Boeing, Booz Allen Hamilton, Fujitsu, General
Motors, Infravio, NEC, Reactivity, SOA Software, VISA, and Others Collaborate on a
Foundation for Service Oriented Architectures."
• SOARM TC web site
• SOA Reference Model TC Wiki
• SOARM TC FAQ document
• SOARM TC mailing list archive
• TC members
• Contact: Duane Nickull (TC Chair) or Matthew MacKenzie (Secretary)
Selected TC deliverables:
• Reference Model for Service Oriented Architecture . Produced by members of the
OASIS SOA Reference Model Technical Committee. Committee Draft, February 07,
2006.
• Reference Model for Service Oriented Architectures . Working Draft 08. September 9,
2005. 27 pages. Edited by C. Matthew MacKenzie (Adobe Systems Incorporated),
Ken Laskey (Mitre Corporation), Francis McCabe (Fujitsu Limited), Peter Brown
(Individual Member), Rebekah Metz (Booz Allen Hamilton). [source PDF]
• Service Oriented Architecture Reference Model . Working Draft Version 07. May 12,
2005. Document identifier: 'wdsoarm07'. Described by coeditor C. Matthew
MacKenzie as the "first 'real' draft." See the bibliographic detail and abstract below.
• Service Oriented Architecture Reference Model . Working Draft Version 05. 03May
2005. Document identifier: 'wdsoarm05'.
OASIS Electronic Business Service Oriented Architecture (ebSOA) TC
On February 20, 2004, OASIS announced the formation of a new TC to "continue work on the
ebXML Technical Architecture to bring it from v1.04 to a more current architecture that takes into
account both subsequent releases of the ebXML specifications and other Web Services and
serviceoriented architecture works including the work of the W3C Web Services Architecture
WG."
In September 2005, Semantion Inc. contributed its FERAbased SOA specification documents to
the OASIS Electronic Business Service Oriented Architecture (ebSOA) TC. According to the
posting, the Federated Enterprise Reference Architecture (FERA) specification includes three
documents: (1) Runtime Service Oriented Architecture (SOA) V0.1, (2) Service Oriented
Architecture Information Model (SOA IM) V0.1, and (3) Service Oriented Architecture
Collaboration Semantics (SOA CS) V0.1.
References:
• TC web site
• ebSOA TC Charter
• ebSOA TC list archive
• ebSOA TC document repository
• TC members
• "OASIS Members Form Electronic Business Service Oriented Architecture TC."
News story 20040220.
SOA Blueprints
In August 2005, a Call for Participation was issued for a new OASIS ServiceOriented
Architecture Adoption Blueprints Technical Committee. The TC will continue work begun within
the SOA Blueprints Initiative, originally founded by The Middleware Company and BEA Systems.
The group is chartered to develop, circulate, maintain, and update a set of example business
profiles ("adoption blueprints") which illustrate the practical deployment of services using SOA
methods. See details in the news story "OASIS Members Form SOA Adoption Blueprints
Technical Committee."
"SOA Blueprints is an industry effort designed to help organizations more easily and affordably
build applications using serviceoriented architecture (SOA). SOA Blueprints highlights best
practices through GeneriCo, a fictitious business entity, described in a functional and behavioral
specification to demonstrate how SOA can solve realworld issues. SOA Blueprints creates a
common vocabulary to discuss SOA in an architecturally neutral way allowing comparable
implementations to be crafted using different technology sets including J2EE, .NET and Web
Services...
The SOA Blueprints specification defines a complete environment consisting of a set of
intercommunicating applications that make up an enterprise. Additionally, a number of existing
resources (such as a Payroll system) are utilized to demonstrate how applications may be
integrated using SOAbased solutions. The industry domain of GeneriCo is purposely vague so
that the specification can be applied to as many industries as possible..." [from "About SOA
Blueprints" 20050801]
References:
• Charter for the OASIS ServiceOriented Architecture Adoption Blueprints TC . News
story.
• SOA Blueprints web site
• "SOA Blueprints Initiative Definition." Draft Version 0.5. For Public Review.
Description of the complete initiative aimed at defining Blueprints and Best Practices
for SOA. Published by The Middleware Company Research Team. [Edited by] Steve
Wilkes and John Harby. June 2004. 7 pages. [source .DOC, source cache]
• "SOA Blueprints Concepts." Draft Version 0.5. Technical Specification for Public
Review. By Steve Wilkes and John Harby (The Middleware Company, Research
Team). June 2004. 9 pages. "A move to drive industry standardization of SOA
concepts and terminology." [source
• "SOA Blueprints Reference Example Requirements Specification." Draft Version 0.5.
Technical Specification for Public Review. By Steve Wilkes and John Harby (The
Middleware Company, Research Team). June 2004. 131 pages. A set of
interconnected applications demonstrating the Blueprints and Best Practices for
SOA. [source]
• "SOA Blueprints: Occasionally Connected Profile." Version 0.1. By Steve Wilkes. The
Middleware Company, Research Team. August 2004. 9 pages. An extension of the
SOA Blueprints Reference Example to deal with occasionally connected rich client
interfaces. [.DOC source, cache]
• "SOA Blueprints V0.2 Expert Review." Expert Review Board comment for version 0.2
of the SOA Blueprints Specification. 5 pages. [source]
SOA Random Links
• BEA dev2dev Center for Serviceoriented Architecture (SOA) and SOA Resource
Center
• HP SOA Services
• ServiceOriented Architecture (SOA) from IBM
• Service Oriented Architecture from Microsoft . See also SOA and BizTalk Business
Process Management (BPM) server.
• ServiceOriented Architecture from Oracle
• Enterprise SOAEnabled Solutions from SAP
• ServiceOriented Architecture (SOA) from Sun Microsystems
• Open Service Oriented Architecture (OSOA) Collaboration
• OSOA Chinese Community — maintained by Primeton
• Ascential's SOA Blog
• SOA Reference Model Glossary . From the SoaRefModel Wiki; see the OASIS
ebSOA TC.
• LooselyCoupled.com
• Microsoft .NET Architecture Center: SOA
• ServiceOrientation.org . Maintained by Thomas Erl.
• SOA Pipeline
• ZDNet SOA Blog: Capitalizing on Service Oriented Architecture
General References: Books, Articles, Papers, News
• [January 08, 2008] Service Science, Management, and Engineering. [fix link later]
Special Issue of IBM Systems Journal Volume 47, Number 1 (2008). "Recognizing
the growing significance of service innovation in the global economy, many in
academia and industry have suggested that there is a need for a new science of
service systems whose chief goal is the development of efficient and scalable
methods for service system analysis, design, implementation, and delivery. This
issue presents fourteen (14) papers on a variety of aspects of service science,
management, and engineering in an effort to help define and promote research in
this emerging multidisciplinary field.
• [January 08, 2008] "From Composition to Emergence: Towards the Realization of
PolicyOriented Enterprise Management." By Matthias Kaiser (Stanford University
Artificial Intelligence Lab [visiting scholar] and SAP Research Center in Palo Alto,
California [senior research scientist]). This paper (August 20, 2007, with 22
references) is a draft version of the Cover Feature Article "Toward the Realization of
PolicyOriented Enterprise Management," published in IEEE Computer Volume 40,
Number 11 (November 2007), pages 5763 [ISSN: 00189162; DOI: MC.2007.406].
"Today, serviceoriented architectures as basis for the composition of business
processes are widely seen as the stateoftheart approach to realize flexible,
extensible enterprise management. However, a number of problems how to
efficiently use this architecture to compose applications to support business goals is
still a hard problem requiring specific expertise as well as tedious human
involvement. In this article, we motivate and outline a new approach towards goal
driven business process composition based on the 'enterprise physics metaphor'. On
the foundation of formally stated business goals, descriptions of Web services and
the formalization of business policies, we explain how business processes capable to
achieve stated business goals can be generated utilizing generic, logicbased
strategies... Policyoriented enterprise management's essential objective is to show
the applicability, value, and feasibility of using computational logic in modern
enterprise management as a next step in software development. POEM's application
of computational logic can lead to a paradigmatic shift in the relationship between
enterprise management and the software supporting it. Such a shift might even close
the gap between business experts' understanding of their domain and software
engineers' realization of appropriate software. A goaldriven approach to business
process composition uses generic, logicbased strategies, descriptions of Web
services, and formalized business policies to generate business processes that
satisfy the stated business goals. The approach is based on an enterprise physics
metaphor, in which business objects are analogous to physical objects and policies
are analogous to physical laws. POEM addresses executable enterprise modeling:
not just a model, and not just executable: the model is the code — all of it. It
endeavors to be as direct an executable expression of policies as possible... The
POEM project exploits the ideas of the policyoriented approach in the business
environment...
The POEM interface assistant has to provide: (1) Achievment of 'realworld awareness'
by means of situation description, especially of elevant situation constituents; (2)
Assistance in formulating achievable process goals based on resources and context; (3)
Decision support for conflict resolution, policy acquisition and monitoring; (4) Explanation
of generated process designs (proofs), stating which services and policies were observed
and used, respectively; (5) Automatic generation of process design documentation. Such
an assistant consists of basically four components: Situation Analyzer (reports/alerts
about special circumstances so that the user can know and act accordingly), Goal
Recommender (generates business goals or subgoals which will lead to a new situation
where plans are completed and/or policies are satisfied), Explainer (information about
why a goal has been recommended and why this goal is relevant in the current situation),
and Guide (explicates actions which, if carried out, will help achieve the goal)..." Policy
Oriented Enterprise Management (POEM) is a SAP research collaboration with the
Stanford Logic Group, supported by The Digital Enterprise Research Institute at Stanford
(DERI Stanford). See the presentation by Charles Petrie. Note: IEEE Computer 40/11
(November 2007) is an IEEE Special Issue on Service Orientation; see the table of
contents and the article abstracts.
• [December 2007] " IBM Business Transformation Enabled by ServiceOriented
Architecture." By Lance Walker (Chief Architect for IBM internal integration
architecture, and project lead for the corporate initiative to embed SOA into the IBM
internal architecture). Published in a special issue of IBM Systems Journal "IT
Enabled Business Transformation", Volume 46, Number 4, 2007. Also in PDF format.
"This paper discusses the use of serviceoriented architecture (SOA) as one of the
key elements supporting business transformation at IBM. It describes the internal
SOA strategy, SOA governance, organizational impacts, and several IBM internal
SOA case studies. The topdown and bottomup approaches to promoting SOA
within the enterprise are also illustrated, along with a set of SOA business and
information technology lessons learned... Common messaging specification: EIMS
(Enterprise Integration Messaging Specification) is a common messaging format
which has been successfully deployed by the IBM Enterprise Business Information
team to support a number of internal applications. It defines and creates reusable
message constructs and data vocabularies. These Extensible Markup Language
(XML) message constructs provide a common data structure and common data
semantics for IBM internal messages. EIMS extends the Business Object Document
specification of the Open Application Group,2 and has been documented in the IBM
internal strategic SOA recommendations for applicationtoapplication
communications... Additional interoperability standards: From a service consumer's
perspective, some level of consistency in interfaces is required to facilitate
interactions involving multiple services, such as when composite business services
are involved. The Developing Web Services internal standard was mandated to
increase the interoperability and consistency of deployed Web services. This internal
standard uses WSI (Web Services Interoperability) industry standard as basis for
extensions that address IBM unique requirements. REST (Representational State
Transfer) style services are also being incorporated into the internal standards. As an
example, additional requirements and guidelines are being written into this IBM
internal standard to ensure a consistent description of REST services, because this
style is not governed by industry standards (such standards do exist for SOAPbased
services, namely Web Services Description Language). Messaging standardization
is achieved with the IBM internal Enterprise Integration Messaging Specification
(EIMS)...
• [November 207] "Component Contracts in ServiceOriented Architectures." By
Francisco Curbera (IBM T.J. Watson Research Center). From IEEE Computer
Volume 40, Number 11 (November 2007), pages 7480 [ISSN: 00189162]. "At the
core of serviceoriented architectures (SOAs) are distributed software components
provided or accessed by independent third parties. Because access is not limited to
a specific organization, explicit component contracts and universally adopted
standards must support thirdparty access. Although such contracts could cover any
technical or business aspect of service interaction, the current focus is on qualityof
service (QoS) policies. From an SOA point of view, we must consider two separate
aspects of the use of QoS policies: interoperability between components, which is
the subject of the Web services specifications stack; and composition, which
composition models, such as the service component architecture (SCA)... Policies
encode QoS properties such as security, reliable delivery, and transactional behavior.
SOA contracts based on these Web services standards are already becoming
commonplace in enterprise and scientific computing. However, basic support is not
enough. If the SOA concept is to achieve its full potential, the SOA framework must
evolve toward richer and more meaningful contracts. To meet this objective, work is
under way on industry specific standards to provide shared business semantic
definitions across industries, and there is significant growth in semantic Web
services research to provide a more flexible support environment for such contracts.
These two developments — one to standardize industryspecific semantics and the
other to incorporate semantic capabilities into the basic infrastructure — are
complementary and could revolutionize the practice of SOA and enterprise
computing... There are two models of service composition in SOAs. Processoriented
composition combines services using a workflow model to define a new service
component. The Business Process Execution Language (BPEL) specification is the
prototype for this composition model. Structural composition focuses on identifying
the participating components and the component connections that represent
component interaction channels...
To date, the SCA specification is the most complete specification of a structural
composition model for SOA. Unlike BPEL, SCA explicitly addresses the policy aspects of
service composition. As of September 2007, the SCA specification was under OASIS
review for standardization... The SCA specification lets component assemblers specify
policies on the wires between components by associating QoS properties with the
binding attached to the wire. These policies govern the interaction across component
boundaries, and their use is a direct application of the Web services interoperability
stack's policy model. SCA extends the Web services policy model in two significant ways,
by introducing (1) implementation policies: policies that represent implementation
behaviors, policies not necessarily related to component interaction; (2) policy intents:
abstract policy features that represent QoS capabilities independent of a particular
protocol... Service composition, whether processoriented or structural, centers on the
services' functional characteristics. Both BPEL and SCA build their composition models
on WSDL business interfaces. However, as an SCA developer assembles services and
components into new composites, the QoS properties of components and wires are also
implicitly composed in ways that are usually hard to understand or predict. A major
challenge when composing policyrich SOA components is to determine a composite's
QoS properties — to understand how the QoS properties of individual services aggregate
during composition. Clearly, policy composition remains one of the most challenging
aspects of serviceoriented computing research, and continues to be one of the least
understood. Establishing contracts for service composition remains one of the most
challenging research areas in SOA and will require significant attention to individual policy
domains...
Note: IEEE Computer 40/11 (November 2007) is an IEEE Special Issue on Service
Orientation; see the table of contents and the article abstracts. See, for example: (1)
"Service Is in the Eyes of the Beholder" (Tiziana Margaria); (2) "ServiceOriented
Computing: State of the Art and Research Challenges" (Michael P. Papazoglou, et al.);
(3) "Evolution of SOA Concepts in Telecommunications" (Thomas Magedanz, et al.); (4)
"Service Orientation in the Enterprise" (Jan Bosch, et al.); (5) "Toward the Realization of
PolicyOriented Enterprise Management" (Matthias Kaiser); (6) "Full LifeCycle Support
for EndtoEnd Processes" (Bernhard Steffen, et al).
• [September 28, 2006] OIO Service Oriented Infrastructure: Exchange of business
messages over the Internet. The OIO Service Oriented Infrastructure is an inititiave
with the aim to establish a framework for the exchange of business documents over
the internet in a secure and reliable fashion. The initiative is primariliy targeted at
small and medium sized business, and public government. The initiative comprises 3
elements: (1) An addressing mechanism which enables lookup of service providers
and their endpoints. Service registration is based on CVRnumbers and possibly
EAN location numbers. (2) A web service profile or a socalled interoperability
profile. The profile is a specification of a collection of web service standards,
assembled on the basis of a set of business requirements. (3) A software toolkit and
a client reference implementation — a socalled message handler. The software
tookit is implemented on both the Java and .Net platforms, in order that software
vendors and system integrators in the easiest possible way can offer endpoint lookup
with the addressing mechanism, and exchange of business documents in
accordance with the profile..." See the overview page.
• [July 20, 2006] "Reference Model for Service Oriented Architecture 1.0." OASIS
[balloted/approved] Committee Specification. Produced by members of the OASIS
SOA Reference Model TC. Edited by C. Matthew MacKenzie (Adobe Systems
Incorporated), Ken Laskey (MITRE Corporation), Francis McCabe (Fujitsu Limited),
Peter F Brown, and Rebekah Metz (Booz Allen Hamilton). 5July2006. 31 pages.
"This Reference Model for Service Oriented Architecture is an abstract framework for
understanding significant entities and relationships between them within a
serviceoriented environment, and for the development of consistent standards or
specifications supporting that environment. It is based on unifying concepts of SOA
and may be used by architects developing specific service oriented architectures or
in training and explaining SOA. A reference model is not directly tied to any
standards, technologies or other concrete implementation details. It does seek to
provide a common semantics that can be used unambiguously across and between
different implementations. The relationship between the Reference Model and
particular architectures, technologies and other aspects of SOA is illustrated in
[specification figure 1]. While serviceorientation may be a popular concept found in
a broad variety of applications, this reference model focuses on the field of software
architecture. The concepts and relationships described may apply to other "service"
environments; however, this specification makes no attempt to completely account
for use outside of the software domain..." [source PDF]
• [June 15, 2006] Reference Model for Service Oriented Architecture 1.0. Produced by
members of the OASIS SOA Reference Model Technical Committee. Public Review
Draft 2. 20060531. Edited by C. Matthew MacKenzie (Adobe Systems
Peter F. Brown, and Rebekah Metz (Booz Allen Hamilton). 31 pages. Second Public
Review announcement. "This Reference Model for Service Oriented Architecture is
an abstract framework for understanding significant entities and relationships
between them within a serviceoriented environment, and for the development of
consistent standards or specifications supporting that environment. It is based on
unifying concepts of SOA and may be used by architects developing specific service
oriented architectures or in training and explaining SOA. A reference model is not
directly tied to any standards, technologies or other concrete implementation details.
It does seek to provide a common semantics that can be used unambiguously
across and between different implementations. While serviceorientation may be a
popular concept found in a broad variety of applications, this reference model
focuses on the field of software architecture. The concepts and relationships
described may apply to other 'service' environments; however, this specification
makes no attempt to completely account for use outside of the software domain..."
• [March 01, 2006] Reference Model for Service Oriented Architecture. Produced by
members of the OASIS SOA Reference Model Technical Committee. Committee
Draft, February 07, 2006. Edited by C. Matthew MacKenzie (Adobe Systems
Peter Brown, and Rebekah Metz (Booz Allen Hamilton). "This reference Model for
Service Oriented Architecture is an abstract framework for understanding significant
entities and relationships between them within a serviceoriented environment, and
for the development of consistent standards or specifications supporting that
environment. It is based on unifying concepts of SOA and may be used by architects
developing specific service oriented architectures or in training and explaining SOA.
A reference model is not directly tied to any standards, technologies or other
concrete implementation details. It does seek to provide a common semantics that
can be used unambiguously across and between different implementations. While
serviceorientation may be a popular concept found in a broad variety of applications,
this reference model focuses on the field of software architecture. The concepts and
relationships described may apply to other 'service' environments; however, this
specification makes no attempt to completely account for use outside of the software
domain..." [source PDF]
• [September 20, 2005] "SOA Infrastructure Leaders Introduce New SOA Maturity
Model. AmberPoint, Sonic Software and Systinet Collaborate on Model to Assess,
Guide and Establish Vision for Maximizing the Strategic Benefits of SOA
investments. Launch 10City Management Forum Tour." "Sonic Software
(www.sonicsoftware.com), the inventor and leading provider of the enterprise service
bus (ESB), today announced that it has joined forces with AmberPoint
(www.amberpoint.com), and Systinet (www.systinet.com) to create and publish a
new ServiceOriented Architecture (SOA) Maturity Model (SOA MM). Together these
firms will publicly present the SOA Maturity Model to senior IT decision managers
during a 10city Management Forum Seminar Series designed to educate managers
on the strategic business value of SOA. Influenced by field experience in thousands
of SOA implementations, Forrester Research Vice President Randy Heffner, and
leveraging the well known SEI Capability Maturity Model Integration (CMMI), this
New SOA Maturity Model provides a tool that managers can use to assess their
teams, projects and overall organizational capabilities with respect to SOA maturity.
The model defines five levels of maturity and sets a vision for business benefits
realized at each of these levels. IT decision makers can use this model to educate
business managers and set expectations within executive teams. Using the SOA
Maturity Model, managers can determine at what level their organization is currently
executing and can see where they can go in terms of advancing up to higher levels of
maturity. The model also provides recommendations for setting management goals
and identifies key practices that need to be performed with regularity before
advancing. Following its debut in the Management Forums, the New SOA Maturity
Model will be published to the public on October 27, 2005..."
• [September 12, 2005] "Building SOA Your Way. Every enterprise needs to find its
own balance between complete, scalable architecture and simply building a service
oriented architecture that works." By Jon Udell. From InfoWorld (September 12,
2005). "A fault line runs beneath the groundswell that began a few years ago with
XML Web services and continues today as SOA. True, nearly everyone agrees that
XML messaging is the right way to implement lowlevel, platformagnostic services
that can be composed into higherlevel services that support enterprises business
functions. Yet, here's also a sense that the standards process has run amok. BM,
Microsoft, and others have proposed so many Web services standards that a new
collective noun had to be invented: WS* (pronounced 'WS star' or sometimes 'WS
splat'). The asterisk is a wild card that can stand for Addressing, Eventing, Policy,
Routing, Reliability, ReliableMessaging, SecureConversation, Security, Transactions,
Trust, and a frighteningly long list of other terms. Surveying this landscape, XML co
creator Tim Bray pronounced the WS* stack 'bloated, opaque, and insanely
complex.' It wasn't always so. Simple forms of XML messaging were succeeding in
the field long before any of these standards emerged. At InfoWorld's SOA Executive
Forum in May, Metratech CTO Jim Culbert described how his company's service
oriented billing system worked back in the late 1990s. The messages exchanged
among partners were modeled in XML and transported using HTTP with SSL
encryption the method still used for most secure Web services communication
today. Seybold analyst Brenda Michelson, who was then chief architect at L.L. Bean,
tells a similar story about that company's early experience with Web services. Two
factors were prominent at the time. First, the Web offered a simple, pervasive
integration framework, one later promoted to the status of architecture and assigned
the label REST (Representational State Transfer). Second, XML provided a universal
way to define services in terms of the data they produced or consumed, rather than
in terms of the code that produced or consumed the data. In combination, these
factors were — and still are — powerful enablers..."
• [September 09, 2005] "Iona Joins Eclipse, Proposes SOA Effort." By Paul Krill. From
InfoWorld (September 09, 2005). "Melding the contemporary concepts of SOA and
open source, Iona Technologies is announcing its participation in the Eclipse
Foundation and will propose an Eclipse SOA Tools Platform Project [within 3060
days]. The company is joining as an Eclipse Strategic Developer and will serve on
the open source tools organization's board of directors, which votes on Eclipse
policies. Iona's SOA tools proposal would constitute the ninth toplevel project at
Eclipse, among other projects such as the Web tools and data tools projects,
according to Iona and Eclipse officials. The project is intended to provide a developer
tooling platform for SOAbased infrastructure, serving as a foundation from which an
extensible toolset for building SOA applications can be developed, according to Iona.
Included in the initial scope of the project are developer requirements for creation of
service providers and consumers, configuration of physical assets of a service and
defining policies and governance for consumption of services. Also to be covered are
the adding of services to an SOA and development of artifacts for deploying or
managing SOAbased system participants. The SOA effort will feature exemplary
components for hooking to specific run times, such as Java Enterprise Edition, Java
Standard Edition, and Java Business Integration. An SOA component could run
inside an application server, for example..."
• [September 09, 2005] Semantion FERAbased SOA Information Model, RunTime
SOA, and SOA Collaboration Semantics (CS). Semantion Inc. contributed its FERA
based SOA specification documents to the OASIS Electronic Business Service
Oriented Architecture (ebSOA) TC. According to the posting, the Federated
Enterprise Reference Architecture (FERA) specification includes three documents:
[1] Runtime Service Oriented Architecture (SOA) V0.1, [2] Service Oriented
Architecture Information Model (SOA IM) V0.1, and [3] Service Oriented Architecture
Collaboration Semantics (SOA CS) V0.1. The first two were contributed; the third will
be available "in the next few weeks and will be submitted to the ebSOA TC as well."
See the posting "Semantion's FERAbased SOA Contribution" from Goran Zugic
Goran Zugic (Chief Architect, Semantion Inc).
o Service Oriented Architecture Information Model (SOA IM) v0.1 . Semantion
Inc. July 2005. 36 pages. "Semantion addresses SOA semantic integration
providing two SOA specifications: SOA Information Model (IM) and SOA
Collaboration Semantics (CS). SOA IM can be stored in a standard registry
like OASIS ebXML Registry or OASIS UDDI and used to provide
informational support for both context and content related to any business
process. The SOA IM is presented in a form of an open standardbased XML
document referred to as the Collaborative Process Information Document
(CPID) that can be either created manually or generated from a business
process definition using a visual modeling tool. This document contains SOA
IM details and CPID creation rules based on the OASIS ebXML Registry
Information Model (RIM) and OASIS ebXML Registry Services (RS)
standard specifications. CPID creation rules based on the OASIS UDDI will
be provided in one of the future releases of this document..."
['SOA_IM_V0.1.doc', source .DOC, cache, later in repository]
o Runtime Service Oriented Architecture (SOA) v0.1 . Semantion Inc. July
2005. 19 pages. "SOAbased systems do not require traditional programming
language coding. A complete SOA runtime specification in a XML form is
generated from the collaborative process model by explicitly defining
services, their inputs, their outputs and their static and dynamic
choreography. This specification is captured in open standard XMLbased
deployment documents that support collaborative process execution on
SOA. Three main principles of the SOA architecture are: completeness, open
standardsbased, and standards convergence... The SOA components are
based on open standards with the exception of the agent framework and
business rules. There are no adequate agent framework or business rules
standards available today that are conforming to all SOA requirements and
one of the ebSOA TC goals will be to initiate and support the development of
agent framework and business rules standards as well. All other SOA
components are standardbased... The main components of the FERA
reference architecture are: federates, interfaces, and SOA Federation. Each
participant involved in the collaboration is called a federate. Federates can
be systems or people..." ['Runtime_SOA_V0.1.doc', source .DOC, cache,
later in repository]
• [September 05, 2005] "End Users to Gain Voice in SOA Blueprints." By Vance
McCarthy. From Integration Developer News (September 05, 2005). "Finally, it
appears that enterprise end users will get their chance to influence the creation of
SOA Blueprints for the real world. IDN [here] examines the results of the first OASIS
meeting, where vendors of products and services will now work closely with leading
enterprise end user firms in banking, manufacturing and other sectors. Discussions
of SOA (Service Oriented Architecture) are about the leave the world of vendor
speak and enter the real world. Or at least that's the hope, as OASIS held its first
meeting of the newlyformed SOA Adoption Blueprints technical committee last
week. OASIS SOA Adoption Blueprints TC will seek to define J2EE and .NET neutral
patterns or recipes for how end user companies can build SOA projects for their
internal enterprise, as well as for B2B integrations. Miko Matsumura, Chair of the
SOA Adoption Blueprints TC: 'Before this committee, SOA was a bit of a closed club,
basically consisting of middleware companies and some major platform companies.
But there wasn't much input from database or application companies, and hardly any
from implementers, integrators or end users. Now, we're looking to let SOA patterns
work take on a completely new character by bringing in all these new voices and
points of view. In fact, if we do this right, it will be the end users who gather around
and tell us what to do, rather than before, when we've got all the middleware
companies telling us all how SOA should work'..." See: SOA Blueprints.
• [June 15, 2005] Sun Microsystems has announced the development of a Web
Services Registry and Repository for building ServiceOriented Architectures (SOA).
Based upon the open source ebXML Registry Reference Implementation Project
'freebXML', the Sun Service Registry offers a unique singleregistry solution
supporting both UDDI v3 and ebXML Registry 3.0 standards. It enables customers to
publish, manage, govern, discover, and reuse services across diverse applications.
Common use cases for Sun's Service Registry include: (1) "Publication,
management, governance, discovery and reuse of Web Services and related SOA
Artifacts; (2) Taxonomy management; (3) XML Schema management; (4) Vocabulary
Management; (5) Business Process registry; (6) Medical content repository. It
features a single registry solution supports wide customer adoption across diverse
domains." The Sun's Service Registry is based a number of established standards in
addition to ebXML Registry 3.0 and UDDI 3.0. Supported XML Standards include
XACML 1.0 for Role Based Access Control Policies, SOAP 1.1 with Attachments,
WSDL 1.1, XML Signature 1.0, XSLT 1.0, Web Services Security: SOAP Message
Security 1.0, Web Services Security: SOAP Message with Attachments (SwA) Profile
1.0, WSI: Basic Security Profile 1.0, WSI: Basic Profile 1.1, and SAML 2.0.
Implemented entirely on the Java Platform, the Sun Service Registry supports
standards included in the Java Web Services Developer Pack (JAXR 1.0, JAXRPC
1.1, SAAJ 1.2, JAXB 1.0, JAXP 1.2), and SQL92. An Early Access version of Sun's
Service Registry is included in Java Web Services Developer Pack (Java WSDP)
Version 1.6, planned for general distribution in June 2005. It is also to be tightly
integrated into Java Enterprise System. Sun plans to demonstrate the Service
Registry at JavaOne 2005 conference, and will ship the product as part of the Java
Enterprise System Release 4 [Java ES R4] in the Fall of 2005. See details in the
news story "Sun Service Registry for SOA Supports UDDI 3.0 and ebXML Registry
3.0 Standards."
• [May 12, 2005] Service Oriented Architecture Reference Model. Working Draft
Version 07. May 12, 2005. Document identifier: 'wdsoarm07'. Described by co
editor C. Matthew MacKenzie as the "first 'real' draft." Edited by C. Matthew
MacKenzie (Adobe Systems Incorporated), John Harby (Individual), Michael Ruiz
(BAE Systems PLC), Christopher Bashioum (Mitre Corporation), Ken Laskey (Mitre
Corporation), Wesley McGregor (Government of Canada PWGSC), Francis
McCabe (Fujitsu Limited), Don Flinn (Individual), Peter Brown (Individual) and Vikas
Deolaliker (Sonoa Systems, Inc). "This Service Oriented Architecture Reference
Model is an abstract framework for understanding significant entities and
relationships amongst them within a serviceoriented environment, and for the
development of consistent standards or specifications supporting that environment. It
is based on unifying concepts of SOA and may be used by architects developing
specific services oriented architectures or for education and explaining SOA. A
reference model is not directly tied to any standards, technologies or other concrete
implementation details, but it does seek to provide a common semantics that can be
used unambiguously across and between different implementations. While service
orientation may be a popular concept found in system a broad variety of applications,
this reference model scopes itself to the field of software architecture..." [source
PDF]
• [April 21, 2005] "SOA Reference Model." By Jim Alateras. From O'Reilly Developer
Weblogs (April 21, 2005). "In February 2005 OASIS formed the SOARM TC (Service
Oriented Architecture Reference Model Technical Committee) and assigned it the
responsibility of developing an SOA Reference Model. The reference model will not
be tied to any particular implementation or set of standards but will define a shared
vocabulary and identify the common elements of a service oriented architecture (i.e
Service, Service Description, Service Advertising, Data Model, Contract etc). The
benefits of the reference model is that it offers a guide to people developing SOAs
and provides a context for discussing and comparing SOA implementations. All good
things in my opinion, especially with so many companies starting enterprisewide
SOA initiatives..." See the TC web site.
• [February 28, 2005] "HandsOn Scenarios for Starting SOA." By Clark D. Richey
(Principal Systems Engineer, BEA Systems' Government Systems Group). From
Integration Developer News (February 28, 2005). "This article is the second in a
series of articles aimed at helping developers, architects and managers navigate the
evershifting SOA landscape as you search for solutions to your SOA issue. When
building Service Oriented Architectures (SOAs), we strive to create loosely coupled
services, each of which performs a logical, discrete business function. These
services act as the building blocks for our application and ultimately, our enterprise
wide SOA. The loose coupling between our building blocks allows us to add new
building blocks and replace others as our business needs change. The chart
[provided] shows a possible path to an SOA, beginning at a client/server architecture.
In addition to indicating three major architecture types, client/server, web services
and serviceoriented, the chart describes major characteristics of each type of
architecture..."
• [February 21, 2005] "Service Oriented Architecture." By Duane Nickull (Adobe
Systems Incorporated), with contributions from Ed Chase, Mike Connor, Mark
Cowan, C. Matthew MacKenzie, and Ben Watson. Adobe White Paper. 10 pages
(with 25 references). Copyright (c) 2005 Adobe Systems Incorporated. "Service
Oriented Architecture (SOA) is currently a popular subject with no consensus or
standardized reference model to define it. While many believe that Web Services or
ebXML are SOA, they are in fact, specialized implementations of SOA. If SOA is truly
an architecture, it must be definable as one. The authors of this paper have started
standards work to define an SOA reference model as part of an OASIS project
[OASIS SOA Reference Model TC]. This paper examines SOA, its history, business
drivers and the standards that may be used to implement it. It attempts to define
SOA and reviews basic and extended models of SOA in use today. For the purposes
of this paper, SOA is defined by abstracting the common concepts and elements
from architectures and standards that claim to be service oriented. The localized
definition of SOA is therefore subject to change in the future... Service Oriented
Architecture (SOA) is an evolution of the Component Based Architecture, Interface
Based Design (Object Oriented) and Distributed Systems of the 1990s, such as
DCOM, CORBA, J2EE, and the Internet in general. SOA does not specifically mean
Web Services, .NET, J2EE, CORBA, or ebXML. These are instead specialized SOA
implementations that embody the core aspects of a serviceoriented approach to
architecture. Each of these implementations extends the basic SOA Reference
Model described in this paper... [Conclusions:] SOA is based on the use of
distributed objects and components and is the next evolutionary step in computing
environments. SOA does not have a standardized, reference model yet; however,
implementations share the main concepts of services, service descriptions,
advertising and discovery, the specification of an associated data model, and the use
of a service contract. An SOA may also implement optional concepts that include a
service consumer, a service client, acceptance of the service contract and invoking
the service. There are many business drivers affecting the development of a
standardized SOA reference model. Once this is achieved, SOA will likely be part of
the solution for many business and world issues..." For related Adobe resources, see
the Adobe LiveCycle Developer Center. For details on the OASIS Technical
Committee, see the news story of February 08, 2005: "OASIS Creates TC to Define
Service Oriented Architecture (SOA) Reference Model."
• [February 15, 2005] Understanding SOA with Web Services. By Eric Newcomer
(IONA, Chief Technology Officer) and Greg Lomow (BearingPoint, Inc). AWP
Independent Technology Guides. Published by AddisonWesley Professional, 2005
[December 14, 2004]. ISBN: 0321180860, 480 pages. See the Table of Contents
and sample chapter "Introduction to SOA with Web Services." "The serviceoriented
architecture (SOA) has also become widely recognized for its important role in
information technology projects. An SOA is a style of design that guides an
organization during all aspects of creating and using business services (including
conception, modeling, design, development, deployment, management, versioning,
and retirement). Despite some limitations (which we document), an SOA with Web
services is the ideal combination of architecture and technology for consistently
delivering robust, reusable services that support today's business needs and that
can be easily adapted to satisfy changing business requirements. Think about an
SOA as an assembly line in a factory. It's an investment in the future operation of
your business, so a significant amount of planning, design, and development may
have to go into it before it starts to really pay off. The first car off a production line is
more expensive than the thousandth. Similarly, the first service deployed in an SOA
is more expensive than the hundredth. The major benefits of SOA arrive over time,
although as we will see, it is possible to start small and incrementally build up to a
fullfledged SOA. SOA with Web services is important because it aligns information
technology (IT) with business requirements and because it reduces the costs of IT
systems and applications. An SOA gives you the ability to more easily integrate IT
systems, provide multichannel access to your systems, and to automate business
processes..."
• [February 15, 2005] Enterprise Service Bus. By Dave Chappell (Sonic Software, Vice
President and Chief Technology Evangelist). Published by O'Reilly, June 2004. ISBN:
0596006756, 352 pages. See the Table of Contents. "An Enterprise Service Bus
(ESB) is a standardsbased integration platform that combines messaging, web
services, data transformation and intelligent routing in an eventdriven Service
Oriented Architecture (SOA)... The ESB is having a profound impact on the way IT
architects, and the industry at large, approach enterprise integration and service
oriented architectures (SOAs). In the last few years, more than eight ESB products
were introduced, and a myriad of articles about this new product category appeared
in the trade journals. Nevertheless, there is still a great deal of confusion mixed in
with the high interest in ESBs, so I wanted to write a guide about the technology.
ESBs developed out of the confluence of standardsbased messaging, XML, SOAs,
and Web services. Customers started to talk about combining an enterprise
messaging backbone with a services registry. Ultimately, a new and unique
distributedservices architecture was needed to make the concept of the ESB a
reality... O'Reilly's Enterprise Service Bus provides you with both a conceptual and
architectural overview of ESB from the viewpoint of a seasoned expert in the areas
of standards for enterprise messaging, web services and SOA. In it, Dave Chappell
offers his unique insights gained from years of working with the pioneers and
innovators defining the ESB and delivers practical strategies for understanding the
architecture of an ESB and its impact on integrating diverse applications into
enterprisewide solutions. He then goes on to present integration patterns that clearly
show how an ESB can help solve the thorniest application integration challenges
using standard components and interfaces..."
• [February 14, 2005] ServiceOriented Software System Engineering: Challenges and
Practices. By Zoran Stojanovic and Ajantha Dahanayake (Delft University of
Technology, The Netherlands). ISBN: 1591404266. 300 pages. Publisher's book
abstract: "Current IT developments like componentbased development and Web
services have emerged as effective ways of building complex enterprisescale
information systems and providing enterprise application integration. To aid this
process, platforms such as .NET and WebSphere have become standards in web
based systems development. However, there are still a lot of issues that need to be
addressed before serviceoriented software engineering (SOSE) becomes a
prominent and widely accepted paradigm for enterprise information systems
development and integration. ServiceOriented Software System Engineering:
Challenges and Practices provides a comprehensive view of SOSE through a
number of different perspectives. Some of those perspectives include: servicebased
concepts, modeling and documentation, service discovery and composition, service
oriented architecture, modeldriven development of serviceoriented applications,
service security and serviceorientation in mobile settings. It provides readers with an
indepth knowledge of the main challenges and practices in the exciting, new world
of serviceoriented software engineering. Addressing both technical and
organizational aspects of this new field, this book offers a balance making it valuable
to a variety of readers, including IT architects, developers, managers, and analysts."
• [February 02, 2005] "ESB Myth Busters: 10 Enterprise Service Bus Myths Debunked.
Clarity of Definition for a Growing Phenomenon." By Dave Chappell (Sonic
Software). In Web Services Journal (February 2, 2005). " Since the release of
Enterprise Service Bus (O'Reilly Media, 2004) the author reports "discussing with
enterprise architects the subject of enterprise serviceoriented architecture (SOA)
and how an enterprise service bus (ESB) backbone can be leveraged to provide a
framework for an enterprise SOA...being asked many questions about the nature of
an ESB. Here he gathers together the most popular questions and misconceptions,
and offer some clarity in the form of a top ten list... To sum this up, make sure that
your understanding of ESB contains these things: (1) An ESB provides the backbone
for building an enterprise SOAbased integration environment. (2) The evolving WS*
specifications will help make ESBs even more interoperable than they are today.
Adopting an ESB today will allow you to build for the future and be capable of
adapting to the WS* specifications as they become commercially viable. (3) ESB is
not just an abstract pattern. It is a product category with a distinct definition and
many vendor offerings. (4) ESBs and application servers are highly complementary.
(5) ESBs can help portal server integration to backend systems by providing the
necessary diversity in connectivity and scalable infrastructure. (6) ESBs provide
many choices for coordinating service interactions. (7) ESB technology is grounded
in reality and is already being adopted by many industries. (8) ESBs can provide the
higherlevel visual tools for integrating services in an ISE environment. (9) ESBs
provide a service container environment that is lightweight, configurable, and highly
distributable..."
• [February 01, 2005] "Agile to the Bone. Serviceoriented Architecture Lets You
Respond Quickly to Demands for New and Improved Processes." By Bruce Silver.
From Intelligent Enterprise (February 01, 2005). "To achieve agility without breaking
the bank, you can't simply rip and replace. You must break down legacy stovepipes
into modular components that can be reused in multiple business processes. That's
precisely the promise of a new style of software development called serviceoriented
architecture. With SOA, applications are no longer built as monoliths. Instead, they're
composed by assembling modular services. Think of a service as a single software
function, such as GetAccountBalance or CancelOrder, that can be executed on
request by any system, regardless of its operating system platform, programming
language or geographic location. SOA isn't new conceptually, but its current
implementation in the form of Web services is revolutionizing software development.
While previous generations of distributed software architecture promised agility and
component reuse, there was always a catch: To allow integration, all components
had to use a common object model or programming language. SOA's ability to
compose processes by assembling standard service building blocks is central to
BPM's promise of agility. Standard SOA design tools make the task of building a
service orchestration model as fast and easy as drawing a flowchart of services. The
same tools then turn the model into an executable business process..."
• [January 26, 2005] "IBM to Help Customers Focus on Growth Through Business
Transformation. New Service Provides Systematic Approach to Link Business Goals
to Technology Resources." "IBM today announced a new service to help companies
build capabilities that support business goals, while freeing up currently
overstretched IT budgets to focus on growth opportunities. The new Service Oriented
Modeling and Architecture (SOMA) is an innovative approach to solving a significant
problem, a consistent way for businesses to develop flexible technology that will
provide the maximum return back to the business. It helps companies implement a
serviceoriented architecture (SOA), a standardsbased framework that enables
enterprises to evolve to on demand businesses that integrate data and applications
with customers, partners and suppliers. To make improvements and grow,
businesses need better visibility into their business processes. Breaking the business
down into a component view — from a discrete process or the business processes
supporting the entire enterprise — is critical to achieving business improvement and
growth. Business process modeling will map out a company's business processes
and help determine which business processes provide strategic differentiation over
competitors, what processes are core and what business processes may not be
considered strategic. However, once this is done, companies often lack a flexible IT
infrastructure to support change that creates growth... SOMA provides an approach
to building an SOA that aligns to the business goals and directly ties the business
processes to underlying applications through services, which will help the business
realize benefits more rapidly..."
• [April 21, 2004] "ServiceOriented Architecture Expands the Vision of Web Services,
Part 1. Characteristics of ServiceOriented Architecture." By Mark Colan (ebusiness
evangelist, IBM Corporation). From IBM developerWorks (April 21, 2004). "SOA
presents the big picture of what you can do with Web services. Web services
specifications define the details needed to implement services and interact with
them. However, SOA is an approach to build distributed systems that deliver
application functionality as services to enduser applications or to build other
services. SOA can be based on Web services, but it may use other technologies
instead. In using SOA to design distributed applications, you can expand the use of
Web services from simple clientserver models to systems of arbitrary complexity..."
• [April, 2004] "New to SOA and Web Services." From IBM developerWorks (April
2004). "A SOA (ServiceOriented Architecture) is a component model that inter
relates the different functional units of an application, called services, through well
defined interfaces and contracts between these services. The interface is defined in
a neutral manner that should be independent of the hardware platform, the operating
system, and the programming language the service is implemented in. This allows
services, built on a variety of such systems, to interact with each other in a uniform
and universal manner. This feature of having a neutral interface definition that is not
strongly tied to a particular implementation is known as loose coupling between
services. The benefit of a looselycoupled system lies in its agility and the ability to
survive evolutionary changes in the structure and implementation of the internals of
each service, that make up the whole application. Tightcoupling on the other hand
means that the interfaces between the different components of an application are
tightly interrelated in function and form, thus making them brittle when any form of
change is required to parts or the whole application..."
• [March 10, 2004] "The SOA Reference Model." By John Cheesman and Georgios
Ntinolazos. From the CBDI Service Oriented Architecture Practice Portal. March 10,
2004. "This is the first in a series of articles in which we provide precise guidance on
implementing SOA. This builds upon and further details many of concepts introduced
in our five part series last year, and will progressively create a common reference
model and process for SOA."
• [January 2004] "Understanding ServiceOriented Architecture." By David Sprott and
Lawrence Wilkes (CBDI Forum). Microsoft Architect Journal. January 2004. "This
paper gives a concise explanation of serviceoriented architecture, what it is, and
how it affects what architects, CIOs, project managers, business analysts, and lead
developers do... The optimum implementation architecture for SOA is a component
based architecture. Many will be familiar with the concepts of process and entity
component, and will understand the inherent stability and flexibility of this component
architecture, which provide a one to one mapping between business entities and
component implementations. Enterprise SOA (ESOA) brings the two main threads —
Web services and CBD (or CBSE) — together. The result is an enterprise SOA that
applies to both Web services made available externally and also to core business
component services built or specified for internal use...The goal for a SOA is a world
wide mesh of collaborating services, which are published and available for invocation
on the Service Bus. Adopting SOA is essential to deliver the business agility and IT
flexibility promised by Web Services. These benefits are delivered not by just viewing
service architecture from a technology perspective and the adoption of Web Service
protocols, but require the creation of a Service Oriented Environment that is based
on the following key principals we articulate in this article: (1) Service is the important
concept. Web Services are the set of protocols by which Services can be published,
discovered and used in a technology neutral, standard form. (2) SOA is not just an
architecture of services seen from a technology perspective, but the policies,
practices, and frameworks by which we ensure the right services are provided and
consumed. (3) With SOA it is critical to implement processes that ensure that there
are at least two different and separate processes — for provider and consumer. (4)
Rather than leaving developers to discover individual services and put them into
context, the Business Service Bus is instead their starting point that guides them to a
coherent set that has been assembled for their domain. For further guidance on
planning and managing the transition to Web Services and SOA, CBDI are providing
the 'Web Services Roadmap', a set of resources that are freely available [online.

Service Oriented Architecture

Caricato da

Informazioni sul documento

Descrizione originale:

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Service Oriented Architecture

Caricato da

Copyright:

Formati disponibili

Service Oriented Architecture (SOA)

Potrebbero piacerti anche