OASIS presentation on cloud computing standards and the landscape ahead. At the organizing meetings of OMG's CSCC cloud group in June 2011.

1. Cloud Computing and
Open Standards

2. Open Clouds and
Open Standards
IX
How's it going?
Pretty well.
M
RE

3. "The largest
standards
group for
electronic Over 5,000 participants
commerce on representing more than
the Web" 600 organizations and
individuals, since 1993
60+ technical
committees producing
royalty-free and RAND
standards

4. OASIS: Standards for
e-business and e-gov ...
 Service Oriented Architecture & Web Services: SOA
Reference Model, WS-Transaction, WS-Reliable
Messaging, BPEL, UDDI, ebXML, ID-Cloud ...
 Security & Identity: WS-Security, SAML, XACML, KMIP,
WS-Federation, XSPA, SPML, PMRM, ORMS ...
 e-Government: Emergency/CAP, UBL, TGF, SmartGrid
(EMIX, WS-DD, OBIX, WS-Calendar) …
 Documents: ODF (OpenDocument Format); DITA;
CMIS; DocBook ...
 Semantics & KM: QUOMOS, UnitsML, SEE, SET,
Search Web Services ...

5. Why Open Standards? Safety.
Real open standards are:

Publicly & persistently visible for review
 Developed fairly under transparent, published rules
 Open to comment: public comments, no NDAs
 Available to use under clear, irrevocable licenses
Anything else is proprietary (vendor-centric).
Nothing wrong with that; but it doesn't provide the same
kind of interoperability and stability assurance.

6. Why Open Standards?
Open Standards are
Reliable and Stable

Open access from stakeholders
 The standard on which you build is less likely to
disappear, be obsoleted or invisibly modified

Stable rules & neutral management help assure against
invisible lock-in to unilateral viewpoints: auditable
sources, drafts and licensing

This is why governments prefer open standards: WTO
Technical Barriers to Trade Agreement, Annex 3
http://www.wto.org/english/ docs_e/ legal_e/final_e.htm

7. Why Open Standards?
Real Standards, versus
Drafts and Proposals
 Final open standards have the benefits of open
process protection and licensing rules
 Drafts, notes & proposals may just be one
company's idea - or property
 Publication of work in neutral, archival forms
on which implementers can safely build

8. So what about the Cloud?

9. It’s a fairly loud, crowded
topic right now

10. But maybe not as complex
as it sounds
software-as-a-service
In the 1980s paradigm, your
In the

platform-as-a-service 1980s paradigm, your

microcomputer was on your
microcomputer was on your
application-as-a-serviceandititwas your problem. your
desk, and idea youryour data,
desk, was
Theidea that
that
problem.

 The my desk, youris my your
andisdata,
Mineis on my desk, resources, and your
is on
 Mine computing resources, and your
computing and my
storage-as-a-service
problem.
problem.softwaremay be elsewhere,
software may be elsewhere,
They were connected. But by
They were new.
isn't new.
isn't

infrastructure-as-a-service connected. But by

obvious, episodic connections.
obvious, episodic connections.
LikeSneakerNet. No-one sat up
LikeSneakerNet.isNo-one sat up
acronyms-as-a-service Neither is outsourcing.
Neither outsourcing.
nightsworrying about where
nights worrying about where
boring-slides-as-a-service was.
the data
the data was.

 Or who controls it.
Or who controls it.
oy-gevalt-as-a-service

11. Most of the challenges that
"the cloud" brings, we've
cloud we
already encountered.
 Your data is somewhere else.
 Your data and applications all must work
with each other (and there are a lot of
them).
 You don’t know who all your users or
network nodes are (or will be later).

12. Your data is somewhere
else.
Answers: Remote storage methods,
Shared data repositories and registries
 We had standards for those by the
early 2000s. (SNIA; OASIS’s UDDI,
ebXML Registry, and more recent
developments like S-RAMP.)

13. Your data and applications
are owned by someone else.
Answers: Application Service Provider duties
& licensure expressed either in SLAs (Service
Level Agreements), when the economics
support a contractual solution; or
reputational enforcement & incentive
systems, when they don't.
don
 Basic contract law can solve the first case
 Older market practices for reputational economy
can address the second. (Some standards are
being developed for the latter: ORMS.)

14. Your computational
platform has to work with
all the other
computational platforms,
and there are a lot of
them.
We have had a solution for that one for a
while, too, called "the Internet ."

Not much that’s new, in 2011, about getting
diverse machines to talk to each other.

It takes what it always did: standards.

15. Your computational
platform is somewhere
else, owned by someone
else.
Answers: Virtualization …

Evolving metadata standards. (DMTF’s OVF)

Hypervisor commoditization? (Open source tools?)

Evolution in server-counting for licensing fees
… Managed Service Providers > Cloud
providers; Traditional outsourcing
 With an underpinning of contract law

16. Lots of different data
applications must work
with each other
Answers: Standard APIs, Service
Oriented Architecture
 Well-established methods in stable standards
and web services work. (OASIS’s SOA
Reference Model, WS-* standards; work from
W3C, the Open Group, OMG, etc..)
 Some standards are being refactored for cloud
optimization. (E.g, AS4 for WS-* adapted ebXML
MSG: see http://www.oagi.org/oagi/Website/Case_Studies/
OAGIS_AS4Cisco-final-1.pdf.)

17. Service Oriented Architecture: SOA
 Services That Describe Themselves: devices
and users can find, and consume, data and
computation services across networks.
 Loose Coupling: Services have defined
interfaces for shared data and signals, between
“block boxes”, but they are not required to work the
same way inside each “box.”
 Late binding: Activities and operations can occur
(“run time”) without all pieces being specified in
advance (at “design time”).
Required: Open standards and open design
Results: Extensibility; no lock-in

18. You don’t know who all
your users or network
nodes are.
Answers: Federation ...
 Formal functions for many-to-many cooperation.
 Well-established, stable standards. (OASIS’s SAML
(used in OpenID & Kantara), WS-Federation.)
… and Provisioning

Account and access control management.
 Well-established, stable standards & methods.
(OASIS’s XACML, PMRM, ID-Cloud, SPML, XSPA,
KMIP.)

19. Open cloud standards empower users
Identity in the Cloud TC SOA Reference Model TC
• Standards profiles for open • Abstract model of the basic
identity deployment, provisioning components, by function, of any
& management in cloud working service architecture
environments • Method-neutral
• Use cases & gap analysis • See: http://www.oasis-
• See: http://www.oasis- open.org/committees/soa-rm
open.org/committees/id-cloud
Privacy Management SOA Repository Artifact
Reference Model (PMRM) TC Model and Protocol (S-
• Service & interaction patterns for RAMP) TC
deploying and assessing formal, • Interaction protocol & common
reusable representations of privacy data model for federatable,
policies distributed data repositories
• See: http://www.oasis- • See: http://www.oasis-
open.org/committees/pmrm open.org/committees/s-ramp

20. Open access control standards empower users
Security Assertion ML XACML TC
(SAML) TC • Access control and authorization
• Reusable representations of user policy representation
authentication, entitlement and • Role-based access and
attribute data hierarchical resource profile
• Widely used in Kantara, OpenID, • See: http://www.oasis-
other frameworks open.org/committees/xacml
• See: http://www.oasis-
open.org/committees/security Provisioning Services
WS-Federation TC / WS-Trust (SPML) TC
• Message exchange and • Common XML language for
provisioning and allocation of
metadata/token policy control
enterprise identity
• Federation and brokered trust
• Builds on LDAP, Active Directory,
capabilities
DSML
• See: http://www.oasis-
• See: http://www.oasis-
open.org/committees/wsfed
open.org/committees/provision

21. The Open Cloud Manifesto:
from the mouths of buyers
CIOs, governments, IT users and business leaders establish a
set of core principles for cloud providers.

Cloud architecture should be scalable on demand; enable cost
savings by increasing opportunities via re-use and outsourcing;
and support portability among vendors and systems.
 This can and should be achieved by using collaborative open
standards, most of which already are available and in use, to
fulfill cloud security, integration, data sharing, policy
governance, network management and monitoring functions.

Customers, vendors and standards bodies must work together
to make good use of existing methods, and avoid excessive
duplication, rather than “reinventing the wheel.”

22. Open Cloud means
Open Standards.
So far, so good.
James Bryce Clark
jamie.clark@oasis-open.org
+1.978.667.5115