1 / 30

Class Project Working Session

Class Project Working Session. 605.702 Service Oriented Architecture Johns-Hopkins University Montgomery County Center, Spring 2009 Session 12, Lecture 12: April 22, 2009 Instructor: T. Pole . Agenda. Deliverables templates and discussion Reusable legacy components Usage scenarios

zacharee
Download Presentation

Class Project Working Session

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Class Project Working Session 605.702 Service Oriented ArchitectureJohns-Hopkins University Montgomery County Center, Spring 2009 Session 12, Lecture 12: April 22, 2009 Instructor: T. Pole

  2. Agenda • Deliverables templates and discussion • Reusable legacy components • Usage scenarios • In class exercises • Class project working session

  3. Example Project: Analysis and Design Artifact Templates • Review deliverables check list • Map individual documents to deliverables • Several deliverables can be combined to create one document • Deliverable templates • Notes on deliverables

  4. Deliverables Check List

  5. Map Deliverables to Documents

  6. 0 ROI Analysis Report Template • 0-1.0 Business Benefits of SOA Approach • What operational business benefits will my enterprise achieve by using an SOA approach to building his system • 0-2.0 Technical Benefits of SOA Approach • What technical benefits will my enterprise achieve by using an SOA approach to building this system

  7. 0-1.0 Business Benefits of SOA Approach • Write a defense of the decision to build this system according to an SOA approach • Discuss cost, benefits to the company, support for future enhancements organizational agility, etc. • Don’t leave out risks, and negative aspects of SOA approach • Compare to other development methods but only in terms of business benefits

  8. 0-2.0 Technical Benefits of SOA Approach • Write a defense of the decision to build this system according to an SOA approach • Discuss technical benefits to the company, flexibility, maintainability, etc. • Don’t leave out risks, and negative aspects of SOA approach • Compare to other development methods but only in terms of technical advantages and disadvantages

  9. 1 Service Oriented Analysis Report • 1-1.0 Requirements Statement (testable, unambiguous, plus derived) • 1-2.0 Business Process Flow Diagrams • 1-3.0 Draft Layered Architecture Diagram (middle of three layer cake) • 1-4.0 Draft list of Candidate Operations

  10. 1-1.0 Requirements Statement • Statement of usage scenarios • 1-1.0-1, 1-1.0-2, thru 1-1.0-5 • List of derived requirements that apply to each scenario (as needed) • For 1-1.0-1: 1-1.0-1.1, 1-1.0-1.2, etc. as needed • List of derived requirements that are not specific to a single scenario • 1-1.0-6

  11. 1-2.0 Business Process Flow Diagrams • One biz proc flow, drawn in your tool of choice including VERY NEAT hand drawn if that’s all you have available, for each business process your are building supporting automation for. • The list of scenarios is the basic business process list, though you may additional business processes if you see they are needed, and you build them • Number them 1-2.0-1 through 1-2.0-5 or greater if needed • For each business process, write a short narrative describing each step in the process, who will use that process (basic user or admin or both), and the business purpose of performing the scenario. What is its business value

  12. 1-3.0 Draft Layered Architecture Diagram • 1-3.0-1 Introduction to what the layered diagram represents • This diagram is just the middle layer of the three layer cake – the SOA layer • 1-3.0-2 Rational as to why you choose the used to determine the layered architecture you selected • 1-3.0-3-1 thru 1-30-3.2, etc. Describing the purpose of each layer, and what kinds of services are in that layer

  13. 1-4.0 Draft list of Candidate Operations • 1-4.0-1 List of candidate operations • Name and short (2-3 sentence) description of what each operation is labeled 1-4.0-1.1, 1-4.0-1.2, etc • Identify the most obvious parameters or return types used by operations • 1-4.0-2 List candidate services, first draft factoring of operations into services • Describe the commonality of each service, and list its candidate operations, and label these sections 1-4.0-2.1, 1-4.0-2.2, etc. • Update 1-3.0-3-1 thru 1-30-3.2, etc. with candidate services

  14. 2 Service Oriented Design Template • 2-1.0 Final Layered Arch Diagram • 2-2.0 Final List of Candidate Services and Operations • 2-3.0 One diagram per business process, mapped to SOA, plus identification of WS-* extensions to be used

  15. 2-1.0 Final Layered Arch Diagram • Update the content of 1-3.0, using the same f0rmat and the same sections, section numbering etc. except they will start with 2-1.0 instead of 1-3.0 • Change rationale and descriptions as needed • In section 1-3.0-2, make sure to update this according to any changes you made in the architecture between 1-3.0 and 2-1.0

  16. 2-2.0 Final List of Candidate Services and Operations • Update the content of 1-4.0, using 2-2.0 as the prefix of the numbering instead of 1-4.0 • In section 2-2.0-2 state why you made any changes to the definition of the commonality of services, addition or deletion of services, etc.

  17. 2-3.0 Map Business Process to SOA • For each business process, create a three layer cake diagram • The top layer being ONE BUSINESS PROCESS • The middle layer being the entire SOA • The bottom layer showing the legacy software components, and any other lower level components you optionally created • Number the diagrams 2-3.0-1, 2-3.0-2, etc, for each business process • Write a short narrative for each diagram that explains how your SOA automates each step in the business process; in terms te end user of the system would understand

  18. 3-01 Dev-Package • All of your projects in one VS solution, all zipped into one file. • Any additional files I will need (optionally) to install, configure or run your system • Deliver BOTH as an email and a CD or (at your option) USB memory stick

  19. 3-02 User Manual • 3-02-1.0 Instruction on installation • What do I have to do to install, configure and startup your system • 3-02-2.0 Usage instructions per scenarios • For each scenario • Describe the scenario (using the text I’ve given you as a starting point) • Describe how I will use your end user client to accomplish this scenario • 3-02-3.0 Error Message • Describe the meaning of and what I should do if I receive an error message from your system

  20. Notes on Deliverables • Ask yourself, where in your design report will I find: • The complete signatures of each operation • The abstract definition of your XSD, your user defined types used as parameters in operations • Where do you map the business process steps to specific operations or MEP’s

  21. Reusable Legacy Components Version 2 • DocManager • Stores the documents • Can be categorized (aka classified) • Can be searched for by category • TextIndexer • Indexes a document • Builds a list of words the document contains • Allows a document to be searched for by words it contains

  22. Usage Scenarios • Some of the scenarios have been simplified slightly. • Example: Only one asset can be retrieved on a single retrieve request from the client

  23. Scenario #1: Engineers Searches for Assets • Service must have operation(s) that accepts a query and returns a list of matching assets • The info in the list of each matching asset, must contain sufficient info to subsequently invoke an operation to retrieve an asset • Exceptions: Query is invalid or ambiguous

  24. Scenario #2: Engineers Access Assets • Service must have operation(s) that accept the identification of a specific asset, and returns that asset to the requestor • Exceptions: • Identification for asset is not valid

  25. Scenario 3: Engineer Submits new Assets • Service must have operation(s) that permit requestor to supply asset and related metadata for submission to SEAMS • Exceptions: • Metadata is non valid (e.g. assigning an asset to a project which has not yet been registered with the system) • [OPTIONAL-extra credit] Asset is already in SEAM (exact character for character match to an existing asset)

  26. Scenario 4: Project Registers with SEAMSys • Service must have operation(s) that allow user to inform repository that there is a new valid value for the metadata field which records project that asset originated from. • Exceptions: • Project is already registered in repository (exact character for character match in project name)

  27. Scenario #5: System Admin Updates Asset • Service must have operation(s) that permit end user to change the content of an asset, and change the values for an asset’s metadata fields. • Exceptions: • New value for metadata is not valid

  28. Reusable Legacy Components • TextIndexer • http://areopagus-soa.net/JHU_SOA_S09??? • DocManager • http://areopagus-soa.net/JHU_SOA_S09??? • Some minor interface changes • Added some methods • Changes one methods signature

  29. In Class Exercises • Exercise #1 • You must allow content of assets as well as the metadata to be updated/changed. How do you do this? • Exercise #2 • The sys-admin is allowed to change an asset, but not all users. How will you authorize the sys-admin user to do this? • You do not need to create users at run time, just define in your code two users, one of which is an admin, one of which is a basic user • You do not need to password protect thee accounts

  30. Class Project Working Session • Q&A I • Work in groups • Q&A II

More Related