[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: F2F - Day2 Notes
|
Welcome to Day 2 of the SAF face to face meeting! Enjoy! - Use Cases (in detail, extract spec elements maybe) - Interfaces for collaborative authoring, catalogue
manipulation, etc. - Cloud Profile (scope, purpose, extensions, constraints,
etc.) - Fujitsu technical submission Before starting, the consumer invoked: - Deploy Template (Sales_App) (1) Protocol published by provider: - Deploy Template (Adjust_Sales_App, N) (2a, 2b) Protocol retrieved by consumer: - Deploy Template (Adjust_Sales_App, N) (3) Consumer creates syndromes that reference the protocols Consumer Symptoms - Sales_per_hour(h) Source:
Infrastructure - Increased sales per hour * Source:
Internal or the sales department - Media endorsement Source:
Search service or marketing department - Anticipated large sales
increase Source: Internal or Crystal Ball service * this Symptom can come either manually
(e.g. a human operator emits it manually) or automatically if monitoring is in
place, e.g. Symptoms with sales per 5 minutes are emitted, and a Syndrome
"counts" sales per hour, and when it detects increased activity it
responds by emitting the "increased sales per hour" Symptom. Syndrome: Increased sales detected - Siganture:
(Sales_per_hour(now) >= 1.1*Sales_per_hour(now-1) >=
1.1*Sales_per_hour(now-2)) - Protocol: Issue_Symptom
(Increased sales per hour) Syndrome: Respond to increased sales per
hour by invoking Adjust Sales App Capacity Protocol - Signature: (Increased
sales per hour) - Protocol: Deploy Template
(Adjust_Sales_App, +1) Syndrome: Anticipated large sales increase
detected - Signature: (Media
endorcement) or (Sales_per_hour(now) >= 1.3*Sales_per_hour(now-1)) - Protocol: Issue_Symptom
(Anticipated large sales increase) Syndrome: Respond to anticipated sales
increase by invoking Adjust Sales App Capacity Protocol - Signature: (Anticipated
large sales increase) - Protocol: Deploy Template
(Adjust_Sales_App, +2) (4) Publish Syndrome (5) Diagnostician loads Catelogue Business Value: - Mapping consumer business conditions to provider cloud
responses - Proactive IT response to changing business conditions - Blending information and knowledge domains, e.g. multiple
parts of the business and external feeds, for competitive advantage - Contrabutions/Intelligence from multiple sources can be
independently contributed (Would you ever get marketing, sales, and IT
infrastructure together otherwise?) CLOUD PROFILE Issues 1. - Interfaces - get / put catalogue elements - Publishing / advertisement - symptom types - protocol types - syndromes 2. - Constraints 3. - Requirements 4. - Additional Elements 5. - Architectural Elements 6. Specific Types 7. Terminology These (below) fit into the numbered categories above. - Templates / parameterization - Parameter types - XML Schemas - Protocol structure, e.g. for capacity adjustments - Type - Relevant parameters - enumeration of resource to change - enumerations for tier to change - Type taxonomy / content - Interfaces / protocols / REST?? 1. ====== Interface ======= (THIS SHOULD REALLY FALL UNDER
ARCHITECTURAL ELEMENTS) Interfaces - Questions that might determine how we define
interface operations (from an author perspective): - What protocols are available from a given author? - Ditto for syndromes - Ditto but with substitutable parameters (ie: templated) - Attach protocol to Syndrome (insert, append) - Publish Syndrome to the catalog handler, ie: call
receiveCatalog, but only 1 Syndrome to publish (with or without associated
Protocols) - Publish Protocol to the catalog handler (only the
Protocol) - Activate Syndrome (might be an interface on the Diagnostian?) - I want to write a Syndrome -- What Symptom types do you
emit? Question posed from author to a given symptom emitter. - I want to write a Protocol -- What Prescription types to
you understand? Question posed from author to a given practitioner. - Questions about Protocol Directiive (as wouldn't the
author need to also understand the Symptoms) Interface discussion (per above)... Prescription: - Type: reboot - Args: ip, delay Protocol: Urgent reboot - Type: ureboot - PrescriptionType: reboot - Directive: symptom ip, 0 Protcol: Lazy reboot - Type: lreboot - PrescriptionType: reboot - Directive: symptom ip,20 We could have different authors for each of the following: - Prescription Types - persisted somewhere? We can
certainly ask the Practitioner, but need to have persisted/published prior to
Practitioner instantiation. - Protocols - persisted in catalog - Symptoms Types - persisted somewhere? See above. - Syndromes - persisted in catalog 2. ======= Constraints ========== An example might be: Only 1 protocol per syndome Likelihood can only be Rare,Common Behavioural - Any new Symptom (of a given
type/subject/reporter) obsoletes all prior symptoms. 3. ======= Requirements ======= An example might be: 1st arg for all Prescriptions must be
the Customer #. 4. =======Additional Elements ======= An example might be <Cloud_UserID> 5. =======Architectural Elements ====== Specific roles - mitigator, symptom store, other information
sources (cloud service catalog) 6. =======Specific Types=========== Symptom, Syndrome, Protocol, Prescription 7. =======Terminology============= -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Revisit use case #1 in context of above discussion.... Difficulty in finding Cloud contraints, requirments,
elements, etc that wouldn't go into base spec. Protocols (possibly even Syndromes) could be specified, but
too restrictive (inclusive of only a few standards, ie: DMTF incubator). Discussion about a "transform" from WSDL (for
example) that would generate a protocol type for each wsdl operation. That
transform process could be normatively described in the profile??? Looking from business function perspective... Business Functions (unique in Cloud space): - Privacy management - Contract - Provisioning - Security - Green Policy - Financial / Pay-per-usage - Audit - Compliance - Identity Steps forward... need more use cases: - Expand the rest of the use cases (the latter two) to the
same level of the first use case - Dave to do. - See into incorporating some of the identified business
functions into the elaborated use cases - Action items for next call: + Dave - expanding Provisioning mgmt + Green
Policy mgmt + Paul - Privacy + Stavros - Identity + Jeff - Financial + Yasu - Contract + Alvin - Security/Audit -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Tom (Fujitsu) ran through some issues with the SAF Base
Spec. Issue1 - signature xpath2 returns sequence of nodes, not a
document. Problems with result of signature with namespaces, plus difficulty
of dealing with node sequence rather than document. - Recommend moving to XQuery. Issue2 - similar problem with directive. Note that this
requires changes to the description of the arguments to a prescription, e.g.
remove the 's'. - Recommend moving to XQuery. Issue3 - Result of signature could be a sequence of
Symptoms, either from an "or" type of signature, or from getting
multiple hits on a match, ie: + UC1: I want my directive to issue a separate result
for each of the 3 symptoms returned from the signature. + UC2: I want my directive to issue a single result
based on the 3 symtpoms returned from the signature (some common value of all 3
for example). + UC3: I want my directive to issue a single result
based on something external to the original symptoms Note: Will need to change some of the incorrect wording in
the Spec. We need to clarify te relationship between the Subject as it appears
in the Signature and how it appears in the prescriptions. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]