Transitioning Enterprise Architectures to Service Oriented Architectures
-
Upload
nathaniel-palmer -
Category
Technology
-
view
28 -
download
2
description
Transcript of Transitioning Enterprise Architectures to Service Oriented Architectures
Welcome Woody Woods
Chief Enterprise Architecture TechnologistSI International, Inc.
SessionTitle:Transitioning Enterprise
Architectures to Service Oriented Architectures
2 April 21-23, 2008
Renaissance Washington, DC
Overview
• What is SOA?• Why SOA?• Service Definitions• Example• Wrap-up
3 April 21-23, 2008
Renaissance Washington, DC
What is SOA?
Service-Oriented Architecture (SOA) – A service-oriented architecture is a conceptual
description of a the structure of a software system in terms of its components and the services they provide, without regard for the underlying implementation of these components, services and connections between components. [Rational Unified Process]
4 April 21-23, 2008
Renaissance Washington, DC
Why SOA?
• Object-Oriented Analysis and Design• Business Process Reengineering• Functional Requirements Capture• Loosely Coupled
– Ease of Change
• Effects Oriented• Interfaces with other Enterprises• Integrated Schema, Definition and Data• Rigorous Analysis
5 April 21-23, 2008
Renaissance Washington, DC
Service Definitions
• NCOW-RM • OASIS Reference Model for SOA v 1.0
6 April 21-23, 2008
Renaissance Washington, DC
Service (NCOW – RM)Service (NCOW – RM)
• A service, in the context of the Reference Model, is:• A self-contained, stateless function with a well-defined interface that allows
discovery and use of the service• A functionality (function or combination of functions) that supports the
production, sharing, and consumption (use) of data, information, or other services
• A functionality that accepts one or more requests and returns one or more responses, independent of the state of other functions or processes
• An exposed functionality with three properties:– The interface contract to the service is platform independent. This means a client
from any device using any operating system in any language can use the service, and that knowledge of the technical details of another service is not required to interact to it.
– The service can be dynamically located and invoked. All applications can appear on the network as a set of services where it is possible to plug all these services into a single information bus. It is irrelevant whether the services are local (within the system) or remote (external to the immediate system), what interconnect scheme or protocol is used, or what infrastructure components are required to make the connection.
– The service is self-contained; it maintains its own state. Services operate as “black boxes” and external components neither know nor care how they perform their function, just that they return the expected result.
7 April 21-23, 2008
Renaissance Washington, DC
Service – OASIS Reference Model for Service – OASIS Reference Model for SOA v 1.0SOA v 1.0
• A service is a mechanism to enable access to one or more capabilities, where the access is provided using a prescribed interface and is exercised consistent with constraints and policies as specified by the service description. A service is provided by an entity – the service provider – for use by others, but the eventual consumers of the service may not be known to the service provider and may demonstrate uses of the service beyond the scope originally conceived by the provider.
• A service is accessed by means of a service interface where the interface comprises the specifics of how to access the underlying capabilities. There are no constraints on what constitutes the underlying capability or how access is implemented by the service provider. Thus, the service could carry out its described functionality through one or more automated and/or manual processes that themselves could invoke other available services.
• A service is opaque in that its implementation is typically hidden from the service consumer except for
– (1) the information and behavior models exposed through the service interface and– (2) the information required by service consumers to determine whether a given
service is appropriate for their needs.
8 April 21-23, 2008
Renaissance Washington, DC
Defining Operational Activities
Establish Vision and Mission
<<use case>>
Determine Enterprise Boundaries
<<use case>>
Identify Enterprise Use Cases
<<use case>>
Detail Enterprise Use Cases
<<use case>>
Develop Logical Data Model
<<use case>>
E_M1
E_D1[ use cases not complete ]
[ use cases complete ]
E_D2 [ enterprise model not complete ]
[ enterprise model
complete ]
[t0] : VisionMission
[established]
[t0] : ContextDiagram
[established]
[t0] : UseCase
[identi fied]
[t0] : ActivityDiagram
[developed]
[t0] : SequenceDiagram
[developed]
[t0] : ClassDiagram
[developed]
[t0] : EnterpriseModel
[complete]
Establishes the overall objectives of the architecture, its purpose, boundaries, goals, and mission.
Documents the consumption and production of the enterprise, the associated roles and interfaces
Establishes the scope of the activity and the responsible roles to produce the result of value.
Establishes the flow of control as defined by the business rules and provides context for the business services offered by the enterprise.
Documents service responsibility among the roles in the environment as defined by the activity diagrams.
Documents the information requirements in the form of classes, their attributes, operations and relationships with other classes.
9 April 21-23, 2008
Renaissance Washington, DC
Scenario
1. An individual on a surveillance team has noticed a drug deal in progress and notifies police headquarters.
2. Police headquarters notifies the FBI and requests ancillary information.
3. The result is a pinpointed location of a specific drug deal
10 April 21-23, 2008
Renaissance Washington, DC
Process
• Identify Roles• Identify Objects• Identify Boundary Crossings• Identify Potential Services• Identify Interfaces
11 April 21-23, 2008
Renaissance Washington, DC
Identify Roles
Police_Headquarters
FBI
DEA Data Source
Individual
12 April 21-23, 2008
Renaissance Washington, DC
Identify Objects (1 of 2)Identify Objects (1 of 2)
[t6] : DrugDeal
[veri fied]
[t7] : DrugDeal
[veri fied]
[t8] : DrugDeal
[veri fied]
[t0] : DrugDeal
[sighted]
: DEA Data Source : FBI : Police_Headquarters : Indiv idual
[t0] : DrugDeal
[sighted]
[t6] : DrugDeal
[verified]
Trigger
Result of Value
Individual Police_Headquarters FBI DEA Data Source
13 April 21-23, 2008
Renaissance Washington, DC
Identify Objects (2 of 2)Identify Objects (2 of 2)
[t0] : DrugDeal
[sighted]
[t1] : DrugDeal
[reported][t2] : DrugDeal
[consolidated]
[t3] : DrugDeal
[reported]
[t2] DEA : Information
[consolidated]
[t6] : DrugDeal
[veri fied]
[t7] : DrugDeal
[veri fied]
[t8] : DrugDeal
[veri fied]
[t4] : DrugDeal
[no additional data needed]
[t5] : DrugDeal
[additional data needed]
: DEA Data Source : FBI : Police_Headquarters : Indiv idual
[t2] DEA : Information
[consolidated]
[t1] : DrugDeal
[reported]
[t2] DEA : Information
[consolidated]
Individual Police_Headquarters FBI DEA Data Source
14 April 21-23, 2008
Renaissance Washington, DC
Identify Initial ActionsIdentify Initial Actions
[t0] : DrugDeal
[sighted]
<<trigger>>
Report Location of Drug Deal
[t1] : DrugDeal
[reported]
Consolidate Individual Drug Deal Position Reports
[t2] : DrugDeal
[consolidated]
Report Consolidated Drug Deal Positional Data
[t3] : DrugDeal
[reported]
[t4] : DrugDeal
[no additional data needed]
Report Verified Drug Deal Positional Data
[t6] : DrugDeal
[veri fied]
[t7] : DrugDeal
[veri fied]
[t8] : DrugDeal
[veri fied]
: DEA Data Source : FBI : Police_Headquarters : Indiv idual
Report Location of Drug Deal
Consolidate Individual Drug Deal Position Reports
Report Consolidated Drug Deal Positional Data
Report Verified Drug Deal Positional Data
Individual Police_Headquarters FBI DEA Data Source
15 April 21-23, 2008
Renaissance Washington, DC
Complete Action AnalysisComplete Action Analysis
Report Location of Drug Deal
Consolidate Individual Drug Deal Position Reports
Report Consolidated Drug Deal Positional Data
Request DEA Information Related to the Drug Deal
Compare DEA Information to Drug Deal Position Data
Determine if Additional Drug Deal Related Data are Needed
_D1
[ additional data needed ]
_M1
[ no additional data needed ]
Report Verified Drug Deal Positional Data
[t0] : DrugDeal
[sighted]
<<trigger>>
[t8] : DrugDeal
[veri fied]
[t1] : DrugDeal
[reported]
[t2] : DrugDeal
[consolidated]
[t7] : DrugDeal
[veri fied]
[t3] : DrugDeal
[reported]
[t2] DEA : Information
[consolidated]
[t4] : DrugDeal
[no additional data needed]
[t6] : DrugDeal
[veri fied]
[t5] : DrugDeal
[additional data needed]
[t0] DEA : Information
<<external>>
[requested]
[t1] DEA : Information
<<external>>
[provided]
: DEA Data Source : FBI : Police_Headquarters : Indiv idual
Determine if Additional Drug Deal Related Data are Needed
Request DEA Information Related to the Drug Deal
Compare DEA Information to Drug Deal Position Data
Individual Police_Headquarters FBI DEA Data Source
16 April 21-23, 2008
Renaissance Washington, DC
Sequence Diagram
: Individual : Individual : Police_Headquarters
: Police_Headquarters
: FBI : FBI : DEA Data Source
: DEA Data Source
1: report( : DrugDeal)
2: consolidate( : DrugDeal)
3: report(consolidated : DrugDeal)
4: determine(Info Requirement : DrugDeal)
5: request(Drug Deal : Information)
6: provide(DEA : Information)
7: compare(DEA/DrugDeal : Information)
8: report(veri fied : DrugDeal)
9: report(veri fied : DrugDeal)
Additional Information Required
17 April 21-23, 2008
Renaissance Washington, DC
Identify Boundaries
• Each role is represented as a swim lane on the activity diagram
• The boundaries are the lines defining each swim lane
• The term “crossing” a swim lane boundary indicates traversal from the producing swim lane to the consuming swim lane and does not include any that are in between
18 April 21-23, 2008
Renaissance Washington, DC
Identify Boundary CrossingsIdentify Boundary Crossings
Report Location of Drug Deal
Consolidate Individual Drug Deal Position Reports
Report Consolidated Drug Deal Positional Data
Request DEA Information Related to the Drug Deal
Compare DEA Information to Drug Deal Position Data
Determine if Additional Drug Deal Related Data are Needed
_D1
[ additional data needed ]
_M1
[ no additional data needed ]
Report Verified Drug Deal Positional Data
[t0] : DrugDeal
[sighted]
<<trigger>>
[t8] : DrugDeal
[veri fied]
[t1] : DrugDeal
[reported]
[t2] : DrugDeal
[consolidated]
[t7] : DrugDeal
[veri fied]
[t3] : DrugDeal
[reported]
[t2] DEA : Information
[consolidated]
[t4] : DrugDeal
[no additional data needed]
[t6] : DrugDeal
[veri fied]
[t5] : DrugDeal
[additional data needed]
[t0] DEA : Information
<<external>>
[requested]
[t1] DEA : Information
<<external>>
[provided]
: DEA Data Source : FBI : Police_Headquarters : Indiv idual
Individual Police_Headquarters FBI DEA Data Source
19 April 21-23, 2008
Renaissance Washington, DC
Identify Potential ServicesIdentify Potential Services
Report Location of Drug Deal
Consolidate Individual Drug Deal Position Reports
Report Consolidated Drug Deal Positional Data
Request DEA Information Related to the Drug Deal
Compare DEA Information to Drug Deal Position Data
Determine if Additional Drug Deal Related Data are Needed
_D1
[ additional data needed ]
_M1
[ no additional data needed ]
Report Verified Drug Deal Positional Data
[t0] : DrugDeal
[sighted]
<<trigger>>
[t8] : DrugDeal
[veri fied]
[t1] : DrugDeal
[reported][t2] : DrugDeal
[consolidated]
[t7] : DrugDeal
[veri fied]
[t3] : DrugDeal
[reported]
[t2] DEA : Information
[consolidated]
[t4] : DrugDeal
[no additional data needed]
[t6] : DrugDeal
[veri fied]
[t5] : DrugDeal
[additional data needed]
[t0] DEA : Information
<<external>>
[requested]
[t1] DEA : Information
<<external>>
[provided]
Push Tracking Data AD
Pull Tracking Data AD
Push Posi tional Data AD
Pull Positional Data AD
Post DEA Information Request AD
Post DEA Information AD
Push Posi tional Data AD
Pull Positional Data AD
Pull Positional Data AD
: DEA Data Source : FBI : Police_Headquarters : Indiv idual
Individual Police_Headquarters FBI DEA Data Source
20 April 21-23, 2008
Renaissance Washington, DC
Post DEA Information Request Post DEA Information Request ServiceService
Post DEA Information Request for the Reported Drug Deal Position
Determine Drug Deal Positi...
Store DEA Information Request in the Repository
Evaluate Request Priority
_D1
Push Data to End User
[ immediate push required ]
Store Message on Queue
[ store on queue ]
[t5] : DrugDeal
<<trigger>>
[t0] : MessageNotification
[t00] DEA : Information
[t1] DEA Request : Information
_M1
[t0] DEA : Information
<<external>>
: DEA Data Source : NetCentricSystems : FBI
21 April 21-23, 2008
Renaissance Washington, DC
Compare Drug Deal with the Profile
PDE_D1[ profile <> sensi tivi ty ]
Parse Drug Deal Information based on Profile
[ profile = sensitivi ty ]
Assemble DEA Information Post
Post DEA Information Date to Netcentric System
[t0] : Profi le
[stored]
[t0] : DrugDeal
<<external>>
[updated]
[t1] : DrugDeal
[compared]
[t01] Location : DrugDeal
[parsed]
[t02] Confidence : DrugDeal
[parsed]
[t03] Type : DrugDeal
[parsed]
[t04] Source : DrugDeal
[parsed]
[t05] DEA : Information
[assembled]
[t1] DEA : Information
[posted]
: NetCentricSystems : DEA Data Source
Identify System InterfacesIdentify System Interfaces
22 April 21-23, 2008
Renaissance Washington, DC
Post DEA Information InterfacesPost DEA Information Interfaces
IAcceptDrugDealSource
acceptDrugDealSource(source : DrugDeal) : String
IAcceptDrugDealConfidence
acceptDrugDealConfidence(confidence : DrugDeal) : Integer
IAcceptDrugDealLocation
acceptDrugDealLocation(location : DrugDeal) : Array
IAcceptDrugDealType
acceptDrugDealType(type : DrugDeal) : Integer
NetCentricSystems<<system>>
DrugDeal
date : Datetime : Datetype : Stringconfidence : Integersource : Stringdescription : Singlelocation : array
23 April 21-23, 2008
Renaissance Washington, DC
Summary
• This method provides a road map to transition from Enterprise Architecture to Service Oriented Architecture– Identifies Business Services in the context of
Business Processes and Rules– Identifies Relationships between and among
Business Actors (Roles)– Develops IT Services from those relationships– Realizes those Services with Interfaces that are
platform independent
24 April 21-23, 2008
Renaissance Washington, DC
Thank You!Woody WoodsChief Enterprise Architecture TechnologistSI International, Inc.
Contact Information:(719) [email protected]