Services Oriented
Infrastructure in a Web2.0
World
Tom Maguire
EMC Corporation

Abstract
The confluence of several mature architectural paradigms
with new user-centric paradigms will drive the next
generation of IT.
Next generation IT will be based on the combination of
model-driven architecture and service-oriented architecture
applied to applications, information delivery, and IT
resources alike.
The agility gained in IT infrastructure coupled with highly
configurable, lightweight, 'last mile' visualization
technologies will dramatically increase the relevance and
reactivity of IT to the business.

What You Should Gain
Ÿ Attendees will leave with an understanding of the benefits of
SOA, models, and Web 2.0 technologies and standards
with regard to IT infrastructure.
Ÿ Attendees will leave with a vision of how they can utilize
SOA, models, and Web 2.0 technologies.

Agenda
Ÿ Service Oriented Architecture
Ÿ Event Driven Architecture
Ÿ Web 2.0
Ÿ Potential IT Management Implications
Ÿ Conclusions

‡
“Form ever follows function”
Not the other way around…..
‡
Louis Henri Sullivan, Architect (September 3, 1856-April 14, 1924)

Service Oriented Architecture - SOA
SOA is an architectural style whose goal is to achieve loose coupling
among interacting components for the purposes of interoperability,
composition, and orchestration.
By loose coupling we mean:
The ability to add, modify, and delete components from the system with
minimal impact on other components.
SOA is not
Ÿ just about Web Services.
Ÿ a rehash of J2EE, CORBA, DCE.
Ÿ just another transport.
SOA is about HOW
– How to build composite distributed systems

Lest We Forget
The 8 fallacies when building distributed systems:
1. The network is reliable.
2. Latency is zero.
3. Bandwidth is infinite.
4. The network is secure.
5. Topology doesn’t change.
6. There is one administrator.
7. Transport cost is zero.
8. The network is homogenous.
Composite distributed systems built with SOA can fall into these traps but
there are mechanisms in SOA that help to avoid some of these pitfalls.
by Peter Deutsch, Sun Fellow

SOA: Core Principles
Ÿ Loose coupling
– Late binding
– Interface to implementation (as well)
Common interface
– Interface fidelity
§ The more precise the interface, the tighter the coupling
Ÿ Described interfaces Different
protocol bindings
– Decouple components
– Separation of concerns
Mediation
Ÿ Implementation agnostic
– Platform independent
Connectors/adapters
– Hidden implementation
Ÿ Message oriented
Native resources
– Well-defined messages
– Coarse grained
– Asynchrony
Ÿ Composition
– Behavior is the sum of all behaviors in the system
Ÿ Internet scale

So what is it really all about?
It is about the messages defined in the interface.
In SOA there are three distinct data models in every
interaction
1. The consumer-side implementation data model
2. The provider-side implementation data model
3. The message data model
The only data model of consequence in an SOA is the
message data model; this is the agreed upon (contract)
‘data model’ for the consumer and the provider.
All of the implementation data models are hidden.

SOA: Composition vs. Coding
• public String getEmployeeName(
long employeeID ) throws
javax.ejb.CreateException,
java.rmi.RemoteException
• { Connection conn = null;
PreparedStatement ps = null;
• try
•{ conn =
this.getConnection();
• ps =
vs conn.prepareStatement(\"select name
from employees_files where idnumber
= ?\"); ps.setLong(1, employeeID);
• ResultSet rs =
ps.executeQuery(); if (rs.next()) {
return rs.getString(1);
• } return \"Unknown\"; }
• catch (SQLException sqe) { return
sqe.getMessage(); } finally { if
(ps != null) { try { ps.close(); }
§ Metadata-driven configuration, composition, and business rules
Application
§ For application specialists (requirements experts) not developers
Composition § Apps composed from existing services built by developers

Web Services – An embodiment
Ÿ Messaging Ÿ Security
– Routing Addressing – Security Policy
– Multiple Message – Secure Conversation
Metadata
Transactions
Sessions
Security
Service State
– Trusted Message
– Events & – Federated Identity
Notification
– Reliable Messaging Ÿ Service State
– Message Packaging – Resource Transfer
Ÿ Transactions – Management
Ÿ Metadata
– Asynchronous
Services
– Policy
Messaging
– Transaction
– Publication &
– Orchestration Discovery
XML XML XML XML
– Base Service &
Message Description
– Metadata Exchange

Web Services Can be SOAP or REST
Ÿ SOAP – Simple Object Access Protocol
– Just SOAP, not Simple and not about Objects
– Provides an extensible format and processing model
§ Allows components to be decoupled from other components (e.g., infrastructure
components)
– Standards – Lots of them and still evolving
– Commercial-grade tools, big vendor support
Ÿ REST – Representational State Transfer
– HTTP, Uniform Resource Identifiers (URI), and XML
– Simple use of GET, PUT, POST, and DELETE
– Open tools, some resistance in commercial space

Event Driven Architecture - EDA
EDA is an architectural style whose goal is to achieve loose coupling
among interacting components through the production, detection,
consumption, and reaction to events.
By loose coupling we mean:
The ability to add, modify, and delete components from the system with
minimal impact on other components.
EDA is
Ÿ an asynchronous publish-and-subscribe model.
Ÿ great for a federated or autonomous processing environment.
Ÿ a declarative model; configuration not code.
EDA is about EVENTS as Messages

SOA and EDA Synergies
Ÿ SOA is about
– Loose coupling at the interface level.
– Contractual agreement on the messages.
– Decoupling implementation from interface.
Ÿ EDA is about
– Loose coupling at the messaging level through configured publisher
and subscriber connections via topics.
– Connecting messages (data models) together.
Ÿ EDA complements SOA by providing a rich asynchronous
messaging capability.
– Publish-subscribe interaction model is the inverse of request-reply.
Ÿ Both architectures focus on messages (data models) and
loose coupling.
– The formalization of the message data model creates opportunities.

What does this describe?

‡
Architecture of Participation – Web 2.0
Ÿ Systems that are designed explicitly for user contribution
Ÿ The current technology
– AJAX – Asynchronous JavaScript and XML
§ Also called Rich Internet Applications (RIA)
– RSS/Atom – published changes to information
§ Really Simple Syndication
§ Collectively called ‘feeds’
– Wikis – freeform collaborative authoring
§ User- or machine-contributed content
§ With history and syndication
– Blogs – user-generated content
§ With Trackbacks, permalinks, syndication
– Social tagging – public bookmarks
– Presence – realtime collaboration
‡
Tim O’Reilly, Warburg-Pincus’ annual technology conference, May, 2003

Characteristics of Web 2.0
Ÿ Unstructured
Ÿ Self-managed
Ÿ Folksnomies
Ÿ Freeform collaboration
Ÿ User-defined metadata
Ÿ In-system authoring

Wikis ‡
The simplest online database that could possibly work.
Ÿ Software that allows users to freely create and edit content
using any browser
– A collaborative website
– “Open editing” but easy to correct mistakes
– Recent changes can be monitored actively or passively
Ÿ At last count there were at least 80 implementations of Wiki
Ÿ Provides communities and categorization
Ÿ Freeform data model with tagging
‡
Ward Cunningham, Inventor of Wiki

Blogs
User-generated content, in a journal style
Ÿ Software that allows individuals to freely create and edit
content using any browser
– An “open mic”
Ÿ Trackbacks, blogrolls, and aggregators create an
understanding of experts
Ÿ Freeform data model with tagging
Ÿ Tagging provides the context for understanding area of
expertise

AJAX
Asynchronous JavaScript and XML. Not a technology, a
technique for creating highly interactive web pages utilizing a
number of technologies.
Ÿ AJAX utilizes
– Standards-based presentation (XHTML & CSS)
– Dynamic display manipulation using DOM (Document Object Model)
– Data model interchange and manipulation using XML & XSLT
– Asynchronous data retrieval using XMLHttpRequest
– JavaScript to glue it all together
Ÿ To create RIA (Rich Internet Applications)
– Web pages that feel more responsive
– That only exchange small amounts of data behind the scenes
– That do not have to be reloaded
– Which improves interactivity, speed, and (hopefully) usability

AJAX – The “Global SOA”?
Ÿ AJAX is the natural service consumer
Ÿ AJAX allows users to interact dynamically with SOA-type
services and their data models:
– SOAP
– REST
– RSS
– ATOM
– XML
– SQL

The Match
?
Rich Internet
Data
Applications
?
SOA
User Interface

Mashups
The combination of content from more than one source
into an integrated experience
Ÿ This is really about content repurposing and reuse
Information and presentation are being separated in
‡
ways that allow for novel forms of reuse
Ÿ Both SOA and Mashups are compositional models
– SOA: think corporate, consultants, big budget…
– Mashups: just the opposite
Ÿ But that is changing….
‡
Sho Kuwamoto, Adobe, Engineering, http://weblogs.macromedia.com/sho/archives/2005/08/web_20_rias_aja.cfm

Impact to IT Management

What if….
Ÿ you had access to all of the certified configuration
information and could easily associate that with your
infrastructure?
Ÿ you could tap into a community that maintained content on
events and alerts that they have seen in their
infrastructures?
Ÿ you had access to a huge community of experts on a wide
range of infrastructure topics?
Ÿ health, faults, and alerts were delivered to you anywhere
you would like with RSS?
Ÿ a chronological log of information of all changes in the
infrastructure was available anywhere?
Ÿ patches and software updates were delivered to you
asynchronously as they became available?
Ÿ the interface to resources mimicked a Wiki-style interaction?

Monolithic Products
Business Process Manual Processes and Workflows
Service Level Mgmt Manual Processes and Workflows
Service Invocation Manual Processes and Workflows
Functional Components NetWorker Replicat’n Disk Email
Manager Xtender Xtender
Resource Managers
Resources

Decomposed into Service Oriented Infrastructure
Content Mgmt Bus. Intelligence Collaboration Business Apps
Business Process Manual Processes and Workflows
SLOs / SLAs
Service Level Mgmt Manual Processes and Workflows
Security Performance Availability Compliance
Web Services
Service Invocation Manual Processes and Workflows
Functional Components Backup Replication Archiving Data
Movement
Resource Managers
Resources

Conclusions & Recommendations
Ü Embark on the path to Service Orientation
² Create well-defined interfaces and message models
² Use Web 2.0 technologies to “mashup” enterprise data models with Internet data
models
² Avoid tight coupling to implementation, interaction model, and data models
Ü Encourage the use of new collaboration tools
² Establish communities for disciplines of interest
² Encourage internal experts to share knowledge through Wikis and blogs
² Harvest those data models and experts through mashups and realtime collaboration
Ü Watch out for accidental architectures
² Command-and-control models (request-reply, point-to-point messaging)
² Fine-grained interactions
² Data model linkages

Backup slides

On Information Model and Data Models
From RFC3444[i]:
The main purpose of an IM is to model managed objects at a conceptual level,
independent of any specific implementations or protocols used to transport the
data. The degree of specificity (or detail) of the abstractions defined in the IM
depends on the modeling needs of its designers. In order to make the overall
design as clear as possible, an IM should hide all protocol and implementation
details. Another important characteristic of an IM is that it defines relationships
between managed objects.
DMs, conversely, are defined at a lower level of abstraction and include many
details. They are intended for implementers and include protocol-specific
constructs.
Stated another way:
The IM includes abstract entities and their relationships to one another as well
as operations that can be driven on those entities.
The DM deals with the implementation details or protocol details, of the IM. For
example, implementation object models and protocol/message formats.
[i] “On the Difference Between Information Models and Data Models”, http://www.ietf.org/rfc/rfc3444.txt