Services-based Systems
Architecture, Design and
Implementation
B.Ramamurthy
3/16/2016
1
Goals
 “Retrospective” on Project 1

Lessons learned and pitfalls to avoid
 Discussion on plans for Project 2
 Artifacts of a large scale distributed system
 Architecting a services-based system
 Design issues in services-based system
 Anything else…
3/16/2016
2
Artifacts: the server/container
 Host with an IP (and ports)
 Web servers, servlet servers, application servers







3/16/2016
All can be bundled into one
More than one can be installed in a “host” machine at
different port (Project 1)
Each has a context root, the path of which represents “/” (Ex:
/DBaccess.jsp)
Each has an admin console for managing the server
resources such a data source and message queues.
Elegant way to access the resources in a deployed unit is
through the container (server).
For java, you will define JNDI (Java Naming and Directory
Interface) names for the resources.
Portability of deployable units (Ex: ‘Component technology’:
Enterprise Java beans)
3
Artifacts: the data
 Relational data base; object relational database
 Data modeling (Entity-Relationship modeling)
 Tables
 Operations
 Data access objects (DAO)
 Enterprise java beans (EJB)
 Enterprise information system (Amazon.com
webservices, yahoo feeds)
 Legacy systems
 Device data (sensors)
 RSS, ATOM, XML and text feeds
3/16/2016
4
Artifacts: the services
 WS creation for consumption:
 Typically create a service from language-dependent
interface/class (Ex: Java interface + class)
 Generate WSDL for publication and consumption.
 WS consumption using a published WSDL.
 Generate the language-dependent classes from WSDL
 Understand thoroughly the various components of
the WSDL: messages, port type, bindings, server
(server, port), etc.
3/16/2016
5
Artifacts: the clients
 Simple applications to rich client (ex: RIA rich
internet application)
 Internationalization (languages, monitory
units, etc.)
 HTTP monitors, cookies and counters
 Preference profiles
3/16/2016
6
Plan for Project 2



Commercial strength enterprise application built around web services
offered by amazon.com ECS:
http://webservices.amazon.com/AWSECommerceService/AWSECom
merceService.wsdl?
Theme: Federation of information from various sources to present an
intelligent interface for assembling a system of components in various
vertical domains.
Examples:

Mundane applications such as furnishing a house for a given
budget or without a budget but with preferences. Based on real
amazon.com data so that the application can be used by
amazon.com customers.

Building a home theater, a music system, stock portfolio, etc.

Interaction models (groups rather than individuals)

Add dynamism to amazon.com experience

Make use of web services you created in Project 1.

Data from other sources such as yahoo feeds.

3/16/2016For persistence you will have oracle data source, CIT data source as 7
well as any local data.
Plan for Project 2











Non-functional requirements:
Reliability (fault handling, exception handling)
Performance (caching, concurrency, thread pooling?)
Elegant data access using data access objects
Validation of any inputs
Junit/Nunit testing
Security authentication
Secure access
Asynchronous operation, push mode
Events, notification, publish, subscribe operations.
Higher level WS-* standards: WS-BPEL, workflow
etc.
3/16/2016
8
Project 2: to do
 We will explore the features offered by amazon.com







and others.
Decide on a project, title, domain, executive summary
and project timelines.
Lets look at some demos.
Links: Amazon.com E-Commerce Service (ECS)
Conceptual Model
ECS Usage/Query Scenarios
Types of data available through ECS (and not
available)
Sample applications (some of them are cool)
3/16/2016
9