Ace104 Lecture 1

1
Ace104Lecture 1

• Introduction
• Distributed Architectures
• SOA Concepts

2
Traditional programming models
3
Distributed programming modelsClassic Web-based

• Easy to deploy but slow, not great user experience

Lacks full support of apps server --
no transactions, rpc, etc.
database
html browser
WebServer
http

• Many programming models
• JSP
• ASP
• Servlets
• PHP
• CGI (python, perl, C)
• Cold Fusion

Dynamically Generated html
html
plus optionally JavaScript to jazz up html
4
Distributed programming modelsTypical Web-based

• Better user experience. Heavier, less portable,
  requires socket programming to stream to server.

html
database
WebServer
http
applet
socket
Dynamically Generated html
html applet
5
Direct Connections

• Direct socket and rpc-style

App1
Application client
Remote Procedures
NDS
App2
App3
Examples Javas rmi, CORBA, DCOM
6
Application Servers
7
RPC-style Web service
8
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

9
Simple XML-based architecture
web browser
hand-rolled XML
WebServer
http
File system
python CGI
hand-rolled XML
XML
10
Motivating Example1

• Mortgage Calculator

11
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)

12
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

13
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

14
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 htmljavascript
• Server-side scripting with htmlapplet
• Direct connection
• Raw sockets
• Distributed objects

15
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/ace
  104/lesson1/examples/mortgage/

16
(No Transcript)
17
(No Transcript)
18
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

19
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?

20
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!

21
Lottery application
22
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.

23
Functional requirements, cont.

• Students are defined by
• Last name
• First name
• Seniority
• Quarters in the House
• Quarters in the College
• The sort keys are
• Quarters in House
• Quarters in College
• Random

24
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

25
Sketch of XML/Servlet solution
filesystem
XML Login Info
login
Web Server
Web Client
XML
XML Student Data
XSLT
lottery
26
Exercise 1
27
An exercise1 solution
Travel Service
Web Client
Internal Rules Engine
?
html
xml
Security manager
xml
http
html
Web Client
http
Complexity of marshaling/unmarshaling XML How to
represent state Ease of integration -- no
proprietary issues Ability to use Schema for
validation
28
SOA Concepts

• A Very Brief Introduction

29
Standards Organizations
30
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?

31
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.

32
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.

33
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

34
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
  business-level 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.

35
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
  enterprises (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

36
SOA the basics

• What it is.
• What it is not.

37
Real SOA

• Changed mindset service-oriented context for
  business logic.
• Changed automation logic service-oriented
  applications.
• Changed infrastructure service-oriented
  technologies.
• A top-down organization transformation requiring
  real commitment.

38
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.

39
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.

40
Potential Benefits

• Based on open standards.
• Supports vendor diversity.
• Fosters intrinsic interoperability.
• Promotes discovery.
• Promotes federation.
• Fosters inherent reusability.
• Emphasizes extensibility.

41
Potential Benefits

• Promotes organizational agility.
• Supports incremental implementation.
• Technical architecture that adheres to and
  supports the principles of service orientation.

42
Focus on the Business Process and Services
Application a
Application c
Application b
Application logic
Source Service-Oriented Architecture, Thomas Erl
43
Focus on the Business Process and Services
Business process layer
Business-oriented services
Services interface layer
Application-oriented services
Application layer
.NET
J2EE
Legacy
Source Service-Oriented Architecture, Thomas Erl
44
Focus on the Business Process and Services
Business process layer
Services interface layer
Application layer
.NET
J2EE
Legacy
Source Service-Oriented Architecture, Thomas Erl
45
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?

46
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

47
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

48
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

49
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).

50
Exercise 2
51
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

52
Quiz