The first six slides do not clearly differentiate SAF
from (yet another) CEP/Workflow. The remaining slides, however, do a
great job of differentiation. Would recommend starting with slide 7,
and moving the first 6 slides to the back of the deck.
It's a good
idea to start with the problem setting, but then in the cartoon slides we use
terms that haven't been defined yet (Diagnostician, Practitioner, etc). So this
Slide 3 explains Symptom, Syndrome, Protocol, and
Prescription. It would be good to articulate that these entities are
primarily envelopes for events, rules, action templates, and actions.
Thus we aren’t re-inventing BPEL, RuleML, etc.
The “cartoon” slides are great, but missing two
The provider is likely to provide Symptoms (and thus
contribute Syndromes to the catalog). The Symptoms would generally
describe service notifications such as “service will be out for maintenance”,
or “unplanned outage”, etc.
I agree with this
as well. But then it might get bloated, no?
There is no discussion of composability. The
consumer would typically compose Syndromes from other syndromes (contributed
from various sources) and also “glue” Syndromes to Protocols. In
my opinion – composability of diverse syndromes/protocols is the key
differentiator for SAF.
also interesting but very difficult to depict properly I think! Open to
Getting nitpicky, but slide 23 is titled
“Collaborations”, and I initially thought it was describing SAF catalog
:-) Do you want to rewrite the title? Jeff has
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.