OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

saf message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: [saf] RE: SAF meeting today - symptoms/prescription

Title: Message
Hi Alvin,
interesting issues you have touched there. Some comments inline.

This exercise highlights one of the key challenges we face with defining the problem domain of SAF.  I don’t THINK that any of us envision SAF as being just a generic information exchange standard.  Perhaps adoption and interest in the standard will not develop until we become MORE restrictive about what SAF is, rather than trying to make it more all-inclusive. 

 Right. It is not about simple information exchange standard. It is about collaboration, automated responses to conditions, etc.   

We’ve deliberately steered away from any such restriction in the past, but perhaps we need to limit SAF to the domain of “alerting about problems that may exist.”  We can still be generous in our definition of “problem” – an under-optimized system, for example, could be considered a “problem.”  Perhaps SAF is really just a standard for generic business process exception handling. 

 I don't think it is about PROBLEMS per se, but about any CONDITIONS that make sense to the participating entities, and for which those said entities wish to automate responses to.

To take just the first row in the below table as an example:


Invoices:  Do we really want to say that SAF can handle “primary” data packet transfers for well defined business processes such as invoicing?  My concern here is that there are probably already established information exchange packets for sharing invoices.  I don’t think that we could possibly make any inroads in to the exchange of invoices, and in fact, attempting to do so may actually weak the argument for SAF (we won’t be taken seriously).


So, in my mind, sending an invoice via SAF is clearly outside of the scope.  However, raising concerns about an invoice may not be outside of the scope of symptoms.  For example, the following may be a better example of something that would be within the domain of SAF (at least in my opinion):


“Outstanding invoices exceed credit limits of customer.”


So, sending an invoice within SAF would not be a good fit (this is a normal business flow).

Sending a notification that an invoice had been paid would not be a good fit (this is a normal business flow)


However, getting a symptom about a chargeback on a credit card (for example) and using that to trigger a prescription (turn off customer account) MAY be in the SAF domain (even this could arguably be a normal business flow though). 


 So the basic mindset is – if a system encounters a PROBLEM (or an indication of a potential problem) which it CAN NOT HANDLE within its domain, symptoms becomes the standard for REPORTING that problem to SOME OTHER ENTITY.  Now the danger with this approach is that someone might think it is “just another event format.”  Symptoms should perhaps be defined as the “subset of events that require mediating actions by an outside source.”  Hence, an audit event (“User XYZ successfully logged in”) is NOT a symptom, even though it is an event. 


 Thoughts on this anyone?  My fear is that we are becoming a giant vacuum cleaner for generic information flow scenarios – and I don’t think we will succeed if that is what we become.

Most are valid points here. E.g. simply notifying about an invoice or sending around invoices is not what SAF should be doing. But even this might depend to what the financing departments want to do for example. They may wish to automate some business processes based on some specific characteristics of the invoices (e.g. all invoices to very large customers are handling somewhat specially, or whatever), or, probably closer to SAF, when a certain number of invoices is reached, the batch processing and backup systems are activated.


So I don't think we should restrict to problem remediation. Besides, from the very beginning we talked about diagnostic or preventative or optimizing responses to conditions, not about problem resolution only. On that note, for the cloud profile the emphasis is given on the collaboration between consumer and provider, bridging information from many domains to define business conditions and automated responses. I think the current approach in the Cloud profile makes sense, if only we don't get stuck to some slightly minor or irrelevant stuff as you mention.


That is my 2 cents... More on the call in a while :-)







- Alvin




From: Vaught, Jeffrey A [mailto:Jeffrey.Vaught@ca.com]
Sent: Thursday, April 29, 2010 9:56 AM
To: saf@lists.oasis-open.org
Subject: [saf] RE: SAF meeting today - symptoms/prescription


Here are the results of my brainstorm (in table below), so far.

Will hopefully have more on the call today.


From: Vaught, Jeffrey A
Sent: Thursday, April 29, 2010 9:26 AM
To: saf@lists.oasis-open.org
Subject: SAF meeting today - proposed Agenda


Proposed Agenda:

-          Outreach review

-          Cloud Profile – potential prescriptions & symptoms across different business functions


Most of the meeting will focus on the latter (Cloud Profile).

Please be prepared to discuss candidate symptoms (and prescriptions) emitted from different business functions.  Pick your favorite business function and “have at it”!

Below is a list of business functions (stolen from a McDonald’s website).  I’ve organized into two columns – Cloud Consumer & Cloud Provider.



Consumer symptoms/prescriptions

Provider symptoms/prescriptions



Symptom: Invoice for XXXX service

Elements needed in Symptoms are:

-          Service identifier

-          Service description

-          Duration of service being billed

-          Amount

-          Unit (dollars, etc)

-          Due date


Symptom: Paid Invoice for XXXX service

Elements needed in Symptoms are:

-          Same as Invoice above

-          Amount Paid





Symptom: Estimate of XXXX service

Elements needed:

-          Same as Invoice



Internal Symptom: Cost of XXXX service

Elements needed:

-          List of items in the service

-          Materials cost per item

-          Labor cost per item

-          Overhead cost per item



Symptom: Our support staff will be ‘on leave’ for the Holidays, Dec 24 & 25.


-          Message

-          Category (hours-of-operation, safety, new-service-announcement, etc)

-          Date of applicability



Symptom: Release 11 of service XYZ is now available.


-          Message

-          Category (hours-of-operation, safety, new-service-announcement, etc)

-          Date of applicability




Corporate Tax



Customer Satisfaction

Symptom: Interfaces are difficult to use in Service XYZ release 11


-          Service identifier

-          Service description

-          Message

-          Satisfaction (excellent, good, fair, poor)

I’m thinking of this as different from SLAs.  Almost like a quality survey card.



Product Engineering/Development



Environmental Affairs


Internal symptom: Disposing of Server Rack 123


-          Hardware identifier

-          Hazardous chemicals reference




symptom: Service XYZ consuming 100 KW/H of energy

-          Service identifier

-          Consumption rate

-          Consumption total

-          Energy blend





Government Relations



Human Resources



Information Services (might be the same as Engineering for Cloud Provider?)















Quality Assurance









 Fujitsu Laboratories of Europe Limited
 Hayes Park Central, Hayes End Road, Hayes, Middlesex, UB4 8FE
 Registered No. 4153469
 This e-mail and any attachments are for the sole use of addressee(s) and
 may contain information which is privileged and confidential. Unauthorised
 use or copying for disclosure is strictly prohibited. The fact that this
 e-mail has been scanned by Trendmicro Interscan does not guarantee that 
 it has not been intercepted or amended nor that it is virus-free.

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]