Download - SOA Analysis v1 0
-
Copyright 2006 by IconATGTM All Rights ReservedVersion 1.0
IconATG
Service-Oriented Architecture:Analysis,
the Keys to Success!
Presented by:William F. NazzaroCTO, IconATG Inc.
-
Page 2
IconATG
Copyright 2006 by IconATGTM All Rights ReservedVersion 1.0
Introduction
Service-Oriented Architecture is hot, but we seem to be asking less technical questions once we embark. Such as, What makes a good service? How do I determine if my service should be a high-level business process Should it be a low-level technical function? Are there any techniques that can help me identify the services I should expose?
Service-Oriented Architecture is predicated on web services and web services provide defined functionality to be exposed for consumption.
A common mistake is designing web services that provide too narrow functionality. But business process modeling, business use cases and system use cases were developed precisely to capture a meaningful business service available to a requestor just like a web service.
This presentation will demonstrate how to leverage business process modeling and use case techniques to describe meaningful business process and how use case modeling concepts may be used to define and refine valuable business web services rather than the obvious low-level methods.
-
Page 3
IconATG
Copyright 2006 by IconATGTM All Rights ReservedVersion 1.0
What Well Cover
SOA, Hype or Reality? Is This Really New? Types of SOA Adoption Why This Is A Challenge
SOA Vocabulary Elements of SOA
Breaking Down Barriers BPM, EA and OOAD Positioning
SO A&D Business Strategy and Process
Business Vision View Business Process View
Building Blocks (i.e., Services)
Service Identification SOA Analysis Techniques
Business Process Modeling Use Case Modeling Service Responsibility Card (SRC)
-
Page 4
IconATG
Copyright 2006 by IconATGTM All Rights ReservedVersion 1.0
SOA, Hype or Reality?
It offers organizations the ability to act or respond quickly / efficiently to changing business requirements thereby enabling Business Agility, the flexibility acquired from
the plug-n-play nature of services
Competitive Advantage the modularity and pay-per-use natures of services
Its considered and piloted because it supports Distributed Heterogeneous Environment
Loosely coupled business applications Interoperability of distributed and disparate
systems
Plug-n-Play Integration Ease of extensibility and scalability via modularity Flexibility to focus on end-user needs
Dynamic Information Exchange/ Management Via asynchronous messaging / communication
Use of Industry Standard Technologies XML, J2EE, .NET Existing middleware technologies are reusable
Service Oriented Architecture offers you a business reason to perform and support ongoing enterprise-wide Web integration effectively
For enterprise-level integration teams, SOA is A positive step forward from traditional
middleware (CORBA) or RPC-based application integration
A widely accepted and supported concept across the Industry
Embraced equally by Microsoft and non-Microsoft school of thoughts
Provides a contract between developers and user community to integrate applications efficiently improving ROI and cost of ownership
A few XML-based standards driven notion example - SOAP, UDDI, and WSDL
Is This Really New?
-
Page 5
IconATG
Copyright 2006 by IconATGTM All Rights ReservedVersion 1.0
Is This Really New?
2000s beyond1970s 1980s 1980s 1990s 1990s 2000s
Mainframe(monolithic)
Goal: BusinessAutomation
Client / Server(objects)
Goal: IntensiveComputing
Multi-tier / WebEnablement
(components)
Goal: e-BusinessOr E-Commerce Service
Orientation(services)
Goal: BusinessFlexibility / Reuse
I view SOA as an Evolution and not a Revolution, that has evolved From client server to brokers Lessons learned during this period
-
Page 6
IconATG
Copyright 2006 by IconATGTM All Rights ReservedVersion 1.0
Types Of SOA Adoption
SOA adoption will initially be driven by one or more desired capabilities: Application development (new software projects) Legacy enablement / enterprise integration (EAI replacement) Client integration (packaged software vendors) Collaboration (DOD and Federal Government) Service Delivery (top down business adoption)
Initial goals, benefits and concerns are different, depending on the drivers: Application development
Delivered application functionality on time and on budget Legacy enablement / enterprise integration
Concentrates on integrating disparate or duplicate systems and extending the life of existing legacy applications
Client integration Driven by clients requirements for functionality or data at the edge of the application.
Collaboration Long term initiative with primary concerns in semantics and governance
Service Delivery (IT as a service)
A fully mature Service Oriented Enterprise will contain all of these capabilities
-
Page 7
IconATG
Copyright 2006 by IconATGTM All Rights ReservedVersion 1.0
Why This Is A Challenge
A typical enterprise might include IT elements such as: ERP, SCM, or CRM packages Legacy mainframe Cobol Systems / Legacy Database Systems Stand alone, client-server, 3-tier, n-tier, and web systems New development in Java/J2EE and Microsoft technologies Data warehouse Partner and/or client interfaces
Each of these elements presents different SOA adoption challenges You can no longer build applications within an IT silo. All service
oriented applications are Enterprise Applications. You have to decide, will the service interfaces you expose reside: Inside the business unit Inside the enterprise Outside the enterprise
-
Page 8
IconATG
Copyright 2006 by IconATGTM All Rights ReservedVersion 1.0
SOA Vocabulary 1
Service: Represents business functionality that is well defined, self contained and
may be accessed through clearly defined interfaces. A service is something that a business person should recognize and
understand.
Service Oriented Architecture: An approach that treats software resources as services and an architecture
that promotes a set of IT best practices for an organization / enterprise Software systems are architected to provide services to end-user
applications or other services through discoverable interfaces. Services may be:
Accessed by other applications/services Composed of other services Interoperable and transparent
Elements of SOA
-
Page 9
IconATG
Copyright 2006 by IconATGTM All Rights ReservedVersion 1.0
Elements of SOA
Service Provider: Provides capabilities or services to
other business applications, components or services
Publishes its capability or service with a registry (Service Broker) so other Service Consumer(s) may find / discover it
Service Consumer: Requests and uses services from
Service Provider(s) Searches and locates a capability
or service from a registry (Service Broker) and binds with the Service Provider using a contract and interface
Service Broker: Registers services from Service
Providers Helps locate services for Service
Consumers
Search / FindsService
ServiceBroker
ServiceConsumer
ServiceProvider
Publishes Service
Service Request
Service Response
-
Page 10
IconATG
Copyright 2006 by IconATGTM All Rights ReservedVersion 1.0
SOA Vocabulary 2
Enterprise Service Bus (ESB) connects all participants of an SOA via interfaces, embraces a variety of technologies and enables multiple communication modes.
Additional the Enterprise Service Bus: Offers transport to services
When a service request arrives an appropriate transport protocol is selected and supported Service is routed to appropriate service provider with necessary quality of service (QoS)
Mediates intelligent processing of service requests or responses Mediation is primarily directed towards message validation, transformation, routing, and monitoring
Acts as a gateway for services Controls access to services and hides details of services, validates user access, and audits requests
to services
service service service
Security Service Messaging Service Other Common Services
Interface
A Simplified Enterprise Service Bus
-
Page 11
IconATG
Copyright 2006 by IconATGTM All Rights ReservedVersion 1.0
SOA Vocabulary 3
Web Service: A functional element or business component (a collection; reusable) accessed
over the Internet using XML and HTTP Primary features of a Web Service:
Platform and language independence, building blocks for open distributed systems Browser independence, can be accessed using browsers, but do not require a browser
or HTML Data independence, offers a mechanism to expose business services without affecting
their data
Web Services add the following characteristics to an SOA Invocation of a service over the Web
Sending a request and receiving a response Can be synchronous or asynchronous Needs
A transport type to transfer the data (example- HTTP) A payload format to define the format of the data (example- XML)
Interoperability with other business applications or components Must be invoked by a client using the service Can be a remote method or a procedure call, middleware, database access or
adapters Discovery or locating service across a network
Looking up a service dynamically that matches clients need Must have Service information such as location and parameters to invoke the service
Standards and Standardization Committees (See Appendix)
-
Page 12
IconATG
Copyright 2006 by IconATGTM All Rights ReservedVersion 1.0
Breaking Down The Barriers
One of the problems blocking SOA adoption in companies is that when the architects and developers start talking in jargon, they lose the business executives and managers in the blur of XML, WSDL, SOAP and UDDI. *
The basic principle is, making SOA understandable, making it something that business and IT own together so that when you have a business strategy, it's linked directly to IT. It's a balance of the technical and non-technical approaches that makes SOA successful," **
BEA Approaches Organizing SOA Projects into six domains Business Focus
Business Strategy and Process" Costs and Benefits," Organization and Governance"
IT Focus Architecture," Building Blocks" (i.e. Services) Projects and Applications"
* Rich Seely, SearchWebServices.com** David Growes, BEA Systems
-
Page 13
IconATG
Copyright 2006 by IconATGTM All Rights ReservedVersion 1.0
Example: Automotive Work Order Problem Statement / Scenario
Adapted from: IBM Developerworks, Elements of Service Oriented Analysis and Design, Olaf Zimmermann, Pal Krogdahl, Clive Gee
-
Page 14
IconATG
Copyright 2006 by IconATGTM All Rights ReservedVersion 1.0
BPM, EA and OOAD Positioning
Adapted from: IBM Developerworks, Elements of Service Oriented Analysis and Design, Olaf Zimmermann, Pal Krogdahl, Clive Gee
Our Focus Shifts To
-
Page 15
IconATG
Copyright 2006 by IconATGTM All Rights ReservedVersion 1.0
SO A&D:Business Strategy and Process
Business Vision View Business Vision Document Business Vision View Techniques Example Class Diagram
Business Process View Example Business Process View Examples Business Process Model
-
Page 16
IconATG
Copyright 2006 by IconATGTM All Rights ReservedVersion 1.0
The Business Vision View
Reveals the overall vision of the business Describes a goal structure for the business Illustrates problems that must be solved in order to reach those
goals Identifies strategies to be undertaken to solve the problems Documented via a Business Vision document
Business Vision Document High-level document, not detailed Basic strategy for moving forward Summarizes business to motivate employees and stakeholders
This artifact isnt new, but its critical for successful SOA deployments? Business Vision drives a set of Business Architecture Requirements
(People, Process, Partners, Goods, Markets, Customers) and then organize into a TOWS matrix
Dont just think SOA, think: Agility Compliance Merger & Acquisition Software as a Service Etc
Business VisionDocument
-
Page 17
IconATG
Copyright 2006 by IconATGTM All Rights ReservedVersion 1.0
The Business Vision View: Techniques
Strategy Definition Position of the company with regard to current and future world Reveal the strategic goals and needed changes for the business Use a TOWS Matrix to model
(Threats, Opportunities, Weaknesses, Strengths)
Conceptual Modeling Definitions of the important concepts used in the business Identifies relationships between the concepts Use class diagrams to model concepts
Goal/Problem Modeling Definition of the goals for the company Breaks high-level abstract goals into measurable sub-goals that are
achievable by a business process Problems that obstruct goal achievement are revealed Use object diagrams to model Goal/Problem relationships
-
Page 18
IconATG
Copyright 2006 by IconATGTM All Rights ReservedVersion 1.0
Example: Automotive Work Order Class Diagram to Model Concepts
Adapted from: IBM Developerworks, Elements of Service Oriented Analysis and Design, Olaf Zimmermann, Pal Krogdahl, Clive Gee
-
Page 19
IconATG
Copyright 2006 by IconATGTM All Rights ReservedVersion 1.0
The Business Process View
The Business Process View reveals the business processes with which a business achieves its goals
All processes collectively attempt to achieve the overall goals of the business
The processes show The activities that must be undertaken to achieve an explicit goal, Along with their relationships to the resources that participate in the
process
The process definitions are used to Understand the business See threats or opportunities to the business Improve or innovate the business Act as the context for process automation systems
-
Page 20
IconATG
Copyright 2006 by IconATGTM All Rights ReservedVersion 1.0
Example: Automotive Work Order Business Process Model
Adapted from: IBM Developerworks, Elements of Service Oriented Analysis and Design, Olaf Zimmermann, Pal Krogdahl, Clive Gee
-
Page 21
IconATG
Copyright 2006 by IconATGTM All Rights ReservedVersion 1.0
Example: Automotive Work Order Initial Use Case Diagram and Use Case Steps
CreateWork Order
ServiceRep
InventorySystem
CustomerApplication
SchedulingERP
Work OrderSystem
CatalogApplication
Create Work Order
Get Customer & Vehicle Info
Create Work Order
Get Auto Service Options
List Required Parts & Supplies
Reserve Low Inventory Level Parts
Schedule Appointment
Save Work Order
Check Inventory Levels
Reserve All Parts
-
Page 22
IconATG
Copyright 2006 by IconATGTM All Rights ReservedVersion 1.0
SO A&D:Building Blocks (i.e., Services)
If we are describing a business areawe will describe the interactions which occur within that workflow.
But if our interest is in how a software system serves its users, our scope narrows considerably.
In SO A&D we actually need to consider both views, but we should work from the outside-inn Determine the business
interactions and our needs to support them
o Determine the software system interactions required to support the business interactions
Events
Organization
Events
Events
Events Events
Events
ManualManual
ManualBusiness AreaBusiness Area
Business AreaBusiness AreaBusiness AreaBusiness Area
Automated
SystemSystem
Automated
Automated
Adapted from: Evanetics & Nazzaro, Use Case Modeling Course
-
Page 23
IconATG
Copyright 2006 by IconATGTM All Rights ReservedVersion 1.0
Example: Automotive Work Order Revised Use Case Diagram and Use Case Steps
PartsSupplier
Customer
Dealership
CreateWork Order
ServiceRep
InventorySystem
CustomerApplication
SchedulingERP
Work OrderSystem
CatalogApplication
Create Work Order
Get Customer & Vehicle Info
Create Work Order
Get Auto Service Options
List Required Parts & Supplies
Reserve Low Inventory Level Parts
Schedule Appointment
Save Work Order
Check Inventory Levels
Reserve All Parts
-
Page 24
IconATG
Copyright 2006 by IconATGTM All Rights ReservedVersion 1.0
Example: Automotive Work Order Initial Service List
Customer Service The Customer Service manages contact and automobile information for each
customer
Catalog Service The Catalog Service provides maintenance offerings for any automobile, and
specifies parts, supplies and labor
Work Order Service The Work Order Service tracks the progression of a single instance of servicing a
single automobile
Inventory Service The Inventory Service provides the quantity on hand for any needed items and
facilitates the ordering of any items not on hand
Scheduling Service The Scheduling Service identifies the next available date and time that
corresponds to the required Duration, Mechanic Type and Bay Type
Guidance: think coarse grained services, not CRUD
-
Page 25
IconATG
Copyright 2006 by IconATGTM All Rights ReservedVersion 1.0
Service Responsibility Card (SRC) Services, Operation and I/O
n Determine the operations required for each service For each identified operation,
Name the operation Leverage the Service Responsibility Card (SRC)
o Determine the inputs/outputs for each operation For each named operation
Determine any input data required by the operation Determine any output data provided by the operation
Assume no collaboration with other services
-
Page 26
IconATG
Copyright 2006 by IconATGTM All Rights ReservedVersion 1.0
Example: Automotive Work Order Service Responsibility Card (SRC)
Service Name: Customer
Service Description:
Service Responsibilities:
Operation: Input Data: Output Data:
Lookup Customer By Telephone Number
Telephone Number Customer And Vehicle Info
The Customer Service manages contact and automobile information for each customer
Operation: Input Data: Output Data:
Create Customer Customer Info None
Operation: Input Data: Output Data:
Create Vehicle Vehicle Info, Telephone Number
None
-
Page 27
IconATG
Copyright 2006 by IconATGTM All Rights ReservedVersion 1.0
Example: Automotive Work Order Service Responsibility Card (SRC)
Service Name: Catalog
Service Description:
Service Responsibilities:
Operation: Input Data: Output Data:
List Maintenance Auto Make and Model Maintenance Code and Description Of Possible Offerings
The Catalog Service provides maintenance offerings for any automobile, and specifies parts, supplies and labor
Operation: Input Data: Output Data:
List Parts Supplies and Labor Maintenance Code List Of Parts, Supplies And Labor
Operation: Input Data: Output Data:
-
Page 28
IconATG
Copyright 2006 by IconATGTM All Rights ReservedVersion 1.0
Example: Automotive Work Order Service Responsibility Card (SRC)
Service Name: Work Order
Service Description:
Service Responsibilities:
Operation: Input Data: Output Data:
Create Work Order None Work Order Number
The Work Order Service tracks the progression of a single instance of servicing a single automobile
Operation: Input Data: Output Data:
Update and Save Work Order and Calculate New Cost
Complete Work Order Information
Cost
Operation: Input Data: Output Data:
Delete Work Order Work Order Number None
-
Page 29
IconATG
Copyright 2006 by IconATGTM All Rights ReservedVersion 1.0
Example: Automotive Work Order Service Responsibility Card (SRC)
Service Name: Inventory
Service Description:
Service Responsibilities:
Operation: Input Data: Output Data:
Determine Quantity on Hand of Item(s)
Item Number(s) Number On Hand, Reserved, and On Back Order for Each Item
The Inventory Service provides the quantity on hand for any needed items and facilitates the ordering of any items not on hand
Operation: Input Data: Output Data:
Reserve Item(s) Work Order Number and Parts List
Back Order and Arrival Info by Part
Operation: Input Data: Output Data:
Return Item(s) Work Order Number None
-
Page 30
IconATG
Copyright 2006 by IconATGTM All Rights ReservedVersion 1.0
Example: Automotive Work Order Service Responsibility Card (SRC)
Service Name: Scheduling
Service Description:
Service Responsibilities:
Operation: Input Data: Output Data:
Schedule Skilled Mechanic and Service Bay
Duration, Mechanic Type, and Bay Type
Start Date and Time, Mechanic Name and Bay Number
The Scheduling Service identifies the next available date and time that corresponds to the required Duration, Mechanic Type and Bay Type
Operation: Input Data: Output Data:
Operation: Input Data: Output Data:
-
Page 31
IconATG
Copyright 2006 by IconATGTM All Rights ReservedVersion 1.0
Example: Automotive Work Order Sequence Diagram: Partial Business Process Model
-
Page 32
IconATG
Copyright 2006 by IconATGTM All Rights ReservedVersion 1.0
Example: Automotive Work Order Sequence Diagram: Partial Business Process Model
-
Page 33
IconATG
Copyright 2006 by IconATGTM All Rights ReservedVersion 1.0
Next Steps
-
Copyright 2006 by IconATGTM All Rights ReservedVersion 1.0
IconATG
In this new world, it's not design the business and then design the technology, you're creating one thing, which is
your business as embodied in your technology base. *
* Randy Heffner, Forrester Research Inc.
-
Copyright 2006 by IconATGTM All Rights ReservedVersion 1.0
IconATG
Service-Oriented Architecture:Analysis,
the Keys to Success!
Presented by:William F. NazzaroCTO, IconATG Inc.
-
Copyright 2006 by IconATGTM All Rights ReservedVersion 1.0
IconATG
Appendix
Additional Material
-
Page 37
IconATG
Copyright 2006 by IconATGTM All Rights ReservedVersion 1.0
Standards and Standardization Committees
Core Standards
XML(Extensible
MarkupLanguage)
SOAP(Simple Object
Access Protocol)
WSDL(Web Services
Description Language)
UDDI(Universal Description,
Discovery, and Integration)
HTTP(HyperText Transfer Protocol)
Supports all three aspects of a Web service
Formats the message in a Web service
Describes a Web service
Registers and publishes a Web service
Carries the message of a Web service over the Internet
Other Relevant Standards BPEL WS Reliable Messaging SAML and SSML WSCI
Major Standardization Committees W3C OASIS WS-I Liberty Alliance
-
Page 38
IconATG
Copyright 2006 by IconATGTM All Rights ReservedVersion 1.0
SOA and Web Services
The Connection
ServiceProvider
Service Consumer
Service Request
Service Response
ServiceBroker
Finds ServicePublishes Service
WSDL WSDL
SOAP
UDDI
Service Interfaces
CommunicationProtocol
Discovery / lookupProtocol