Re: [public-xg-usdl] <none>

Hi everybody,

I agree, that attributes such as mailbox size, supported devices etc.
(i.e. non-functional attributes, attributes that represent constraints
over some functionality) should reside in the service level module.
However, the actual functionality (What does the service do? In this
case: transmitting textual messages), in my opinion, should stay in
the functional module.

Best regards
Oliver

---

Dr. Oliver Müller
Assistant Professor
at the Hilti Chair of Business Process Management

University of Liechtenstein
Institute for Information Systems
Fürst-Franz-Josef-Strasse, 9490 Vaduz, Liechtenstein
Phone +423 265 11 11, Direct +423 265 13 23
oliver.mueller@uni.li, www.uni.li




2011/3/31 Oberle, Daniel <d.oberle@sap.com>:
> Dear all,
>
> Torsten just made me aware that the service level module is the better place
> for representing such information. That means we look at the mailbox size as
> a specific service level. But you will run in comparable problems wrt
> variant mgmt although there is a specific mechanism called “base extension”
> for this module.
>
>
>
> Best
>
> Daniel
>
>
>
> From: public-xg-usdl-request@w3.org [mailto:public-xg-usdl-request@w3.org]
> On Behalf Of Oberle, Daniel
> Sent: Donnerstag, 31. März 2011 09:56
> To: Blackwell, Ken; public-xg-usdl@w3.org
>
> Subject: RE: [public-xg-usdl] <none>
>
>
>
> Dear Ken,
>
> yes makes sense and I got the idea. One could represent such information as
> “capabilities” in the functional module. This would look something like
>
>
>
> <Service>
>
> …
>
>     <Name>Gmail</Name>
>
>    …
>
>     <FunctionalElements>
>
>       <Capabilities>
>
>         <Capability>
>
>           <Name>1GB Mailbox size</Name>
>
>          …
>
>         </Capability>
>
>         <Capability>
>
>           <Name>10 preprocessing rules</Name>
>
>          …
>
>         </Capability>
>
>
>
> Although structured and “at the right place”, this solution is of course
> quite “loose” since it basically boils down to free text hindering
> comparability.
>
> The ideal would be domain-specific extensions of the language which are at
> the heart of variant management (cf. other threads in the mailinglist).
> Attributes such as mailbox size then should become part of the language
> looking something like this
>
>
>
> <Service>
>
> …
>
>     <Name>Gmail</Name>
>
>    …
>
>     <FunctionalElements>
>
>       <Capabilities>
>
>         <Mailbox >
>
>           <size>1 </size>
>
>          <unit>GB</unit>
>
>          …
>
>
>
> I assume the latter would be the preferred solution for you since
> comparisons are facilitated?
>
> The solution we proposed for variant management would allow users or some
> “consortium” to extend USDL via tool support incl. government.
>
>
>
> Best regards,
>
> Daniel
>
>
>
>
>
>
>
> From: Blackwell, Ken [mailto:Ken.Blackwell@ca.com]
> Sent: Dienstag, 22. März 2011 21:44
> To: Oberle, Daniel; public-xg-usdl@w3.org
> Subject: RE: [public-xg-usdl] <none>
>
>
>
> Hi Daniel,
>
>
>
> Sorry to be slow in responding.  Have been slow in everything lately as am
> very busy.
>
>
>
> To your question, we generally think of cloud services at a higher level
> than IaaS.
>
> While nothing should preclude a service comparison at a lower level, we
> think the urgent problem is much higher.
>
>
>
> So, rather than thinking of EC2, it might be most constructive to consider
> Gmail vs. Yahoo Mail vs HotMail as our use case.
>
>
>
> Some attributes of functional comparability might be:
>
> 1)      Total mailbox size
>
> 2)      Number of configurable preprocessing rules
>
> 3)      Integrations with Facebook and other social media
>
> 4)      Browsers supported
>
> 5)      Mobile devices supported
>
> 6)      Min/Max/Average times from message received by the service until it
> shows in the inbox
>
> 7)      Ability to block an incoming address
>
> 8)      Web service APIs available for integrations with other apps
>
> 9)      …
>
>
>
> Obviously most of these are specific to a particular class of service
> (Email), but USDL should have the ability to embed custom metadata
> attributes and for particular types of services (email, ERP, Payments
> processing, whatever) the industry can then coalesce around common
> attributes for a specific type of service based on industry specific
> standards, whether formal or defacto.
>
>
>
> Make sense?
>
>
>
> Ken Blackwell
> VP & Chief Architect, Service Assurance
>
> CA Technologies
> Tel: +1 203-733-5381
> Ken.Blackwell@ca.com
>
>
>
> From: public-xg-usdl-request@w3.org [mailto:public-xg-usdl-request@w3.org]
> On Behalf Of Oberle, Daniel
> Sent: Tuesday, March 08, 2011 7:32 AM
> To: public-xg-usdl@w3.org
> Subject: RE: [public-xg-usdl] <none>
>
>
>
> Dear Ken,
>
> thanks a lot for your explanation. As mentioned yesterday in the telco I
> deem this use case as one out of two required “implementations” of USDL for
> continuing down the path of W3C.
>
>
>
> I got a good high-level idea out of your explanations so far. I’d be
> interested in a concrete example, however. Say Service A is amazon’s EC2 and
> Service B is a similar one by a competitor. As you have written below you
> would like to compare if they are functionally similar. So what would you
> consider “functional” in the case of amazon EC2?
>
>
>
> Best regards,
>
> Daniel
>
>
>
> From: public-xg-usdl-request@w3.org [mailto:public-xg-usdl-request@w3.org]
> On Behalf Of Blackwell, Ken
> Sent: Mittwoch, 2. März 2011 21:21
> To: public-xg-usdl@w3.org
> Subject: [public-xg-usdl] <none>
>
>
>
> Hi All,
>
> I have had on my list for some time now to email the group some information
> and perspectives from IT management point of view.  Finally cleared a few
> days on my calendar to concentrate on this and my book chapter...
>
> First, some background.  CA Technologies is in the system management
> encompassing system monitoring, automation, security, and a host of other
> domains.  We are investing very heavily in the cloud space across all of our
> domains.  One of the most important new developments from CA is what we call
> Cloud Commons and the Service Measurement Index or SMI.
>
> You can read all about it at:
> http://www.cloudcommons.com/servicemeasurementindex/-/asset_publisher/M69c/content/how-smi-scores-are-calculated-and-what-they-mean?redirect=http%3a%2f%2fwww.cloudcommons.com%2fservicemeasurementindex%3fp_p_id%3d101_INSTANCE_M69c%26p_p_lifecycle%3d0%26p_p_state%3dnormal%26p_p_mode%3dview%26p_p_col_id%3dcolumn-2%26p_p_col_count%3d1
>
> The Clould Service Measurement Initiative Consortium, lead by Carnegie
> Mellon University in Silicon Valley has taken ownership of this proposed
> standard so it is not unique to CA.
>
> So what is SMI?  It is a set of business-relevant Key Performance Indicators
> (KPI's) that provides a standardized method for measuring and comparing
> business services.  It looks at things like performance, reliability, cost,
> and other quality metrics to provide an overall rating of the service so
> that two similar services can be compared.
>
> The inputs to Cloud Commons SMI is observed, either human or machine, KPI
> data that is entered by the community.  The idea is to replicate for cloudl
> service ratings what Amazon has done for rating products on its website.
> Over time, let the community coalese around an opinion of a service based on
> real-world observations.
> The community can then go to Cloud Commons and look at community ratings to
> decide which of  set of "similar" servcies best suites their needs for a
> particular purpose.
>
> And that is the rub; that word "similar".  I have complained for some time
> that we are focused on grading two services, say A and B, to compare their
> fitness for a particular business purpose based on observations of IT
> metrics, but we have not addressed the the upfront problem of determining if
> A and B are functionally "similar".
> We have tended to gloss over that question and focus on what we do well
> which is monitoring and measuring IT metrics.
>
> After complaining about this problem for some time internally to CA, I was
> asked by our CTO to join the USDL effort to help work towards a solution...
>
> I am going to be focused on providing feedback to this team on the
> comparability aspects of services defined in USDL.  This is related to
> searching which is already identified as an important aspect of USDL.
> Ideally, i would like to come up with a way to augment the SMI score with a
> something like a Service Equivalency Index that can advise the consumer of
> how similar two services are.
>
> I hope this provides some context and a complimentary point of view to the
> group.  My availability to focus on this effort varies greatly from week to
> week, so I probably won't be as consistent as I would like, but I'm always
> monitoring the effort and happy to hear your feedback to the ideas above.
>
> Regards,
>
> Ken Blackwell
> VP & Chief Archtiect
> Service Assurance Business Unit
> CA Technologies
> +1 (203) 733-5381
>
>

Received on Thursday, 7 April 2011 12:05:47 UTC