Transcript Document

Ace104
Lecture 1
Introduction
Distributed Architectures
SOA Concepts
“Traditional”
programming models
Distributed programming models:
Classic Web-based
Easy to deploy but slow, not great user experience
Lacks full support
of apps server -- no
transactions, rpc, etc.
database
html
browser
http
html
plus optionally
JavaScript to
jazz up html
Web
Server
Dynamically
Generated
html
Many programming models
•JSP
•ASP
•Servlets
•PHP
•CGI (python, perl, C)
•Cold Fusion
Distributed programming models
Typical Web-based
Better user experience. Heavier, less portable, requires
socket programming to stream to server.
html
http
applet
socket
html + applet
Web
Server
Dynamically
Generated
html
database
Direct Connections
Direct socket and rpc-style
ports
App1
Application
client
App2
App3
Application
client
Remote Procedures
Examples: Java’s rmi, CORBA, DCOM
NDS
App1
App2
App3
Application Servers
RPC-style Web service
QuickTime™ and a
TIFF (Uncompressed) decompressor
are needed to see this picture.
General role of XML
Most modern languages have method of
representing structured data.
Typical flow of events in application
Read data
(file, db, socket)
Marshal
objects
Manipulate in
program
Unmarshal
(file, db, socket)
•Many language-specific technologies to reduce these steps: RMI, object
serialization in any language, CORBA (actually somewhat language neutral),
MPI, etc.
•XML provides a very appealing alternative that hits the sweet spot for
many applications
Simple XML-based architecture
http
Web
Server
File system “hand-rolled”
python CGI
web
browser
“hand-rolled”
XML
XML
XML
Motivating Example1
Mortgage Calculator
Example: mortgage calculator
Start very simple to motivate role of XML
All we need is a web server that supports
a server-side programming model
We will build up this example to include
first web service and then SOA concepts
(as we gain experience)
Functional requirements
Design a simple application which does the
following:

Accepts user input
Loan amount
Loan term
Interest rate
Extras (assessments + taxes)

Returns per-month table of
total payment
interest
principal
some other fun stuff
Design requirements
Must be





Clean simple interface (easy)
Remotely accessible with security
Portable to different machine architectures
Not require heavyweight or sophisticated
installation on the part of the user
Sufficiently fast not to be embarrassing given
10 hits/minute maximum usage
Some possible architectures
Things I tried

what are (dis) advantages of each?
Web server



Server-side scripting with pure (dynamic) html
Server-side scripting with html+javascript
Server-side scripting with html+applet
Direct connection


Raw sockets
Distributed objects
Initial choice
Front-end: html form
Back end: python cgi


Python generates web page dynamically after making
calculations
No use of higher-level web generation libraries at this point
What are advantages/disadvantages of this architecture?
Run application:

http://people.cs.uchicago.edu/~asiegel/courses/ace104/lesson1/examples/mortgage/
Disadvantages
Two obvious disadvantages are:


Formatted web content in print statements low-level,
ugly error prone
Data is not decoupled from formatting. What if we
want to switch to an application client? What if we
want to allow further processing by the client?
Several strategies can help with both of these
(higher-level htmlgen libraries, server-side
scripting model, beans, etc.) and XML
We will look at how XML fits in
Key Questions
What does browser do with XML?


Can it display?
Does it even understand XML?
If not, what good is this?
Do we have to hand roll our programming
language objects from XML?
Some answers
Regarding first point, try this with your web
browser


Note that XML is displayed/formatted nicely, but not
nearly to the same level of utility as the html table
To transform to html, we must associate a separate
.xsl file (e.g.) with the XML file. We will study XSL
soon.
Regarding XML-language conversion, we will
study language binding for various high-level
ways of doing this. For now, we will hand-roll
ourselves!
Lottery application
Functional requirements
Given a list of student members of a
dormitory, perform an ordered randomized
sort of the students to determine a room
draft order.
Functional requirements, cont.
Students are defined by



Last name
First name
Seniority
Quarters in the House
Quarters in the College
The sort keys are
1.
2.
3.
Quarters in House
Quarters in College
Random
Software requirements
Secure login


House name
Password
Remotely accessible to single small company

Several hits per hour maximum
All Windows Users
What I tried


Excel embedded in IE6
Web-based with java servlets, XML, XSLT
Sketch of XML/Servlet solution
filesystem
Web
Client
XML
XSLT
login
XML
Login
Info
lottery
XML
Student
Data
Web
Server
Exercise 1
An exercise1 solution
Travel Service
Web
Client
Web
Client
html
http
html
http
Internal
Rules
Engine
xml
Security
manager
Complexity of marshaling/unmarshaling XML
How to represent state
Ease of integration -- no proprietary issues
Ability to use Schema for validation
xml
?
SOA Concepts
A Very Brief Introduction
Standards Organizations
W3C (1994) OASIS (1998) WS-I (2002)
membership
400
600
200
Overall SOAspecific goals
To further the
evolution of
web via
standards that
improve info
sharing
To promote
online trade and
commerce via
specialized Web
services
standards
To foster
standardized
interoperability
using Web
services
standards
Prominent
SOA-specific
deliverables
XML, XML
Schema, Xquery,
XML Encryption,
XML Signature,
Xpath, XSLT,
WSDL, SOAP, WSCDL, WSAddressing
UDDI, ebXML,
SAML, XACML,
WS-BPEL, WSSecurity
Basic Profile,
Basic Security
Profile
This is all a work in progress
Reading too much gives the impression that these are
turnkey solutions.
In fact, remember that MANY of these standards are
very immature and are at various stages of
implementation by different vendors.
They also tend to change quickly in the early years. Be
very careful when applying to real problems!
Question: are open standards worthwhile? If so, who do
they benefit and how?
SOA Definitions
What is a SOA?

OASIS: “paradigm for organizing and utilizing
distributed capabilities that may be under the control
of different ownership domains. It provides a uniform
means to offer, discover, interact with and use
capabilities to produce desired effects consistent with
measurable preconditions and expectations.”
SOA definitions, cont.




Erl: “Contemporary SOA represents an open, agile, extensible,
federated, composable architecture comprised of autonomous,
QoS-capable, vendor diverse, interoperable, discoverable, and
potentially reusable services, implemented as Web services.
SOA can establish an abstraction of business logic and
technology, resulting in a loose coupling between these
domains.
SOA is an evolution of past platforms, preserving successful
characteristics of traditional architectures, and bringing with it
distinct principles that foster service-orientation in support of a
service-oriented enterprise.
SOA is ideally standardized throughout an enterprise, but
chieving this state requires a planned transition and the support
of a still evolving technology set.”
SOA Definitions, cont.
OMG : “Service Oriented Architecture is an architectural
style for a community of providers and consumers of
services to achieve mutual value, that:




Allows participants in the communities to work together with
minimal co-dependence or technology dependence
Specifies the contracts to which organizations, people and
technologies must adhere in order to participate in the
community
Provides for business value and business processes to be
realized by the community
Allows for a variety of technologies to be used to facilitate
interactions within the community”
SOA definitions, cont.
W3C: “A form of distributed systems architecture that is typically characterized by the
following properties:




Logical view: The service is an abstracted, logical view of actual programs, databases,
business processes, etc., defined in terms of what it does, typically carrying out a businesslevel operation.
Message orientation: The service is formally defined in terms of the messages exchanged
between provider agents and requester agents, and not the properties of the agents
themselves. The internal structure of an agent, including features such as its implementation
language, process structure and even database structure, are deliberately abstracted away
in the SOA: using the SOA discipline one does not and should not need to know how an
agent implementing a service is constructed. A key benefit of this concerns so-called legacy
systems. By avoiding any knowledge of the internal structure of an agent, one can
incorporate any software component or application that can be "wrapped" in message
handling code that allows it to adhere to the formal service definition.
Description orientation: A service is described by machine-processable meta data. The
description supports the public nature of the SOA: only those details that are exposed to the
public and important for the use of the service should be included in the description. The
semantics of a service should be documented, either directly or indirectly, by its description.
Granularity: Services tend to use a small number of operations with relatively large and
complex messages. Network orientation: Services tend to be oriented toward use over a
network, though this is not an absolute requirement. Platform neutral: Messages are sent in a
platform-neutral, standardized format delivered through the interfaces. XML is the most
obvious format that meets this constraint. “
SOA definition, cont.
Open Group: “An architectural style that supports service orientation …
Service orientation
A way of a way of thinking in terms of services and service based development and the outcomes
that services bring Service
A logical representation of a repeatable business activity that has a specified outcome (e.g., check
customer credit; provide weather data, consolidate drilling reports), is self-contained and maybe
composed of other Services. It is a black box to consumers of the Service Architectural Style
The combination of distinctive features in which Enterprise Architecture is done, or expressed The
SOA Architectural styleﾕs distinctive features: Based on the design of the services comprising an
enterprise’s (or inter-enterprise) business processes. Services mirror real-world business activity
Service representation utilizes business descriptions. Service representation requires providing its
context (including business process, goal, rule, policy, service interface and service component)
and service orchestration to implement service Has unique requirements on infrastructure.
Implementations are recommended to use open standards, realize interoperability and location
transparency. Implementations are environment specific, they are constrained or enabled by
context and must be described within their context. Requires strong governance of service
representation and implementation Requires a Litmus Test, which determined a good services”
SOA: the basics
What it is.
What it is not.
Real SOA
Changed mindset: service-oriented
context for business logic.
Changed automation logic: serviceoriented applications.
Changed infrastructure: service-oriented
technologies.
A top-down organization transformation
requiring real commitment.
SOA Characteristics
Loosely coupled: minimizes dependencies
between services.
Contractual: adhere to agreement on
service descriptions.
Autonomous: control the business logic
they encapsulate.
Abstract: hide the business logic from the
service consumers.
SOA Characteristics
Reusable: divide business logic into
reusable services.
Composable: facilitate the assembly of
composite services.
Stateless: minimize retained information
specific to an activity.
Discoverable: self-described so that they
can be found and assessed.
Potential Benefits
Based on open standards.
Supports vendor diversity.
Fosters intrinsic interoperability.
Promotes discovery.
Promotes federation.
Fosters inherent reusability.
Emphasizes extensibility.
Potential Benefits
Promotes organizational agility.
Supports incremental implementation.
Technical architecture that adheres to and
supports the principles of service
orientation.
Application
logic
Business
logic
Focus on the Business– Process
and Services
Application
a
Application
b
Application
c
Source: Service-Oriented Architecture, Thomas Erl
Business
process layer
Focus on the Business– Process
and Services
Services
interface layer
Business-oriented
services
Application
layer
Application-oriented
services
.NET
J2EE
Legacy
Source: Service-Oriented Architecture, Thomas Erl
Business
process layer
Focus on the Business– Process
and Services
Services
interface layer
orchestration service
layer
business service layer
Application
layer
application service layer
.NET
J2EE
Legacy
Source: Service-Oriented Architecture, Thomas Erl
SOA hype
Beware that SOA is used in many different ways within
the IT community (“most despised buzzword according
to several surveys”)
Erl-1 does a good job of sorting through a lot of this -should read ch. 1-3 carefully.
Still, many attributes ascribed to SOA are carryovers
from the “old days” -- encapsulation of business logic,
language interoperability, network transparency, loose
coupling, etc. etc. What is new?
BPEL
BPEL is a key part of the Web Services activities



BPEL 2.0 called WS-BPEL
BPEL is a programming language specialized for
creating/executing a workflow of assembled web
services (think driver language).
BPEL is built on top of a number of XML-related
specifications
XML is used as the syntax for BPEL
WSDL is used as the interface description of Web Services
XML Schema is used to describe the types used by BPEL
processes
XPath is used to extract parts of data in a BPEL process
SOA vs. Web services
SOA design concepts exist independently of web
services -- web services are one (and currently
the only) standard upon which SOA designs can
be built and deployed. This is a pretty uniformly
accepted view.
By the same token, using web services does not
necessarily imply SOA design
That said, in real world modern SOA the two
technologies are tightly linked and go hand in
hand
BPEL and BPMN
There is no standardized graphical
notation for BPEL





XML is used as the standardized syntax
the BPEL syntax is defined by an XML Schema
most BPEL tools provide graphical notations
different products use different notations
Business Process Modeling Notation (BPMN) has
been proposed as a graphical notation standard
Some perspective
Think about and try to articulate the relationship
between SOA and other common programming
models





Structured
OO
Component-based
Distributed
Client-server programming
Confluence of many existing ideas, but SOA is
definitely a shift in perspective (if not a radically
new paradigm).
Exercise 2
Organization of Book
Web Services and “Primitive SOA”



Services (as web services)
Service descriptions (WSDL)
Messaging (SOAP)
Web Services and “Contemporary SOA”


Part I: MEPs, service activity, atomicity, business activities,
orchestration, choreography
Part II: Advanced messaging, metadata, and security
We will roughly follow this ordering but precede it with a
deep understanding of XML, Schema …
This will be topic of next lecture
Quiz