1 ECCF Training 2.0 Implemental Perspective (IP) ECCF Training Working Group January 2011.

Slides:



Advertisements
Similar presentations
2/11/2014 8:44 AM The CDA Release 3 Specification Stack September 2009 HL7 Services-Aware Enterprise Architecture Framework (SAEAF)
Advertisements

Copyright © 2006 Data Access Technologies, Inc. Open Source eGovernment Reference Architecture Approach to Semantic Interoperability Cory Casanave, President.
Web Service Architecture
Siebel Web Services Siebel Web Services March, From
Overview of Web Services
Modeling with the ECCF SS ● UML Profile for ECCF ● UML Redefinition Semantics ● Compliance ● Consistency ● Conformance ● Validation ● Transformation ●
1 Introduction to XML. XML eXtensible implies that users define tag content Markup implies it is a coded document Language implies it is a metalanguage.
L4-1-S1 UML Overview © M.E. Fayad SJSU -- CmpE Software Architectures Dr. M.E. Fayad, Professor Computer Engineering Department, Room #283I.
Knowledge, Skills, and Abilities Working Group Hua Min Jahangheer Shaik Natasha Sefcovic Kahn Aleksey.
Recall The Team Skills 1. Analyzing the Problem (with 5 steps) 2. Understanding User and Stakeholder Needs 3. Defining the System 4. Managing Scope 5.
1 ECCF Training 2.0 Introduction ECCF Training Working Group January 2011.
Kmi.open.ac.uk Semantic Execution Environments Service Engineering and Execution Barry Norton and Mick Kerrigan.
Sharif University of Technology1 Design and Use-case Realization Software Engineering Laboratory Fall 2006.
Use Case Analysis – continued
Web Service Architecture Part I- Overview and Models (based on W3C Working Group Note Frank.
Roles and Responsibilities Jahangheer Shaik. Service Specification Specification requires development of three inter-related documents CIM, PIM and PSM.
Processing of structured documents Spring 2003, Part 6 Helena Ahonen-Myka.
TIBCO Designer TIBCO BusinessWorks is a scalable, extensible, and easy to use integration platform that allows you to develop, deploy, and run integration.
Introduction to UDDI From: OASIS, Introduction to UDDI: Important Features and Functional Concepts.
CaGrid 2.0 December What is caGrid 2.0??? Provides a patch for caGrid 1.x to support SHA2 OSGi implementation of WSRF on the new technical stack.
© The ATHENA Consortium From PIM4SOA to Peer-2-Peer (P2P),
T Network Application Frameworks and XML Web Services and WSDL Sasu Tarkoma Based on slides by Pekka Nikander.
1 ECCF Training 2.0 Platform Specific Model (PSM) ECCF Training Working Group January 2011.
IHE Profile – SOA Analysis: In Progress Update Brian McIndoe December 6, 2010.
Integrating Security Design Into The Software Development Process For E-Commerce Systems By: M.T. Chan, L.F. Kwok (City University of Hong Kong)
International Telecommunication Union Geneva, 9(pm)-10 February 2009 ITU-T Security Standardization on Mobile Web Services Lee, Jae Seung Special Fellow,
Microsoft Visual Studio 2010 Muhammad Zubair MS (FAST-NU) Experience: 5+ Years Contact:- Cell#:
Architecting Web Services Unit – II – PART - III.
1 ECCF Training 2.0 Guidance for the Logical Perspective Specification ECCF Training Working Group January 2011.
SWE © Solomon Seifu ELABORATION. SWE © Solomon Seifu Lesson 10 Use Case Design.
Nadir Saghar, Tony Pan, Ashish Sharma REST for Data Services.
XML Web Services Architecture Siddharth Ruchandani CS 6362 – SW Architecture & Design Summer /11/05.
1 caBIO ECCF Pilot Konrad Rokicki ICR Workspace Call July 28, 2010.
Requirements as Usecases Capturing the REQUIREMENT ANALYSIS DESIGN IMPLEMENTATION TEST.
Shannon Hastings Multiscale Computing Laboratory Department of Biomedical Informatics.
1 Open Ontology Repository: Architecture and Interfaces Ken Baclawski Northeastern University 1.
1 ECCF Training Computationally Independent Model (CIM) ECCF Training Working Group March 2011.
Unified Modeling Language* Keng Siau University of Nebraska-Lincoln *Adapted from “Software Architecture and the UML” by Grady Booch.
L6-S1 UML Overview 2003 SJSU -- CmpE Advanced Object-Oriented Analysis & Design Dr. M.E. Fayad, Professor Computer Engineering Department, Room #283I College.
IHE Profile – SOA Analysis: In Progress Update Brian McIndoe January 18, 2011.
Service Oriented Architecture CCT355H5 Professor Michael Jones Suezan Makkar.
1 SAIF-Effects on Data Service Specifications Baris Suzek Georgetown University Architecture/VCDE Joint Face-to-Face June,3, 2010 St. Louis, Missouri.
XML Grammar and Parser for WSOL Kruti Patel, Vladimir Tosic, Bernard Pagurek Network Management & Artificial Intelligence Lab Department of Systems & Computer.
Logical view –show classes and objects Process view –models the executables Implementation view –Files, configuration and versions Deployment view –Physical.
Archie Warnock, A/WWW Enterprises OCG Catalog Specification v2.0 Overview and Discussion Archie Warnock, Doug Nebert Yonsook Enloe, Jolyon Martin May 14,
1 ECCF Training 2.0 Introduction ECCF Training Working Group January 2011.
Kemal Baykal Rasim Ismayilov
1 Service Creation, Advertisement and Discovery Including caCORE SDK and ISO21090 William Stephens Operations Manager caGrid Knowledge Center February.
1 ECCF Training 2.0 Guidance for the Platform Independent Model (PIM) ECCF Training Working Group January 2011.
Requirement Engineering. Recap Elaboration Behavioral Modeling State Diagram Sequence Diagram Negotiation.
EGOS LLC CCSDS 14/ Question Question; Why a Service Viewpoint? Short Answer; Because a service viewpoint provides a useful additional level.
Architecture View Models A model is a complete, simplified description of a system from a particular perspective or viewpoint. There is no single view.
Week 04 Object Oriented Analysis and Designing. What is a model? A model is quicker and easier to build A model can be used in simulations, to learn more.
GEO PLACES EXPLORER PRESENTED BY KHUSHBOO BAGHADIYA SUMANA VENKATESH.
1 ECCF Training 2.0 Guidance for the Logical Perspective Specification ECCF Training Working Group January 2011.
Behavioral Framework Background & Terminology. Behavioral Framework: Introduction  Background..  What was the goal..
XASTRO-2 Presentation CCSDS SAWG th November 2004.
1 ECCF Training Computationally Independent Model (CIM) ECCF Training Working Group January 2011.
OOD OO Design. OOD-2 OO Development Requirements Use case analysis OO Analysis –Models from the domain and application OO Design –Mapping of model.
1 ECCF Training Computationally Independent Model (CIM) ECCF Training Working Group March 2011.
Expense Tracking System Developed by: Ardhita Maharindra Muskan Regmi Nir Gurung Sudeep Karki Tikaprem Gurung Date: December 05 th, 2008.
DEVELOPING WEB SERVICES WITH JAVA DESIGN WEB SERVICE ENDPOINT.
Jackson, Web Technologies: A Computer Science Perspective, © 2007 Prentice-Hall, Inc. All rights reserved Chapter 9 Web Services: JAX-RPC,
CTMS Coordination Team CTMS Coordination Team: Model and Documentation Management John Koisch Paul Boyes
Sabri Kızanlık Ural Emekçi
Unified Modeling Language
Systems Architecture & Design Lecture 3 Architecture Frameworks
Design Yaodong Bi.
Design.
Presentation transcript:

1 ECCF Training 2.0 Implemental Perspective (IP) ECCF Training Working Group January 2011

2 Outline Implemental Perspective (IP) What is the Implemental Perspective ? IP Enterprise Viewpoint IP Information Viewpoint IP Behavioral Viewpoint IP Implementation Viewpoint IP Technology Viewpoint IP Specification Overview

3 Remember our Case Study: Molecular Annotations Service: We have defined the Conceptual Perspective. “Conceptually what purpose does this service serve?” We have defined the Logical Perspective. “What are the specific capabilities and what does the data model look like?” Now we want to define the Implemental Perspective. “What would a platform specific instance of this service look like?”

4 Considerations: What is the Implemental Perspective? Implementable Perspective. “implementable perspective”…..not necessarily “implemented perspective” What is the “Platform”? Most specifications in the NCI CBIIT SOA Enterprise the “Platform” will be web or REST services. So we need to think at the level of WSDL/WADL and/or Schema artifacts for defining operations, messages, data types, and attributes.

5 NCI CBIIT PSM Required Artifacts

6 Viewpoints for the Implementable Perspective Enterprise Viewpoint Conformance Profiles – Traceability Matrix Technology Stack Information Viewpoint Domain Information Model Behavioral Viewpoint Service Interface Sequence Diagram Engineering/Implementation Viewpoint Standards Deployment Diagrams Sequence Diagram Deployment and Implementation Considerations

7 Enterprise Viewpoint PSM Artifacts The primary artifacts generated from the Enterprise Viewpoint at the Implementable Prospective include: Traceability Matrix (Conformance Profile): Traces back the functional interface and information model that are tied to a particular platform at the PSM specification level to the PIM specification level. This ensures that there is no loss of functionality or information from the Implementable to Logical to PSM specification levels. Technology Stack: Defines the list of the approved technology platforms through which the service should be realized (i.e. defines the “platform”)

8 Conformance Profiles Conformance profiles enable the mapping of the functional and semantic profiles at the Logical level to that described at the Implementable level to ensure that at the Implementable level no functionality, semantics, or conformance statements described in the Logical prespective is lost. Example: In the “logical” prospective we define a functional profile describing a set of required capabilities, realized by operations, that are required. In the “implementable” prospective we must be sure that each of these operations is actually specified in the service specification. We can explicitly state which functional profiles the service is going to adhere to (the conformance profile) by mapping from one in the logical prospective directly to an interface in the implementable prospective. A set of traceability matrix artifacts will define this.

9 Conformance Profiles Example:

10 Traceability Matrix Example The Molecular Annotation Service explicitly defines that it will implement the MA-FP1 function profile. This functional profile was specified in the logical prospective and is now being mapped in the implementable prospective to a service interface.

11 Traceability Matrix Example Then it maps each capability from the logical prospective to the actual operation in an interface which provides the implementable prospective of that capability.

12 Technology Stack Enables setting guidance and requirements to implementation teams for technology choices. May refer to an existing enterprise technology stack such as the NCI CBIIT Technology Stack. Ensures technology compatibility across other implementable prospective service specifications. Helps to define the “platform” for which this specification is designed to be implemented on. Enables top level technology changes to be reflected across a wide range of service specifications. May also put in service specific technology requirements or choices above and beyond a referenced technology stack.

13 Technology Stack Example From caGrid 1.0 as an example.

14 Information Viewpoint Implemental Perspective Artifacts The primary artifacts generated from the Information Viewpoint at the Implementable Prospective include: Domain Information Model: Further localization of the Domain Information Model defined the Logical perspective Enables further refinement of the model. Enables specification of a transport or persistence model to used in the Implementable perspective. Enables localization of a model for restricting values for use in the Implementable perspective specification instance.

15 Information Model Example (Class Diagram) The model created at the Implementable Prospective can localized or restricted.

16 Information Model Example (Schema/Message Types) Creation of XSD for representing message types.

17 Information Model Example (Localization) Example localization of values to a particular vocabulary (ISO21090 in this case). The Person objects attributes are being defined to be of value types defined in another vocabulary.

18 Behavioral Viewpoint Implemental Perspective Artifacts The primary artifacts generated from the Behavioral Viewpoint at the Implementable Prospective include: Service Interface: Platform specific specification of service interface. Should be the WSDL/URL representation of the Logical Perspective functional profiles. Could also contain the Java API representation of the Logical Perspective functional profiles. Could also contain the.NET API representation of the Logical Perspective functional profiles. May add extra operations to facilitate required platform specific functionality.

19 Service Interface Example (DOC) Each interface and its operations should be specified in the PSM document so that it can easily be traced back to the Logical Prospective

20 Operation Behavior Example operation behavior description for the “Query” operation.

21 Service Interface Example (WSDL) for soap based services Basic StructureSimple Example

22 Service Interface Example (WADL) for REST based services platform specific functionality.

23 Implementation Viewpoint Implemental Perspective Artifacts The primary artifacts generated from the Implementation Viewpoint at the PSM specification include: Standards: A list of standards that are applicable for the chosen platform to which the service implementation needs to adhere. Deployment Diagrams: Deployment diagrams define the deployment model for the given service, identify various nodes on which service will be deployed, and identify the connections between them. If there are additional deployment-specific details, they need to be highlighted as well. Sequence Diagrams: Sequence diagrams define the sequence of events and operation calls that the client will perform, such as to discover or invoke the service, to authenticate the service, to initiate a transaction, or to obtain a connection. The sequence diagrams should showcase the non-functional platform-level interactions only. Deployment and Implementation Considerations: Based on the deployment model, as well as on various non-functional capabilities, the Engineering Viewpoint can inform the service developers about various deployment and implementation considerations that need to be addressed during development.

24 Standards Standard Models and Vocabularies are used to localize and/or restrict the service as well as semantically anchor the data types that are being used in the service help to increase interoperability.

25 Standards Technology standards are defining the “platform” at the Implementable Prospective level. Standards such as WSDL, WSRF, and XML (technology standards from caGrid 1.X) are used to define the platform by which this service is indented to be implemented in and operate in.

26 Deployment Diagrams Deployment diagrams can be used to show the high level components and how they are decoupled and communicate. The diagram may also note deployment level considerations and or requirements.

27 Sequence Diagrams Sequence diagrams A sequence diagrams can help illustrate the intended flow for using the service. For instance, if there are functional dependencies like a user must first call “register” and then “query”. Or when it is expected that a user will “login” and then “query”.

28 Deployment and Implementation Considerations Details about errors.

29 Deployment and Implementation Considerations Deployment details.

30 Deployment and Implementation Considerations Security details.

31 Implementable Prospective Artifacts The primary artifacts-generated Technology Viewpoint at PSM specification include: Implementation Considerations

32 Case Study: Molecular Annotation Implemental Perspective One final Look at a complete Implementable Perspective and all its artifacts in the submitable template.

Exercises 1. Create Conformance Profile 2. Create Traceability Matrix 3. Create Operation Behavioral Descriptions 4. Create Localized Schema Model 33