ICT 1 Enterprise Architecture (EA) Service-Oriented Architecture (SOA) Web Services Architecture (WSA) NorStella SOA-seminar 30.05.2007 Brian Elvesæter [email protected]
ICT 1
Enterprise Architecture (EA)Service-Oriented Architecture (SOA)Web Services Architecture (WSA)
NorStella SOA-seminar 30.05.2007
Brian Elvesæ[email protected]
ICT 2
Outline
What is an architecture? Enterprise architecture and enterprise modelling Interoperability Enterprise architecture and SOA Integration, SOA and Web services References
ICT 3
What is an architecture?
ICT 4
Different kinds of architectures
Business architecture
Integration architecture
Conceptual architecture
Architecture framework
Logical architecture
Knowledge architecture
Information architecture
Realisation architecture
Functional architecture
ICT architecture
Web servicesarchitecture
Enterprisearchitecture
Service-oriented
architecture
ICT 5
EA – SOA – WSA
Enterprise architecture (EA) is the practice of applying a method for describing a current and/or future structure and behaviour for an organization's processes, information systems, personnel and organizational sub-units, so that they align with the organization's core goals and strategic direction. Holistic view of the enterprise and all its important assets.
Service-oriented architecture (SOA) is a paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains. [OASIS 2006] Architectural style for designing (technical) systems.
Web services architecture (WSA) intends to provide a common definition for understanding Web services. A Web services architecture involves many layered and interrelated technologies. [W3C 2004] A set of enabling Web technologies for implementing software systems.
ICT 6
IEEE Std 1471-2000
IEEE Std 1471-2000 IEEE Recommended Practice for Architectural Description of Software-
Intensive Systems Adopted September 2000
Architecture definition Structure(s) of a system in terms of
components, their externally visible properties, their relations, and the underlying principles
Common frame of reference for architectural descriptions Common terminology
architecture, architectural description, model, view, viewpoint, system, stakeholder, concern, …
ICT 7
Developed using the methods established by its viewpoint, consisting of views expressing an architectural description.
The expression of a systems architecture with respect to a particular viewpoint. Addresses one or more of the concerns of the system stakeholder.
described by
identifies
SystemEnvironmentinfluences
inhabits
Mission
Stakeholder
has
fulfills
Architecturehas an
Architectural description
Concern
is important to
has identifies
ViewViewpointused to cover
is addressed to
selects organized by
conforms to
Modelestablishes methods for
participates in
consists of aggregates
participates in
Library viewpoint
has source
Rationaleprovides
1..*
1..*
1..*
1..*
1..* 1..*
1..*
1..*
1..*
1..*
0..1
1..*
1..*
1..*
1..*
The fundamental organisation of a system embodied in its components, their relationships to each other and to the environment, and the principles guiding its design and evolution.
Has interest in, or concerns relative to the system.
Those interests which pertain the system’s development, operation and other aspects that are critical or otherwise important to one or more stakeholders.
ICT 8
Architecture of what and for whom?Virtual enterprise
Business
Software system
Software component
Software object
SOA
EA
Decomposition
Bus1Bus2 Bus3
Bus4
SW syst1Actor1 Actor2
SW syst2
Decomposition
Comp1Comp2 Comp3
Comp4
Decomposition
Decomposition
Object1Object2 Object3
Object4
Datatype1Datatype2 Operation1
Datatype3
WSA
ICT 9
Enterprise architecture and enterprise modelling
ICT 10
History of enterprise architecture
The major pioneering efforts: Zachman Framework - initiated 1978 ARIS tool set - 1988 First Metis tool set - 1991 Troux Knowledge Repository - 2002
Four major approaches: Systems development case tools - 1984 IT process modelling - 1986 Product and process modelling - 1989 Business process management - 1995 Enterprise architecture modelling - 1997
ICT 11
Why enterprise architecture?
?
?
How can Iinvolve my peoplein improving theperformance of thebusiness
How can I use best practices to ensure the success of the business?
How can I ensure that the IS
technologyhelps the work of
my people?
?
ICT 12
Governance with enterprise architecture
Architecture is a strategic tool not just high-level design Architecture goes beyond ICT Enterprise architecture is a key
component of the IT governance process at any organization of significant size.
Stability and flexibility Seem to be contradictory, but a
good architecture facilitates change!
Communication with stakeholders architects, managers, customers,
engineers, … Analysis
impact-of-change cost and performance
Enterprise Architecture (EA) is a generic, abstracted and aggregated representation of the core structures and competences of an enterprise.
EA supports laying out the main characteristics of the enterprise to be analysed and agreed before detailed technical design is started.
It is shared and discussed enterprise-wide between all stakeholders as a common description forms, functions and features, components, properties and relationships.
ICT 13
Role of enterprise architecture
Mark Lankhorst et al., "Enterprise Architecture at Work: Modelling, Communication and Analysis", Springer, 2005, ISBN: 978-3-540-24371-7.
Mission
Goals
Strategy
Actions
Vision
as is to be
enterprise architecture
domain/aspectarchitectures
culture
people
leadership
Operations… peopleprocesses ITproducts
ICT 14
Describing coherence
Mark Lankhorst et al., "Enterprise Architecture at Work: Modelling, Communication and Analysis", Springer, 2005, ISBN: 978-3-540-24371-7.
Process architecture
Application architecture Technical architecture
Information architecture Product architecture
?
?
?
?
?
ICT 15
Enterprise modelling
Enterprise modelling (EM) is a capability for externalising, making and sharing enterprise knowledge.
EM tools can either be: used stand-alone to produce
various kinds of model views, integrated as front-ends to
other systems, part of an environment
providing a contextual user-environment.
ICT 16
Enterprise modelling languages
Enterprise modelling languages should allow building the model of an enterprise according to various points of view such as: function, process decision, economic, etc. in an integrated way.
Languages defined at high level of abstraction as constructs for EM are independent of the technology of implementation
Examples are: IEM Metis Enterprise Arcitecture
Framework (MEAF) CIMOSA GRAI IDEF PSL WPDL XPDL BPML EDOC BPDM EPC Archimate
ICT 17
Enterprise architecture frameworks
Enterprises architecture frameworks are fundamental structures which allows defining the main sets of concepts to model and to build an enterprise.
Architectural frameworks are designed to define views of specific enterprise domains.
Frameworks lack capabilities for meta-data management role-driven viewing integration with platforms model-driven design generation of interoperable
solutions
Examples are: ZACHMAN GERAM GRAI ARIS CIMOSA DoDAF TOGAF TEAF Troux/Metis/AKM ISO 15745 MISSION
ICT 18
Representations of architecture
ARIS ZACHMAN GERAM
EN/ISO 19439
NIST
EKA -POPSEKA -POPSEKA -POPS
ATHENA
ICT 19
Based on work by John A. Zachman
VA Enterprise Architecture
DATAWhat
FUNCTIONHow
NETWORKWhere
PEOPLEWho
TIMEWhen
MOTIVATIONWhy
DATAWhat
FUNCTIONHow
NETWORKWhere
PEOPLEWho
TIMEWhen
MOTIVATIONWhy
SCOPE(CONTEXTUAL)
Planner
ENTERPRISEMODEL(CONCEPTU AL)
Owner
SYSTEM MODEL(LOGICAL)
Designer
TECHNOLOGYMODEL(PHYSICAL)
Builder
DETAILEDREPRESENTATIONS(OUT-OF-CONTEXT)
Sub-Contractor
FUNCTIONINGENTERPRISE
SCOPE(CONTEXTUAL)
Planner
ENTERPRISEMODEL
(CONCEPTU AL)
Owner
SYSTEM MODEL(LOGICAL)
Designer
TECHNOLOGYMODEL
(PHYSICAL)
Builder
DETAILEDREPRESENTATIONS(OUT-OF-CONTEXT)
Sub-Contractor
FUNCTIONINGENTERPRISE
Things Important to the Business
Entity = Class of Business Thing
Processes Performed
Function = Class of Business Process
Semantic Model
Ent = Business Entity Rel = Business Relationship
Business Process Model
Proc = Business Process I/O = Business Resources
Business LogisticsSystem
Node = Business Location Link = Business Linkage
Work Flow Model
People = Organization Unit Work = Work Product
Master Schedule
Time = Business Event Cycle = Business Cycle
Business Plan
End = Business Objectiv e Means = Business Strategy
ImportantOrganizations
People = Major Organizations
Business locations
Node = Major Business Locations
Ev ents Significantto the Business
Time = MajorBusiness Event
Business Goalsand Strategy
Ends/Means =Major Business Goals
Logical DataModel
Ent = Data Entity Rel = Data Relationship
Application Architecture
Proc = Application Function I/O = User Views
Distributed SystemArchitecture
Node = IS Function Link = Line Characteristics
Human InterfaceArchitecture
People = Role Work = Deliv erable
ProcessingStructure
Time = System Event Cycle = Processing Cycle
Business RuleModel
End = Structural Assertion Means = Action Assertion
Physical DataModel
Ent = Segment/Table Rel = Pointer/Key
SystemDesign
Proc = Computer Function I/O = Data Elements/Sets
TechnologyArchitecture
Node = Hardware/Softw are Link = Line Specifications
PresentationArchitecture
People = User Work = Screen Format
ControlStructure
Time = Ex ecute Cycle = Component Cycle
RuleDesign
End = Condition Means = Action
DataDefinition
Ent = Field Rel = Address
Program
Proc = Language Statement I/O = Control Block
Netw orkArchitecture
Node = Addresses Link = Protocols
SecurityArchitecture
People = IdentityWork = Job
Timing Definition
Time = InterruptCycle = Machine Cycle
RuleDesign
End = Sub-Condition Means = Step
Data
Ent = Rel =
Function
Proc =I/O =
Netw ork
Node = Link =
Organization
People = Work =
Schedule
Time = Cycle =
Strategy
End = Means =
Based on work by John A. Zachman
VA Enterprise Architecture
DATAWhat
FUNCTIONHow
NETWORKWhere
PEOPLEWho
TIMEWhen
MOTIVATIONWhy
DATAWhat
FUNCTIONHow
NETWORKWhere
PEOPLEWho
TIMEWhen
MOTIVATIONWhy
SCOPE(CONTEXTUAL)
Planner
ENTERPRISEMODEL(CONCEPTU AL)
Owner
SYSTEM MODEL(LOGICAL)
Designer
TECHNOLOGYMODEL(PHYSICAL)
Builder
DETAILEDREPRESENTATIONS(OUT-OF-CONTEXT)
Sub-Contractor
FUNCTIONINGENTERPRISE
SCOPE(CONTEXTUAL)
Planner
ENTERPRISEMODEL
(CONCEPTU AL)
Owner
SYSTEM MODEL(LOGICAL)
Designer
TECHNOLOGYMODEL
(PHYSICAL)
Builder
DETAILEDREPRESENTATIONS(OUT-OF-CONTEXT)
Sub-Contractor
FUNCTIONINGENTERPRISE
Things Important to the Business
Entity = Class of Business Thing
Processes Performed
Function = Class of Business Process
Semantic Model
Ent = Business Entity Rel = Business Relationship
Business Process Model
Proc = Business Process I/O = Business Resources
Business LogisticsSystem
Node = Business Location Link = Business Linkage
Work Flow Model
People = Organization Unit Work = Work Product
Master Schedule
Time = Business Event Cycle = Business Cycle
Business Plan
End = Business Objectiv e Means = Business Strategy
ImportantOrganizations
People = Major Organizations
Business locations
Node = Major Business Locations
Ev ents Significantto the Business
Time = MajorBusiness Event
Business Goalsand Strategy
Ends/Means =Major Business Goals
Logical DataModel
Ent = Data Entity Rel = Data Relationship
Application Architecture
Proc = Application Function I/O = User Views
Distributed SystemArchitecture
Node = IS Function Link = Line Characteristics
Human InterfaceArchitecture
People = Role Work = Deliv erable
ProcessingStructure
Time = System Event Cycle = Processing Cycle
Business RuleModel
End = Structural Assertion Means = Action Assertion
Physical DataModel
Ent = Segment/Table Rel = Pointer/Key
SystemDesign
Proc = Computer Function I/O = Data Elements/Sets
TechnologyArchitecture
Node = Hardware/Softw are Link = Line Specifications
PresentationArchitecture
People = User Work = Screen Format
ControlStructure
Time = Ex ecute Cycle = Component Cycle
RuleDesign
End = Condition Means = Action
DataDefinition
Ent = Field Rel = Address
Program
Proc = Language Statement I/O = Control Block
Netw orkArchitecture
Node = Addresses Link = Protocols
SecurityArchitecture
People = IdentityWork = Job
Timing Definition
Time = InterruptCycle = Machine Cycle
RuleDesign
End = Sub-Condition Means = Step
Data
Ent = Rel =
Function
Proc =I/O =
Netw ork
Node = Link =
Organization
People = Work =
Schedule
Time = Cycle =
Strategy
End = Means =
Zach
man
Fra
mew
ork
ICT 20
Enterprise Unified Process (EUP)
ICT 21
Interoperability
ICT 22
Interoperability research
Project type: Network of Excellence (NoE)
Full title: Interoperability Research for Networked Enterprises Applications and Software
Project duration: 3 years Project budget: 12.0 M€ EU IST funding: 6.5 M€ Partners/contractors: 50 Start date: Nov 1, 2003
Web page: www.interop-noe.org
Project type: Integrated Project (IP) Full title: Advanced Technologies for
Interoperability of Heterogeneous Enterprise Networks and their Applications
Project duration: 3 years Project budget: 26.5 M€ EU IST funding: 14.4 M€ Partners/contractors: 19 Start date: Febr. 1, 2004
Web page: www.athena-ip.org
ICT 23
System implementation budgetApplication integration license revenue
B$
(Source: the Yankee Group 2001)
Integration40%
Imp. Services
20%
Software10%
Hardware10%
Misc.20%
Interoperability is the key to increase competitiveness of enterprises. “Enterprise systems and applications need to be interoperable to achieve
seamless operational and business interaction, and create networked organizations” – European Group for Research on Interoperability, 2002
The cost of non-interoperability are estimated to
40% of enterprises IT budget.
Rationale for interoperability
ICT 24
Knowledge integration The originality of the projects are to take a multidisciplinary approach by
merging three research areas supporting the development of Interoperability of Enterprise Applications and Software: Architecture & Platforms: to provide implementation frameworks, Enterprise Modelling: to define Interoperability requirements and to support solution
implementation, Ontology: to identify Interoperability semantics in the enterprise.
Architectures&
Platforms
EnterpriseModelling
Ontology
ATHENA&
INTEROP
ICT 25
4-layered view of an enterpriseBusiness Operational Architecture
Enterprise Knowledge Architecture (EKA)
Information and Communication Technology (ICT) Architecture
Sem
antic
s
Software platforms
EKA servicesBusiness and user services
Modelingtools
Infrastructure services
Management tools
NomenclaturesClassifications
Ontologytools
Ontologyservices
Dictionaries Ontologies
Business termsLaws, rules, principles
Agreed norms and practices
Operations Strategy
Procedures and routines
Governance
Enterprise models
Metamodels and languages
Enterprise templates
Enterprise methodology
Reference architectures
Product models
ICT 26
Holistic approach to interoperability
To achieve meaningful interoperability between enterprises, interoperability must be achieved on all layers: Business layer: business environment and business processes Knowledge layer: organisational roles, skills and competencies of employees and knowledge
assets ICT layer: applications, data and communication components Semantics: support mutual understanding on all layers
Application
Data
Business
Knowledge
Application S
eman
tics
Business
Knowledge
Sem
antics
Enterprise A Enterprise B
Data
Communication
ICT
Interoperability (def.) is “the ability of two or more systems or components to exchange information and to use the information that has been exchanged” – IEEE Standard Computer Dictionary
ICT 27
Enterprise architecture and SOA
ICT 28
Motivation for SOA
Enterprise Challenges
Business agility Flexibility and adaptability
Enterprise architecture frameworks+ Holistic approach+ Different views of an enterprise as
related (visual) knowledge models- Current enterprise architectures are
only blueprints
ICT Challenges
Inflexible and difficult to adapt Enterprise application integration
(EAI) Service-oriented architecture (SOA)
+ Architectural style+ Loosely coupled systems+ Horizontal integration between
different business domains+ Use case oriented service
composition+/- Web services (enabling technology)
Requirements Enterprises require operational
enterprise architectures ICT solutions must be designed to be
inherently interoperable
ICT 29
Business and technology alignment
Business Services can be seen as business
capabilities that support the enterprise.
Services usually represent a business function or domain.
Services provide the ‘units of business’ that represent value propositions within a value chain or within business processes.
Traceability between the service as a business capability and its technical implementation.
Services will improve delivery methods that are an integral part of the business product.
Technology Modular design Compositions and granularity Services are loosely coupled From compile-time and
deployment-time dependencies to run-time dependencies
Dynamic discovery and binding Services are standardized
(“platform independent”) Standard Internet and Web
protocols as the common “glue” to provide “syntactical interoperability”
ICT 30
Problems with current EA frameworks
User's problems A lot of enterprise architecture proposals on the "market" However, it is usually difficult to understand, compare and choose
Researcher's problems There is no justification, nor evaluation of existing enterprise architectures No adequate architecture representation language, too many different views and
levels of detail Confusing notions between Enterprise Architecture, Enterprise Model, Enterprise
Infrastructure Lack of standardized terminology and collaboration between different EA
communities (system engineers, software engineering,…) Engineer's problems
There is no "architecture continuity", it is difficult to transform an architecture from conceptual to implementation levels, and vice versa
There is no "architecture interoperability", enterprise applications built on different architectures are not interoperable
There is no scientific "architecture principles" like we have in the construction or shipbuilding domains, enterprise architecting is still a matter of experience
ICT 31
ATHENA's approach to operational EA
EA is the holistic expression of the enterprise’s key business knowledge, information, application and technology strategies and their impact on business functions and processes, that: Guides investment strategies and decisions Provides the framework needed to innovate the business Consists of the current targeted Enterprise Knowledge Models (EKMs):
EBA: Enterprise Business Architecture EKA: Enterprise Knowledge Architecture EIA: Enterprise information Architecture EAA: Enterprise Application Architecture ETA: Enterprise Technology Architecture
Oversees integration across the core architectures that provides a synchronized set of EA artefacts that needs to be created, collected, organized and communicated to enable adaptation to change business and technology
Is defined and deployed through the company-wide process councils
ICT 32
Enterprise architecture viewpoints
EnterpriseBusinessArchitecture
(EBA)
EnterpriseKnowledgeArchitecture
(EKA)
EnterpriseApplication & Architecture
(EAA)
EnterpriseTechnicalArchitecture
(ETA)
(EA)
Business Processes• Information Flows (between
processes)• People, Teams, RAA• Business Policy & Strategy
Business Information• Information Policy & Strategy
Applications• Application Data• Data Flows (between Apps)• Application Policy & Strategy
IT Platform and Infrastructure• Hardware & OS• SW Services & Middleware• Productivity Apps.• Technical Policy & Strategy
Integrates AcrossEBA,EKA,EIA, EAA
ICT 33
From EM to Enterprise Visual Scenes (EVS)
Utilizing the powers of visual enterprise knowledge scenes
Redefining Enterprise Knowledge Modelling
EM is externalizing and sharing enterprise knowledge, developing the enterprise knowledge architecture and enabling EVS.
EKM is extending EM by Intelligent Infrastructure and knowledge architectures to support continuous enterprise architecting, business management and more.
Four types of views: meta.-data, content, functional and context.
Different kinds of views to support process roles.
Views can also be turned into and be models
Views have their specific
view styles, and dependencies.
Many kinds of diagrams
ICT 34
Visu
al e
nter
pris
ear
chite
ctur
e m
anag
emen
t
ICT 35
Enterprise architecture layers –Integrated by intelligent infrastructuresInter-related reflective views of key roles – replacing frameworks as mosaics of static kinds and types of views (the knowledge legacy from paper carriers)
Business layer:Methods, models, operations, strategy, governance, …
Enterprise Knowledge Architecture (EKA) layer:POPS methods, EIS templates, UEML +++
ICT architecture layer: Services as reusable tasks, servers and EKM repositories
Law, rules, principles, agreed practices and norms, day to day routines
User views (types and kinds), Enterprise-models and sub-models, Meta-models: Languages, Structures and Type-hierarchies
Access services, capabilities to integrate legacy systems, extract data, handle parameterised sub-models
EKA-POPS
Layers, aspects: Logic and content:
ICT 36
POP* dimensions
The Process Dimension includes constructsrelated to activities, tasks and processes goingon in the enterprise or between enterprises.
The Organisation Dimension focuses onorganisational structures, as well as membersand positions thereof. Also, focus is set oninteraction between structures, both as a wholeand between members.
The Product Dimension is used to modelproduct architectures or product structures, forthe purpose of design, development andengineering or product data management.
The Decision Dimension is concerned withthe collection of concepts and constructs thatallow describing the decision-making structurein terms of decision centres and decisionactivities.
The purpose of the Infrastructure Dimensionis to support modelling of infrastructures andthe services they provide.
ICT 37
Mutually reflective views
An object in one view will have reflections in other dimensions No orthogonal, layered
meta-hierarchy No difference between
modelling and metamodelling
View connections and dependencies are designed or automatically created
Types and kinds of views for each design role
A content view for role A may be a definition view or functional view for role B
Product
Complex relationships,
tasks, decisions
Process
ICT 38
Enterprise KnowledgeSpaces (EKSs) areexternalised knowledgespaces of four or moreknowledge dimensions thatcontain mutual and complexdependencies of domains andelements in the fourdimensions.
Enterprise knowledge spaces
ICT 39
Modelling Platform for Collaborative Enterprises (MPCE)
Modelling tools
POP* enterprise model repository
.
Integration Services
Administration Services
Modelling support services
Repository management services
Modelling tools
POP* enterprise model repository
.
Integration Services
Modelling support services
Repository management services
Administration services
Enterprises’ ICT infrastructures
Model-generated workplaceswith business and user services
The ICT infrastructure is a platform of software component services.
Model-designed and generated working
environments supporting concurrent design,
planning and execution.
The integrator of all systems and provider of new solutions
ICT 40
MPCE Storage- with models asEKA structures-files-internal MPCEdata as models
Model-designed and generated Workplaces
Modules with Web UI- Page editor & runtime- Dynamic forms ed. & runtime- Problem tracker- Document uploader- Simple EKA text browser
MenusNavigation
Roles, users, pages, permissions, projects
FileRepository
(Blobs)
MPCE Server (non-UI) modules-Permissions, users, groups, roles-Projects, portals, menus, navigation-File storage and retrieval-Model transformation services-EKA load, save, merge, etc
Modelling clients
Reference models as EKA structures POP* metamodel
MPCE Web Services-update users, projects, roles,-update dynamic forms etc-load, save EKA etc
EKA Objectrepository
Web Service Enactment-call other systems-return results for viewing
New Models
Clie
ntSe
rver
Stor
age
ICT 41
Integration, SOA and Web services
ICT 42
The waves of client/server technology
Base Source: Client/Server Survival Guide, 1994Robert Orfali, Dan HarkeyOS/2 Edition, VNR Computer library + AJB update 2004
1982 1986 1990 1994 1998 1999 2000 2001 2002 2003
FileServers
DistributedObjects
FirstWave
SecondWave
ThirdWave
OMG CORBACOM/OLEWeb/InternettJava
J2EE/EJBCOM+Corba Comp
Server-sidecomponentsc
MDA, WebServices, .NetService-orientedArchitectureSOAP, XML
WSDL/WSFL
FourthWave
FifthWave
P2PGrid
Agents,FIPA
ICT 43
Web service
Web service “Applications identified by a URI, whose interfaces and bindings
are capable of being defined, described and discovered as XML artefacts. A Web service supports direct interactions with other software agents using XML-based messages exchanged via Internet-based protocols.” (W3C)
http://www.w3.org/
SOA ~ architectural style Web services stack ~ technology/protocol standards SOA =/= Web services
ICT 44
Web services architecture
Web services can be used to implement service-oriented solutions
They adhere to the set of roles and operations specified by the service oriented model.
They have also managed to establish a standardized protocol stack.
ICT 45
WS-* stack to-be
Simplified version of the to-be WS-* stack Families of related specs not expanded Competing spec families not shown “Historical” or abandoned specs not shown
XML
SOAP WSDL
BPEL
WS-CDLWS-Security
WS-Addressing
WS-ReliableMessagingWS-Coordination
WS-Policy
WS-MetadataExchange
WS-Notification
WS-ResourceWS-Transfer
UDDI
WS-Federation
ICT 46
WS-* stack as-is
Complete version of the as-is WS-* stack The 3 widely-accepted specs today are the same as 5 years ago BPEL and WS-Security is gaining momentum Orchestration, discovery and brokering do not exist in today’s world
XML
SOAP WSDL
BPEL
WS-CDLWS-Security
WS-Addressing
WS-ReliableMessagingWS-Coordination
WS-Policy
WS-MetadataExchange
WS-Notification
WS-ResourceWS-Transfer
UDDI
WS-Federation
ICT 47
Service-oriented architecture (SOA)Application architecture
Segmented business areas Collaborative business areas
SOA
y1
r
a
y1
r
a
y2
s
b
y2
s
bc
t
z
c
t
z
x x
a b cr
st x
yz
a b t zyr s y
z
c
Application architecture vs. SOA
ICT 48
SOA and integration
Fundamental change for integration: X <-> Y Pre-SOA: outside, after development Post-SOA: inside, integral part of development / computational model
Consequences How should integration be done? Innovation and experience Competition, expansion, consolidation
Not understood: IDC Directions 2006 (3/2/06): SOA important but not understood or
deployed as claimed Gartner (2/15/06): “Globally, organizations placing minor emphasis on
understanding the role of data integration in SOA and creation of data services at the foundation of their architectures”
ICT 49
History of integration
1950 – 2006: Integration = develop then integrate 1950s-1970s: Simple, manual integration 1970s-1980s: Distributed Computing
Applications (interoperation) Databases (integrate)
1990s: Business Driven Integration – concepts, technologies, and tools – increased automation, internet-based computing Concepts: Workflows, Processes, Web, Integration solutions blossom (diverge): ETL, EAI, BPM, …
2000: SOA Emerges 2000: Web services 2003: Integration solution evolution accelerates, vendor chaos ensues 2005: Growth in all integration categories
ICT 50
Integration in SOA
2006 – 2012: Integration = dominant programming model 2001-2010: Wrapping 2005-2010: Re-Engineering 2006-2008: Consolidation 2006-2008: Research on Semantic SOA 2007-2012: Emergence of SOA Platforms and Solutions 2006-2012: Problem Solving Era: IT/integration relegated to low
level function
ICT 51
ICT 52
SOA platform consolidation
Data and information integration ➪ Information Fabric EII: Enterprise information integration ETL: Extract, transform and load
Application integration ➪ Integration Suite EAI: Enterprise application integration B2Bg: Business-to-business gateway ESB: Enterprise service bus
Applications and Processes ➪ Business Process Management Suite BPM: Business process management B2Bi: Business-to-business integration
Enterprise workplace ➪ Interaction Platform
ICT 53
ICT 54
Goal: Composite applications Components: EAI, BPM, B2B, B2Bi Extensions: Adapter, collaboration, analysis, reporting, development,
monitoring, contracts, SOA standards, …
Integration suite services
ICT 55
Business process management suite& interaction services
Goal: Continuous process improvement Components: BPM
human-centric: people-intensive processes Integration-centric: system-intensive processes
ICT 56
Information fabric services
Goal: Holistic view of data (information virtualisation) Components: DBMS, EII + ETL + replication Extensions: Distributed meta-data repository, distributed data access,
integrated data management
ICT 57
Trends
Consolidation ➪ comprehensive platforms Merging of Human Workflow and System
Orchestration/Process services Integration of Business Rules Engines Support for Event Notification services (publish and
subscribe) Integration of Model-generated workplaces and role/task-
oriented user interfaces, user interaction services, portals, and multi-device interfaces
Explicit use of models (Enterprise and System) Enterprise architecture + SOA
ICT 58
References
ICT 59
References[ATHENA] ATHENA, "ATHENA Home Page", ATHENA IP. http://www.athena-ip.org/[DnD] DnD, "Faggruppen for applikasjonsintegrasjon – metoder og arkitektur", Den norske dataforening
(DnD). http://www.dnd.no/[Elvesæter, et al. 2005] B. Elvesæter, R. K. Rolfsen, F. Lillehagen, and D. Karlsen, "Integrated
Enterprise Service Architecture", in Proc. of the 12th ISPE International Conference on Concurrent Engineering (CE 2005), Fort Worth, Texas, USA, 2005, M. Sobolewski and P. Ghodous (Eds.), International Society for Productivity Enhancement, Inc., NY, USA, pp. 129-134.
[INTEROP] INTEROP, "INTEROP Home Page", INTEROP NoE. http://www.interop-noe.org/[Lillehagen, et al. 2005] F. Lillehagen, D. Karlsen, H. G. Solheim, H. D. Jørgensen, H. Smith-Meyer, B.
Elvesæter, and R. K. Rolfsen, "Enterprise Architecture - from Blueprints to Design Services", in Proc. of the 12th ISPE International Conference on Concurrent Engineering (CE 2005), Fort Worth, Texas, USA, 2005, M. Sobolewski and P. Ghodous (Eds.), International Society for Productivity Enhancement, Inc., NY, USA, pp. 121-128.
[NESSI] NESSI, "Networked European Software & Services Iniative (NESSI)". http://www.nessi-europe.eu/Nessi/
[OASIS 2006] OASIS, "Reference Model for Service Oriented Architecture 1.0", OASIS, OASIS Standard, 12 October 2006. http://docs.oasis-open.org/soa-rm/v1.0/soa-rm.pdf
[W3C 2004] W3C, "Web Services Architecture", World Wide Web Consortium (W3C), W3C Working Group Note, 11 February 2004. http://www.w3.org/TR/ws-arch/