Service Oriented Analysis I and Overview of SEAM, SEAMSys and iSEAMS

1
Service Oriented Analysis I and Overview of SEAM,
SEAMSys and iSEAMS

• 605.702 Service Oriented ArchitectureJohns-Hopkin
  s University
• Montgomery County Center, Spring 2008
• Session 10, Lecture 8 April 9, 2008
• Instructor T. Pole

2
Agenda

• Required Reading for This Week
• Service Oriented Architecture Concepts Technology
  Design (SOACTD)
• Chapter 12 Service Oriented Analysis Part II
  Service Modeling
• Chapter 13 Service Oriented Design Part I
  Introduction
• Todays Presentation
• Todays Lecture
• Service Oriented Analysis - complete
• Service Oriented Design begin
• Overview of Class Project Requirements
• Overview of Iteration 2 of SEAM, SEAMSys and
  iSEAMS
• Class Assignments
• Discuss Iteration 1 drafts
• Assign remaining, iteration 2 requirements for
  Class Project which is due 5-7-08
• Class Web Site
• Installing Web Services on class web site

3
Ch 12 Service Oriented Analysis Part II (Service
Modeling)
4
Ch 13 Service Oriented Design Part I
(Introduction)
5
Overview of the SOA SDLC

• Service Delivery Lifecycle Phases
• Service Oriented Analysis
• Service Oriented Design
• Service Development
• Service Testing
• Service Deployment
• Service Administration
• Project Requirements are NOT the SEAMSys
  functional requirements
• Project requirements are what you must do to
  complete the class project, one of which is a
  statement of you projects requirements.

6
Service Oriented Analysis

• Determine the scope of the SOA
• (Customer, thats me) Given requirements
• Derived (by you) requirements
• Identification of business processes that will be
  automated in the SOA
• Map out the (candidate) service layers
• Section ??
• Identify individual service operations modeled as
  candidate services
• Derived from?? (see section ??)
• Analysis process is identified in chap 11 and 12

7
Service Oriented Design

• Service Layers are finalized
• Candidate operations list is finalized
• Candidate services are finalized
• By allocating and re-analysis of services
• Business process are mapped to operation
  sequences that will automate them
• Ws- extensions and other design decisins are
  finalized
• SOA Design process is defined in chapters 13
  through 15

8
Service Development

• Actual construction of the services
• Prior to this, the operation interfaces,
  operation behaviors, integration protocols,
  service/operation sequences defined, and mapped
  to the business processes and use case scenarios
• Other development paradigms are the primary
  approach used here, notable object oriented
  software engineering

9
Service Testing

• Involves both unit testing, and system or
  integration testing
• unit testing testing individual services, or
  even individual operations out of context
• system testing testing entire operation
  sequences against the business process they
  automate

10
Service Deployment

• The deployment (installation, configuration,
  etc.) of all individual services, and their
  consumers/requestors
• integrating the services with
• their underlying functional components
• COTS products
• Legacy systems

11
Service Administration

• Operate the system
• Train users in the use of the system
• Maintain the system
• Evolve the system
• Track usage, maintenance, etc. of the system

12
Overview of Class Project

• What will you deliver for
• Service Oriented Analysis
• Service Oriented Design
• Service Development
• Service Testing
• Service Deployment
• Service Administration

13
Project RequirementsService Oriented Analysis

• Determine the scope of the SOA
• Deliverable 1-01 Requirements Statement
• Deliverable 1-02 Business Processes ERM Diagrams
  (see 11.3) for each usage scenario
• Optionally entity dependence diagram (see 11.4)
• Map out the (candidate) service layers
• Deliverable 1-03 Initial draft service layered
  architecture diagram (see figures 9.7 though
  9.14)
• Identify individual service operations modeled as
  candidate services
• Deliverable 1-04 Initial draft list of candidate
  operations
• Analysis process is identified in chap 11 and 12

14
Project RequirementsService Oriented Design

• Service Layers are finalized
• Deliverable 2-03 Finalized layered architecture
  diagram
• Candidate operations list is finalized
• Deliverable 2-04 Finalized list of candidate
  operations
• Candidate services are finalized
• Deliverable 2-05 All candidate operations
  allocated to candidate services (see figure
  12.4.2)
• Business process are mapped to operation
  sequences that will automate them (see figure
  12.9 trough 12.11)
• Deliverable 2-06 Map of each business process ERM
  diagram to its automation in the layered
  architecture SOA diagram
• Ws- extensions and other design decisions are
  finalized
• Deliverable 2-06 Same diagram as above, but each
  inter-service connection is foot-noted with
  whichever ws- extentions are appropriate for the
  service connection.
• SOA Design process is defined in chapters 13
  through 15

15
Service Development

• Actual construction of the services
• Deliverable 3-07 Each service is installed on the
  class web site
• Deliverable 3-08 A service consumer client(s) is
  submitted in class on CD-ROM. Will include the
  complete Visual Studio Solution/Project for each
  client/cosumer.
• Deliverable 3-08 A short users manual on how to
  install the clients and use them to invoke the
  services will be submitted bia email.
• Prior to this, the operation interfaces,
  operation behaviors, integration protocols,
  service/operation sequences defined, and mapped
  to the business processes and use case scenarios
• Other development paradigms are the primary
  approach used here, notable object oriented
  software engineering

16
Service Testing

• Involves both unit testing, and system or
  integration testing
• unit testing testing individual services, or
  even individual operations out of context
• Deliverable 4-09 A short unit test plan (what
  to do and what to expect when you do it) for each
  service, which exercises each operation.
• system testing testing entire operation
  sequences against the business process they
  automate
• Deliverable 4-10 A short system test plan which
  explains how to use your client(s) to accomplish
  the automated portion of each use case scenario,
  for each business process your SOA supports.

17
Service Deployment

• The deployment (installation, configuration,
  etc.) of all individual services, and their
  consumers/requestors
• You will have already deployed all your
  components to support the Service Testing phase.
  NO additional deliverables are required.
• integrating the services with
• their underlying functional components
• COTS products
• Legacy systems

18
Service Administration

• Operate the system
• Train users in the use of the system
• Maintain the system
• Evolve the system
• Track usage, maintenance, etc. of the system
• You are not required to submit any deliverables
  for the administration of your SOA project

19
Simplified SEAMSysReference System

• An example of a simplified System Engineering
  Asset Management System (SEAMSys)

20
Simplified means

• Remember, the goal here is to learn the analysis
  and design of an SOA solution, not SEAM
• If you want to learn much more about SEAM, take
  my component based software engineering course
  Fall 08
• We will only discuss some of the goals and
  processes of a SEAM
• We will discuss a system which satisfies only
  some of the requirements of a SEAMSys
• The automation side of a SEAM
• The design and implementation will not be
  complete
• Some security, maintainability, dependability
  issues will be simplified or ignored

21
Overview

• We will follow texts analysis and design methods
  in this exercise, some of which we have yet to
  cover
• Clarifications of SEAM terminology
• Tailoring Erl SO analysis and design to an
  iterative or spiral process
• Simplified SEAM Goals
• Simplified SEAM Processes
• Simplified SEAM System (SEAMSys)
• Simplified SEAMSys Usage Scenarios
• Simplified SEAMSys SOA Design
• Interoperable SEAMSys (iSEAMS)
• Updates of SEAMSys scenarios to iSEAMS scenario
• Updates of SEAMSys design to iSEAMS design
• Simplified iSEAMS SOA Implementation
• Simplified iSEAMS Concept of Operations

22
Clarifications

• SEAM
• System/Software Engineering Asset Management
  (SEAM) is a set of processes, or updates to
  processes in an organization
• SEAMSys
• A SEAM System (SEAMSys formerly SEAMS) is a
  automated system which supports the goals and
  processes of a SEAM
• iSEAMS
• An integrated group of SEAMSyss are
  Interoperating SEAMSyss or and iSEAMS

23
Development Process

• Iterative or Spiral Process
• Iterative design a little, build a little, test
  a little, repeat
• Spiral iterative with more rigor on selecting
  what a little means and adding a cycle analysis
  phase before repeat
• Ours will be a little more formal then iterative,
  a little less then evolutionary sprial

24
Iterative Spiral Process

• Scope entire project
• Select initial set of requirements
• Those that are well understood, and have fewest
  dependencies on other requirements design
  decisions
• Design to those requirements
• Keeping in mind the ones that are not included in
  this iteration
• Implement to that design
• Examine results
• Efficiency, completeness, difficulty, etc.
• Repeat
• Adding new requirements that are now better
  understood (based on iterations experience) and
  fewest dependencies on requirements not yet
  allocated

25
Simplified SEAM Goals

• Manage (capture, make accessible and preserve)
  the work products of engineering activities
• Control
• Capture the engineering work products (assets)
• Capture the metadata about those assets
• Make Accessible
• Organize assets and assets metadata so that
  assets can be found and accessed
• Preserve
• Protect assets from unapproved changes, and
  capture approved change history

26
Simplified SEAM Processes

• Initializing SEAM
• Establishing SEAM ingest, access and reuse
  policies and procedures
• Implementing SEAM System (automation)
• Operating SEAM
• Linking new project(s) to SEAM
• Ingesting assets into SEAMSys
• Finding and accessing assets in SEAMSys
• Updating SEAM controlled assets
• Repurposing/Reusing SEAM assets

27
Process Derivation Exercise

• Im the customer
• Youre the analyst
• Here are me requirements (next slides)
• Start asking me questions and identifying and or
  deriving the business processes that you will (at
  least in part) be automating in your SOA designed
  SEAMSys

28
XYZ Software Company PP

• Policies and Procedures
• All programs will maximize reuse of past
  development efforts
• Program managers are responsible that this
  happens
• PMs and staff are rewarded for reusing assets, or
  creating reusable assets (but not till theyre
  reused)
• All engineering assets are stored in the CM
  system, SourceSafe
• Weekly system build are only built from software
  in the CM system
• Company policy says that all requirements
  statements, design documents and testing material
  must be checked into the CM system
• Project is not closed until QA checked that all
  assets are checked into the CM system
• A life cycle phase can not be marked as complete
  on project schedule until all engineering assets
  created in that phase are checked in to the CM
  system
• XYZ software purchased ABC software in 2005 and
  QED software in 2007. They did not follow XYZ
  PP, but the ABC and WED CM archives are
  available on line.
• PMs are given bonuses based partly on the
  percentage of reuse their programs consume. This
  also helps determine the size of the bonus pool
  available for PMs to share with their staff
• Directors are given bonuses based partly on the
  number of reuses of components created by
  programs under their direction. This also helps
  determine the size of the bonus pool available
  for Directors to share with their staff.

29
Simplified SEAM System (SEAMSys)

• Simplified SEAMSys Usage Scenarios
• Simplified SEAMSys SOA Design
• Simplified Interoperable SEAMSys
• Logical extension of SEAMSys to iSEAMS which
  allows access across multiple SEAMSys
• Simplified iSEAMS Design
• Simplified iSEAMS SOA Implementation
• Simplified iSEAMS Deployment and Operations Plan

30
Simplified SEAMSys Usage Scenarios

• Iteration 1
• Engineers search SEAMSys for assets to reuse
• Engineers access assets
• Engineer submits new assets
• Iteration 2 (Dont start on these till NEXT
  week)
• Project registers with SEAMSys
• This enables them to access SEAMSys for reuse
  existing assets, and submit new assets
• SEAMSys admins update asset
• Which notifies registered asset users

31
Engineers search SEAMSys for assets to reuse

• Service(s) must have operation(s) that identifies
  what metadata fields are available to define a
  query with, and what values are valid for each
  field
• Exceptions None
• Service(s) must have operation(s) that accepts a
  query and creates a list of matching assets
• Exceptions Query is invalid or ambiguous

32
Engineers access assets

• Service(s) must have operation(s) that accept the
  identification of specific assets, and returns
  them to requestor
• Exceptions
• Identification for asset is not valid
• (optional iteration 2) User is not permitted
  access to asset

33
Engineer submits new assets

• Service(s) must have operation(s) that permit
  requestor to supply asset and related metadata
  for submission to SEAMS
• Exceptions
• Metadata is non valid or incomplete
• Asset is already in SEAM

34
Iteration 1 Tasks

• Week beginning 4/2/08
• Determine lifecycle model
• This is given, informal iterative spiral
• Agile strategy concurrent business analysis and
  service design
• Performing Analysis
• As defined in chapters 10 through 12
• Exercise analysis
• Preliminary design of Iteration 1 requirements
• Prototype implementation of Iteration 1 design

35
Iteration 1 Requirements

• Week beginning 4/2/08
• Must satisfy all usage iteration 1 usage
  scenarios
• Single stand alone SEAM
• Supports single project
• Limited, non-extendable set of metadata
• Ability to ingest asset with related metadata
• Metadata update not included
• All metadata entered manually
• Ability to search for assets via metadata
• No search of asset content itself
• Ability to retrieve specific assets
• No access or limited distribution (secure
  controlled access) functions as yet

36
Iteration 2 Tasks

• Week beginning 4/9/08
• Dont start on this till NEXT week
• Revisit Analysis
• Add iteration 2 requirements
• Add lessons learned from iteration 1
• Perform Design
• As defined in chapters 13 through 15
• Exercise Design
• Prototype Implementation of Iteration 2 design

37
Iteration 2 Requirements

• Week beginning 4/9/08
• Must satisfy all iteration 1 requirements and
  iteration 2 updated usage scenarios
• Dont start on this till NEXT week
• Multiple Projects
• Adding metadata about which project assets came
  from
• Metadata model can be extended
• New metadata fields, not just values, specific to
  projects or other asset collections
• Ability to edit metadata for existing asset, and
  to update an asset
• Ability to search asset (free text search)
• (optional) Inability to retrieve assets for which
  user does not have rights
• Implies new requirements to authenticate users
  and group assets according to access rights

38
Simplified Interoperable SEAMSys

• Purpose
• Logical extension of SEAMSys to iSEAMS which
  allows access across multiple SEAMSys
• Introduces no new processes or goals, simply
  extensions to existing ones
• Linking new project(s) to SEAM
• Ingesting assets into SEAMSys
• Finding and accessing assets in multiple SEAMSys
  both local and distributed
• Updating SEAM controlled assets and related
  metadata in all SEAMSys that reference updated
  assets
• Repurposing/Reusing SEAM assets both local
  (already owned) and distributed (partners)
• Changes from SEAMSys to iSEAMS are in RED

39
Simplified iSEAMS Usage Scenarios

• Very little change to existing SEAMSys scenarios
• An optional addition to each, to select which
  SEAMSys to search
• In many cases user will not be given the choice
• Some new usage scenarios we will not implement
• iSEAMS admin updates metadata and asset exchange
  configuration
• iSEAMS participating SEAMSys admins configure
  which SEAMSys groups of users can access
• iSEAMS participating SEAMSys admins configure
  which assets will be made available to other
  SEAMSys users

40
Creating Web Service on the Web Site

• File -gt New -gt Web Site
• Select ASP.Net Web Service template
• Location HTTP
• Language Visual C
• Location http//areopagus-soa.net/jhu_soa_s08/clas
  sproject/your_name/Web_Service_Name

41
Publishing a web site to the class web server (1
of 2)

• Prerequisites user name areopagusso, password
  spring2008, student folder your first initial
  and last name (instructors tpole)
• Areopagus-soa.net/jhu_s08/ClassProject/tpole
• Right click the web service project
• Select Publish Web Site
• Type in URL
• Select Allow this precomiled site
• Click the to the right of the URL, then
  select
• FTP Site
• Passive Mode
• Enter user name and password

42
Part a web site (2 of 2)

• Once Site is published go to discountasp.net and
  login
• Go down left column, find web application tool
• Left click on web service you just uploaded
• Click on (in right gray box) Install
  Application
• To change clients target web server
• Open the clients app.config file and change the
  url
• -or-
• Make a new web reference