Download SW Arch - University of Connecticut

CSE
CSE
2102
2102
Software and Enterprise Architectures
Prof. Steven A. Demurjian, Sr.
Computer Science & Engineering Department
The University of Connecticut
371 Fairfield Road, Box U-255
Storrs, CT 06269-2155
[email protected]
http://www.engr.uconn.edu/~steve
(860) 486 - 4818
Copyright © 2008 by S. Demurjian, Storrs, CT.
1
Software Architectures
CSE
2102







Emerging Discipline in Mid-1990s
Software as Collection of Interacting Components
What are Local Interactions (within Component)?
What are Global Interactions (between Components)?
Advantages of SW Architectural Design
 Understand Communication/Synchronization
 Definition of Database Requirements
 Identification of Performance/Scaling Issues
 Detailing of Security Needs and Constraints
Towards Large-Scale Software Development
For Biomedical Informatics:
 What are Architectures for Data Sharing?
 How is Interoperability Facilitated?
2
Concepts of Software Architectures
CSE
2102







Exceed Traditional Algorithm/Data Structure
Perspective
Emphasize Componentwise Organization and System
Functionality
Focus on Global and Local Interactions
Identify Communication/Synchronization
Requirements
Define Database Needs and Dependencies
Consider Performance/Scaling Issues
Understand Potential Evolution Dimensions
3
The HTSS Software Architecture
CSE
CSE
2102
2102
IL
IL
IL
SDO
EDO
SDO
EDO
Payment
CR
CR
CR
IL:
CR:
IC:
DO:
CR
Item
IC
Order
IC
Item Locator
Cash Register
Inventory
Invent. Control
Control
Deli Orderer for
Shopper/Employee
ItemDB
Global
Server
ItemDB
Local
Server
Non-Local
Client Int.
CreditCardDB
ATM-BanKDB
OrderDB
SupplierDB
4
Multiple Backend Database System (MBDS)
CSE
CSE
2102
2102
Backend
Database
Processor
Database
Controller
Backend
Database
Processor
Host/User
Backend
Database
Processor
5
The MBDS Processes
CSE
2102
Database
Controller
Request
Preparation
Post
Processing
Put Msg.
Get Msg.
Get Msg.
Put Msg.
Directory
Management
Record
Processing
Concurrency
Control
Disk I/O
Backend
Database
Processor
6
Multiple Processes in MBDS
CSE
2102
No.
1
2
3
4
6
12
15
16
21
22
23
Type
New Request
Results of Request
Number of Reqs in Transaction
Aggregate Operators (Sum, etc.)
Parsed Request to Backends
Backend Aggregate Operator Results
Ids for Accessing Database Indexes
Request and Disk Addresses
Ids for Accessing Database Records
Locks Obtained: Okay to Execute
Request ID of Finished Request
SRC
Host
PoPr
ReqP
ReqP
ReqP
RecP
DM
DM
DM
CC
RecP
DST
ReqP
Host
PoPr
PoPr
DM
PoPr
DMs
RecP
CC
RecP
CC
7
Message Passing in MBDS
CSE
2102
A1
F15 From
Other
Backend
Request
Preparation
D6
Put Msg.
B3
C4
K12
Post
Processing
K12
Get Msg.
E15 To Backend(s)
Get Msg.
Put Msg.
D6,F15
E15
Directory
Management
G21
K12
H22
Record
Processing
I16
Concurrency
Control
J23
Disk I/O
8
Software Design Levels
CSE
2102




Architecturally:
 Modules
 Interconnections Among Modules
 Decomposition into Subsystems
Code:
 Algorithms/Data Structures
 Tasking/Control Threads
Executable:
 Memory Management
 Runtime Environment
Is this a Realistic/Accurate View?
 Yes for a Single “Application”
 What about Application of Applications?
 System of Systems?
9
Software Engineering - an Oxymoron?
CSE
2102





Is there any Engineering?
Is there any Science?
Collection of Disparate Techniques:
 Data-Flow Diagrams
 E-R Diagrams
 Finite State Machines
 Petri Nets
 UML Class, Object, Sequence, Etc.
 Design Patterns
 Model Drive Architectures
What is being “Engineered”?
How do we Know we are Done?
 E.g. Does Artifact Match Specification?
10
What's Available for Engineering Software?
CSE
2102







Specification (Abstract Models, Algebraic Semantics)
Software Structure (Bundling Representation with
Algorithms)
Languages Issues (Models, Scope, User-Defined
Types)
Information Hiding (Protect Integrity of Information)
Integrity Constraints (Invariants of Data Structures)
Is this up to date?
What else can be Added to List?
 Design Patters
 Model Driven Architectures
 XML –Data Modeling and Dependencies
 Others?
11
Engineering Success in Computing
CSE
2102



Compilers Have Had Great Success
 Originally by Hand
 Then Compiler Compilers
 Parser Generators - Lex/Yacc
Solid Science Behind Compilers
 Regular, Context Free, Context Sensitive
Languages
 FSAs, PDAs, CFGs, etc.
Science has Provided Engineering Success re. Ease
and Accuracy of Modern Compiler Writing
12
History of Programming
CSE
2102



C - Still Remains Industry Stronghorse
 Separate Compilation
 Decomposition of System into Subsystems, etc.
 Shared Declarations
 ADTs in C, But Compiler won't Enforce Them
Modula-II and Ada 83 Had
 Information Hiding
 Public/Private Paradigm
 Module/Package Concepts
 Import/Export Paradigm
Rigor Enforced by Compiler – but Can’t
 Bind/Group Modules into Subsystems
 Precisely Specify Interconnections and Interactions
Among Subsystems and Components
13
‘Recent-Past’ Generation?
CSE
2102



C++ and Ada95
 Considered “Legacy” Languages - Old
Java, C# - Are they Headed Toward Legacy?
 How do they Rate?
 What Do they Offer that Hasn't been Offered
Before?
 What are Unique Benefits and Potential of Java?
What about new Web Technologies?
 Javascript, Perl, PhP, Phython, Ruby
 XML and SOAP
 How do all of these fit into this process?
 Particularly in Regards to C/S Solutions!
14
What's Next Step?
CSE
2102






Architectural Description Languages
 Provide Tools to Describe Architectures
 Definition and Communication
Codification of Architectural Expertise
Frameworks for Specific Domains
DB vs. GUI vs. Embedded vs. C/S
Formal Underpinning for Engineering Rigor
What has Appeared for Each of these?
 Struts for GUI
 Open Source Frameworks (mediawiki)
 Wide-Ranging Standards (XML)
 Model-Driven Architectures
 What Else???
15
Architectural Styles
CSE
2102




What are Popular Architectural Styles?
 How are they Characterized?
 Example in Practice
Explore a Taxonomy of Styles
Focus on “Micro-Architectures”
 Components
 Flow Among Components
 Represents “Single” Application
Forms Basis for “Macro-Architectures”
 System of Systems
 Application of Applications
 Significantly Scaling Up
16
Taxonomy of Architectural Styles
CSE
2102




Data Flow Systems
 Batch Sequential
 Pipes and Filters
Call & Return Systems

 Main/Subroutines
(C, Pascal)
 Object Oriented
 Implicit Invocation
 Hierarchical Systems

Virtual Machines
 Interpreters
 Rule Based Systems
Data Centered Systems
 DBS
 Hypertext
 Blackboards
Independent
Components
 Communicating
Processes/Event
Systems
Client/Server
 Two-Tier
 Multi-Tier
17
Taxonomy of Architectural Styles
CSE
2102

Establish Framework of …
 Components
 Building Blocks for Constructing Systems
 A Major Unit of Functionality
 Examples Include: Client, Server, Filter, Layer, DB

Connectors
 Defining the Ways that Components Interact
 What are the Protocols that Mandate the Allowable
Interactions Among Components?
 How are Protocols Enforced at Run/Design Time?
 Examples Include: Procedure Call, Event Broadcast,
DB Protocol, Pipe
18
Overall Framework
CSE
2102







What Is the Design Vocabulary?
 Connectors and Components
What Are Allowable Structural Patterns?
 Constraints on Combining Components &
Connectors
What Is the Underlying Conceptual Model?
 Von Newman, Parallel, Agent, Message-Passing…
 Are their New Emerging Models?
 Collaborative Environments/Shareware?
What Are Essential Invariants of a Style?
 Limits on Allowable Components & Connectors
Common Examples of Usage
Advantages and Disadvantages of a Style
Common Specializations of a Style
19
Pipes and Filters
CSE
2102
Components are Independent
Entities. No Shared State!
Components with
Input and Output
Sort
Sort
Merge
Connectors for Flow Streams of I/O

Filters:
 Invariant: Unaware of up and Down Stream
Behavior
 Streamed Behavior: Output Could Go From
One Filter to the Next One Allowing Multiple
Filters to Run in Parallel.
20
Pipes and Filters
CSE
2102



Possible Specializations:
 Pipelines - Linear Sequence
 Bounded - Limits on Data Amounts
 Typed Pipes - Known Data Format
What is a Classic Example?
Other Examples:
 Compilers
 Sequential Processes
 Parallel Processes
21
Pipes and Filters - Another Example
CSE
2102



Text Information Retrieval Systems
 Scanning Newspapers for Key Words, Etc.
 Also, Boolean Search Expressions
Where is Such an Architecture Utilized Today?
What is Potential Usage in BMI?
Search
Controller
User
Commands
Disk
Controller
Control
Programming
Result
Query
Resolver
Term
Comparator
Search
Data DB
22
ADTs and OO Architectures
CSE
2102


Widespread Usage in the 1990’s
Advantages Are Well Known
op
Components
obj
op
Connectors
op
obj
obj
op
op
op
obj
op
obj
op
op
op
obj
op
op
op
obj
obj

Disadvantages:
 Interaction Required Object Identity
 If Identity Changes, It Is Difficult to Track All
Affected Objects.
23
Implicit Invocation
CSE
2102



Similar to OO in the Sense that Components Can Call
Services on Other Components
How Does this Work?
 Components Have List of Events they can Raise
and List of Procedures to Handle Events
 When Event is Raised, it is Broadcast
 All Components that Have Procedure to Handle
Broadcast Event will Act Upon it
 The Component That Raised the Event has no
Knowledge of Which Component(s) will Handle
Event
What are Some Examples?
24
Implicit Invocation
CSE
2102


Advantages
 No Need to Know the Targeted Components
 Single Event can Impact Multiple Components
 New Event Handlers can Easily be Added
 New Events Can then be Raised
Disadvantages
 No Control Over the Order of Processing When an
Event is Raised
 No Control Over “Who” and “How Many” Process
Events
 Very Non-Deterministic System Behavior
25
What has OO Evolved Into?
CSE
2102


What has Classic OO Solution Evolved into Today?
 Client (Browser + Struts)
 Server (Many Variants of OO Languages)
 Database Server (typically Relational)
Different Style (e.g., Design Pattern)
 Does Pattern Capture All Aspects of Style?
 Do we Need to Couple Technology with Pattern?
Dr. D, Jan 01, 08
Fever, Flu, Bed Rest
No Scripts
No Tests
Item(Phy_Name*, Date*,
Visit_Flag, Symptom, Diagnosis, Treatment,
Presc_Flag, Pre_No, Pharm_Name, Medication,
Test_Flag, Test_Code, Spec_No, Status, Tech)
26
Layered Systems
CSE
2102
Useful Systems
Base Utility
Core
level
Users



Components - Virtual Machine at Each Layer
Connectors - Protocols That Specify How Layers
Interact
Interaction Is Restricted to Adjacent Layers
27
Layered Systems
CSE
2102


Advantages:
 Increasing Levels of Abstraction
 Support Enhancement - New Layers
 Support for Reuse
Drawbacks:
 Not Feasible for All Systems
 Performance Issues With Multiple Layers
 Defining Abstractions Is Difficult.
28
Layered Systems in BMI
CSE
2102


One Approach to Constructing Access to Patient Data
for Clinical Research and Clinical Practice
Construct Layered Data Repositories as Below
 Each Layer Targets Different User Group
 Need to Fine Tune Access Even within Layers
Aggregated
De-identified
Patient
Data
Provider
Cl. Researchers
Public Health Researchers
29
ISO as Layered Architecture
CSE
2102

ISO Open Systems Interconnect (OSI) Model
 Now Widely Used as a Reference Architecture
 7-layer Model
 Provides Framework for Specific Protocols (Such
as IP, TCP, FTP, RPC, UDP, RSVP, …)
Application
Presentation
Session
Transport
Network
Data Link
Physical
Application
Presentation
Session
Transport
Network
Data Link
Physical
30
ISO OSI Model
CSE
CSE
2102
2102
Application
Presentation
Session
Transport
Network
Data Link
Physical
Application
Presentation
Session
Transport
Network
Data Link
Physical

Physical (Hardware)/Data Link Layer Networks:
Ethernet, Token Ring, ATM
Network Layer Net: The Internet

Transport Layer Net: Tcp-based Network

Presentation/Session Layer Net: Http/html, RPC,
PVM, MPI
Applications, E.g., WWW, Window System,
Algorithm


31
Repositories
CSE
2102
ks8
ks1
Blackboard
(shared data)
ks2
ks3
ks6
ks4




ks7
ks5
Knowledge Sources Interact With the Blackboard.
Blackboard Contains the Problem Solving State Data.
Control Is Driven by the State of the Blackboard.
DB Systems Are a Form of Repository With a Layer
Between the BB and the KSs - Supports
 Concurrent Access, Security, Integrity, Recovery
32
Database System as a Repository
CSE
2102
c8
c1
Database
(shared data)
c2
c3
c6
c4



c7
c5
Clients Interact With the DBMS
Database Contains the Problem Solving State Data
Control is Driven by the State of the Database
 Concurrent Access, Security, Integrity, Recovery
 Single Layer System: Clients have Direct Access
 Control of Access to Information must be
Carefully Defined within DB Security/Integrity
33
Team Project as a Repository
CSE
2102
c8
c1
Web Portal
Shared
c2
c3
c6
c4



c7
c5
Clients are Providers, Patients, Clinical Researchers
Database Underlies Web Portal
Simply a Portion of Architecture
 Interactions with PHR (Patients)
 Interactions with EMR (Providers)
 Interactions with Database/Warehouse (Researchers)
34
Interpreters
CSE
2102
Inputs
Outputs


Program being
interpreted
Data
(program state)
Simulated
interpretation
engine
Selected
instruction
Selected
data
Internal
interpreter
state
What Are Components and Connectors?
Where Have Interpreters Been Used in CS&E?
 LISP, ML, Java, Other Languages, OS
Command Line
35
Java as Interpreter
CSE
CSE
2102
2102
36
Process Control Paradigms
CSE
2102
Input variables
Set
point
Ds to
manipulated
variables
Controller
Input variables
Set
point

Controller
Ds to
manipulated
variables
With Feedback
Process
Controlled
variable
Without Feedback
Process
Controlled
variable
Also:
 Open vs. Close Loop Systems
 Well Defined Control and Computational
Characters
 Heavily Used in Engineering Fields.
37
Process Architecture: Statechart Diagram?
CSE
CSE
2102
2102
38
Process Architecture: Activity Diagram?
CSE
CSE
2102
2102

Clear Applicability to Medical Processes that have
Underlying BMI – Low Level Processes
Waiting for
Heart Signal
timeout
irregular beat
Heartbeat
Heart Signal
Waiting for
Resp. Signal
Breath
Trigger
Local
Alarm
Trigger
Remote
Alarm
Resp Signal
Alarm Reset
39
Design Patterns as Software Architectures
CSE
2102




Emerged as the Recognition that in Object-Oriented
Systems Repetitions in Design Occurred
Gained Prominence in 1995 with Publication of
“Design Patterns: Elements of Reusable ObjectOriented Software”, Addison-Wesley
 “… descriptions of communicating objects and
classes that are customized to solve a general
design problem in a particular context…”
 Akin to Complicated Generic
Usage of Patterns Requires
 Consistent Format and Abstraction
 Common Vocabulary and Descriptions
Simple to Complex Patterns – Wide Range
40
The Observer Pattern
CSE
2102



Utilized to Define a One-to-Many Relationship
Between Objects
When Object Changes State – all Dependents are
Notified and Automatically Updated
Loosely Coupled Objects
 When one Object (Subject – an Active Object)
Changes State than Multiple Objects (Observers –
Passive Objects) Notified
 Observer Object Implements Interface to Specify
the Way that Changes are to Occur
 Two Interfaces and Two Concrete Classes
41
The Observer Pattern
CSE
CSE
2102
2102
42
Model View Controller
CSE
2102

http://java.sun.com/blueprints/patterns/MVC-detailed.html
43
Model View Controller
CSE
2102

Three Parts of the Pattern:
 Model
 Enterprise Data and Business Rules for Accessing and
Updating Data

View
 Renders the Contents (or Portion) of Model
 Deals with Presentation of Stored Data
 Pull or Push Model Possible

Controller
 Translates Interactions with View into Actions on
Model
 Actions could be Button Clicks (GUI), Get/Post http
(Web), etc.
44
Model View Controller
CSE
2102

http://java.sun.com/blueprints/patterns/MVC-detailed.html
45
UML for System Modeling
CSE
2102




UML is a Language for Specifying, Visualizing,
Constructing, and Documenting Software Artifacts
What Does a Modeling Language Provide?
 Model Elements: Concepts and Semantics
 Notation: Visual Rendering of Model Elements
 Guidelines: Hints and Suggestions for Using
Elements in Notation
References and Resources
 Web: http://www.uml.org/
Is UML Sufficient for Complexity of BMI?
 Able to Model Information Needs for BMI?
 Able to Represent Required Architectures?
46
UML
CSE
2102


UML is a Set of Graphical Specification Languages
(OMG’s Standard Design Language Since November,
1997)
Implementation Diagrams
 Component Diagrams:
 Show the Physical Structure of the Code in Terms of
Code Components and Their Dependencies

Deployment Diagrams:
 Show the Physical Architecture of the Hardware and
Software in the System.
 They Have a Type and an Instance Version.
47
UML
CSE
2102


When to Use Deployment Diagrams
“… In practice, I haven’t seen this kind of diagram
used much. Most people do draw diagrams to show
this kind of information but they are informal
cartoons. On the whole, I don’t have a problem with
that since each system has its own physical
characteristics that your want to emphasize. As we
wrestle more and more with distributed systems,
however, I’m sure we will require more formality as
we understand better which issues need to be
highlighted in deployment diagrams.”
 From “UML Distilled. Applying the Standard
Object Modeling Language”, by Martin Fowler.
Addison-Wesley, Object Technology Series, 7th.
Reprint June, 1998.
48
Pros and Cons of Graphical Modeling
CSE
CSE
2102
2102

Advantages:



Clear to Show
Structure
Excellent
Communication
Vehicle
Addresses Different
Aspects of
Modeling in an
Integrated Fashion

Disadvantages:



Shows Little (or No)
Details
There is a Big Gap
Between Specification
and Implementation
Limited by Screen
Size & Printable Page
Solution: Associate a Complete Textual
Specification to Graphical Model that Contains
the Necessary Details for Each Element

49
Design Concepts
CSE
2102







Interface Interaction With the Outer World
Signature + Requested Services
Type: Abstract Entity - Interface + Semantics
Subtype: Inherits the Supertype Definition
Class: Implementation of a Type
Realization: Relation Between a Type and a Class
That Implements It
Subclass: Inherits the Superclass Implementation
Instance: Element of a Class
50
UML Diagrammatic Representations
CSE
2102





Component Diagram: Captures the Physical Structure
of the Implementation
Deployment Diagram: Captures the Topology of a
System’s Hardware
Collaboration Diagram: Captures Dynamic Behavior
(Message-Oriented)
What About Other Diagrams?
 State Chart Diagram: Captures Dynamic Behavior
(Event-Oriented)
 Activity Diagram: Captures Dynamic Behavior
(Activity-Oriented)
These and Others Seem too Low Level …
What is Role of UML for BMI?
 Yet Another Design Artifact
 Can it be More?
51
Component Diagram
CSE
2102

Captures the Physical Structure of the Implementation
52
Deployment Diagram
CSE
2102

Captures the Topology of a System’s Hardware
53
Collaboration Diagram
CSE
CSE
2102
2102
54
Single and Multi-Tier Architectures
CSE
2102


Widespread use in Practice for All Types of
Distributed Systems and Applications
Two Kinds of Components
 Servers: Provide Services - May be Unaware of
Clients
 Web Servers (unaware?)
 Database Servers and Functional Servers (aware?)

Clients: Request Services from Servers
 Must Identify Servers
 May Need to Identify Self
 A Server Can be Client of Another Server

Expanding from Micro-Architectures (Single
Computer/One Application) to Macro-Architecture
55
Single and Multi-Tier Architectures
CSE
2102





Normally, Clients and Servers are Independent
Processes Running in Parallel
Connectors Provide Means for Service Requests and
Answers to be Passes Among Clients/Servers
Connectors May be RPC, RMI, etc.
Advantages
 Parallelism, Independence
 Separation of Concerns, Abstraction
 Others?
Disadvantages
 Complex Implementation Mechanisms
 Scalability, Correctness, Real-Time Limits
 Others?
56
Example: Software Architectural Structure
CSE
CSE
2102
2102
Initial Data
Entry Operator
(Scanning & Posting)
Advanced Data
Entry
Operators
Analyst
Manager
10-100MB Network
Document
Server
Stored
Images/CD
Database
Server
Running
Oracle
RMI Registry
RMI Act.
Obj/Server
RMI Act.
Obj/Server
Functional Server
57
Business Process Model
CSE
CSE
2102
2102
DB
DB
Historical Completed
Records Applications
Licensing
DB
Supervisor
Review
Scanner
DB
Licensing
Division
Scanning
Operator
Stored
Images
Licensing Division Printer
Data Entry Operator
DB
Basic
Information
Entered
New Licenses
New Appointments
FOI
Letters (Request
Information, etc.)
58
Two-Tier Architecture
CSE
2102





Small Manufacturer Previously on C++
New Order Entry, Inventory, and Invoicing
Applications in Java Programming Language
Existing Customer and Order Database
Most of Business Logic in Stored Procedures
Tool-generated GUI Forms for Java Objects
59
Three-Tier Architecture
CSE
2102






Passenger Check-in for Regional Airline
Local Database for Seating on Today's Flights
Clients Invoke EJBs at Local Site Through RMI
EJBs Update Database and Queue Updates
JMS Queues Updates to Legacy System
DBC API Used to Access Local Database
60
Four-Tier Architecture
CSE
2102





Web Access to Brokerage Accounts
Only HTML Browser Required on Front End
"Brokerbean" EJB Provides Business Logic
Login, Query, Trade Servlets Call Brokerbean
Use JNDI to Find EJBs, RMI to Invoke Them
61
Architecture Comparisons
CSE
2102





Two-tier Through JDBC API is Simplest
Multi-tier: Separate Business Logic, Protect Database
Integrity, More Scaleable
JMS Queues vs. Synchronous (RMI or IDL):
 Availability, Response Time, Decoupling
JMS Publish & Subscribe: Off-line Notification RMI
IIOP vs. JRMP vs. Java IDL:
 Standard Cross-language Calls or Full Java
Functionality
JTS: Distributed Integrity, Lockstep Actions
62
Comments on Architectural Styles
CSE
2102




Architectural Styles Provide Patterns
 Suppose Designing a New System
 During Requirements Discovery, Behavior and
Structure of System Will Emerge
 Attempt to Match to Architectural Style
 Modify, Extend Style as Needed
By Choosing Existing Architectural Style
 Know Advantages and Disadvantages
 Ability to Focus in on Problem Areas and
Bottlenecks
 Can Adjust Architecture Accordingly
Architectures Range from Large Scale to Small Scale
in their Applicability
We’ll see Examples for BMI Shortly …
63
The Next Big Challenge
CSE
2102


Macro-Architectures
 System of Systems
 Application of Applications
Involves Two Key Issues
 Interoperability
 Heterogeneous Distributed Databases
 Heterogeneous Distributed Systems
 Autonomous Applications

Scalability




Rapid and Continuous Growth
Amount of Data
Variety of Data Types
Different Privacy Levels or Ownerships of Data
64
Interoperability: A Classic View
CSE
CSE
2102
2102
Local
Schema
Simple Federation
Multiple Nested Federation
FDB Global
Schema
FDB Global
Schema 4
Federated
Integration
Federated
Integration
Local
Schema
Local
Schema
FDB 1
Local
Schema
Federation
FDB3
Federation
65
What is CORBA?
CSE
2102


Differs from Typical Programming Languages
Objects can be …
 Located Throughout Network
 Interoperate with Objects on other Platforms
 Written in Ant PLs for which there is mapping
from IDL to that Language
Application
Interfaces
Domain Interfaces
Object Request Broker
Object Services
66
What is CORBA?
CSE
2102


Allow Interactions from Client to Server CORBA
Installed on All Participating Machines
Client Application
Static
Stub
DII
Server Application
ORB
Interface
ORB
Interface
Skel
eton
DSI
Object Adapter
Client ORB Core
Network
IDL - Independent
Same for all
applications
Server ORB Core
There may be multiple
object adapters
67
CORBA-Based Development
CSE
CSE
2102
2102
IDL file
Client
Application
IDL Compiler
Stub
ORB/IIOP
Object
Implementation
IDL Compiler
Skeleton
ORB/IIOP
68
Database Interoperability in the Internet
CSE
2102


Technology
 Web/HTTP, JDBC/ODBC, CORBA (ORBs +
IIOP), XML
Architecture
Information Broker
•Mediator-Based Systems
•Agent-Based Systems
69
ORB Integration:Java Client + Legacy Application
CSE
CSE
2102
2102
Java Client
Legacy
Application
Java
Wrapper
Object Request Broker (ORB)
CORBA is the Medium of Info. Exchange
Requires Java/CORBA Capabilities
70
Java Client with Wrapper to Legacy Application
CSE
CSE
2102
2102
Java Client
Java Application Code
WRAPPER
Mapping Classes
JAVA LAYER
Interactions Between Java Client
and Legacy Appl. via C and RPC
C is the Medium of Info. Exchange
Java Client with C++/C Wrapper
NATIVE LAYER
Native Functions (C++)
RPC Client Stubs (C)
Legacy
Application
Network
71
COTS and Legacy Appls. to Java Clients
CSE
CSE
2102
2102
COTS Application
Java Application Code
Legacy Application
Java Application Code
Native Functions that
Map to COTS Appl
NATIVE LAYER
Native Functions that
Map to Legacy Appl
NATIVE LAYER
JAVA LAYER
JAVA LAYER
Mapping Classes
JAVA NETWORK WRAPPER
Mapping Classes
JAVA NETWORK WRAPPER
Network
Java Client
Java Client
Java is Medium of Info. Exchange - C/C++ Appls with Java Wrappers
72
Java Client to Legacy App via RDBS
CSE
CSE
2102
2102
Transformed
Legacy Data
Java Client
Updated Data
Relational
Database
System(RDS)
Extract and
Generate Data
Transform and
Store Data
Legacy
Application
73
JDBC
CSE
2102


JDBC API Provides DB Access Protocols for Open,
Query, Close, etc.
Different Drivers for Different DB Platforms
JDBC API
Java
Application
Driver Manager
Driver
Oracle
Driver
Access
Driver
Driver
Sybase
74
Connecting a DB to the Web
CSE
CSE
2102
2102

DBMS

CGI Script Invocation
or JDBC Invocation
Web Server

Web Server are
Stateless
DB Interactions Tend
to be Stateful
Invoking a CGI
Script on Each DB
Interaction is Very
Expensive, Mainly
Due to the Cost of
DB Open
Internet
Browser
75
Connecting More Efficiently
CSE
CSE
2102
2102

DBMS
Helper
Processes
CGI Script
or JDBC
Invocation

Web Server
Internet

To Avoid Cost of
Opening Database, One
can Use Helper
Processes that Always
Keep Database Open
and Outlive Web
Connection
Newly Invoked CGI
Scripts Connect to a
Preexisting Helper
Process
System is Still Stateless
Browser
76
DB-Internet Architecture
CSE
CSE
2102
2102
WWW Client
(Netscape)
WWW client
(Info. Explore)
WWW Client
(HotJava)
Internet
HTTP Server
DBWeb Gateway
DBWeb Gateway
DBWeb Gateway
DBWeb
Dispatcher
DBWeb Gateway
77
Internet and the Web
CSE
2102

A Major Opportunity for Business
 A Global Marketplace
 Business Across State and Country Boundaries

A Way of Extending Services
 Online Payment vs. VISA, Mastercard

A Medium for Creation of New Services
 Publishers, Travel Agents, Teller, Virtual Yellow
Pages, Online Auctions …


A Boon for Academia
 Research Interactions and Collaborations
 Free Software for Classroom/Research Usage
 Opportunities for Exploration of Technologies in
Student Projects
What are Implications for BMI? Where is the Adv?
78
WWW: Three Market Segments
CSE
CSE
2102
2102
Server
Business to
Business
Corporate
Network


Server
Intranet




Decision
support
Mfg.. System
monitoring
corporate
repositories
Workgroups
Internet
Internet



Provider Network


Information sharing
Ordering info./status
Targeted electronic
commerce
Corporate
Server Network
Sales
Marketing
Information
Services
Server
Provider Network
Exposure to Outside
79
Information Delivery Problems on the Net
CSE
2102




Everyone can Publish Information on the Web
Independently at Any Time
 Consequently, there is an Information Explosion
 Identifying Information Content More Difficult
There are too Many Search Engines but too Few
Capable of Returning High Quality Data
Most Search Engines are Useful for Ad-hoc Searches
but Awkward for Tracking Changes
What are Information Delivery Issues for BMI?
 Publishing of Patient Education Materials
 Publishing of Provider Education Materials
 How Can Patients/Providers find what Need?
 How do they Know if its Relevant? Reputable?
80
Example Web Applications
CSE
2102


Scenario 1: World Wide Wait
 A Major Event is Underway and the Latest, Up-tothe Minute Results are Being Posted on the Web
 You Want to Monitor the Results for this
Important Event, so you Fire up your Trusty Web
Browser, Pointing at the Result Posting Site, and
Wait, and Wait, and Wait …
What is the Problem?
 The Scalability Problems are the Result of a
Mismatch Between the Data Access Characteristics
of the Application and the Technology Used to
Implement the Application
81
Example Web Applications
CSE
2102


Scenario 2:
 Many Applications Today have the Need for
Tracking Changes in Local and Remote Data
Sources and Notifying Changes If Some Condition
Over the Data Source(s) is Met
 To Monitor Changes on Web, You Need to Fire
Your Trusty Web Browser from Time to Time,
Cache the Most Recent Result, and Difference
Manually Each Time You Poll the Data Source(s)
Issue: Pure Pull is Not the Answer to All Problems
82
What is the Problem?
CSE
2102


Applications are Asymmetric but the Web is Not
 Computation Centric vs. Information Flow Centric
Type of Asymmetry
 Network Asymmetry
 Satellite, CATV, Mobile Clients, Etc.

Client to Server Ratio
 Too Many Clients can Swamp Servers

Data Volume
 Mouse and Key Click vs. Content Delivery

Update and Information Creation
 Clients Need to be Informed or Must Poll
83
What are Information Delivery Styles?
CSE
2102



Pull-Based System
 Transfer of Data from Server to Client is Initiated
by a Client Pull
 Clients Determine when to Get Information
 Potential for Information to be Old Unless Client
Periodically Pulls
Push-Based System
 Transfer of Data from Server to Client is Initiated
by a Server Push
 Clients may get Overloaded if Push is Too
Frequent
Hybrid
 Pull and Push Combined
 Pull First and then Push Continually
84
Publish/Subscribe
CSE
2102



Semantics: Servers Publish/Clients Subscribe
 Servers Publish Information Online
 Clients Subscribe to the Information of Interest
(Subscription-based Information Delivery)
 Data Flow is Initiated by the Data Sources
(Servers) and is Aperiodic
 Danger: Subscriptions can Lead to Other
Unwanted Subscriptions
Applications
 Unicast: Database Triggers and Active Databases
 1-to-n: Online News Groups
May work for Clinical Researcher to Provider Push
85
Design Options for Nodes
CSE
2102

Three Types of Nodes:
 Data Sources
 Provide Base Data which is to be Disseminated

Clients
 Who are the Net Consumers of the Information

Information Brokers
 Acquire Information from Other Data Sources, Add
Value to that Information and then Distribute this
Information to Other Consumers
 By Creating a Hierarchy of Brokers, Information
Delivery can be Tailored to the Need of Many Users

Brokers may be Ideal Intermediaries for BMI!
 Act on Behalf of Patients, Providers
 Incorporate Secure Access
86
CSE
2102
Research Challenges

Ubiquitous/Pervasive
Many computers and information
appliances everywhere,
networked together

Inherent Complexity:
 Coping with Latency (Sometimes
Unpredictable)
 Failure Detection and Recovery
(Partial Failure)
 Concurrency, Load Balancing,
Availability, Scale
 Service Partitioning
 Ordering of Distributed Events
“Accidental” Complexity:
 Heterogeneity: Beyond the Local
Case: Platform, Protocol, Plus All
Local Heterogeneity in Spades.
 Autonomy: Change and Evolve
Autonomously
 Tool Deficiencies: Language
Support (Sockets,rpc),
Debugging, Etc.
87
Infosphere
CSE
CSE
2102
2102
Problem: too many sources,too much information
Internet:
Information Jungle
Infopipes
Clean, Reliable,
Timely Information,
Anywhere
Digital
Earth
Personalized
Filtering &
Info. Delivery
Sensors
88
Current State-of-Art
CSE
CSE
2102
2102
Web
Server
Mainframe
Database
Server
Thin
Client
89
Infosphere Scenario
CSE
CSE
2102
2102
Infotaps &
Fat Clients
Sensors
Variety
of Servers
Many sources
Database
Server
90
Heterogeneity and Autonomy
CSE
2102

Heterogeneity:
 How Much can we Really Integrate?
 Syntactic Integration
 Different Formats and Models
 Web/SQL Query Languages

Semantic Interoperability
 Basic Research on Ontology, Etc

Autonomy
 No Central DBA on the Net
 Independent Evolution of Schema and Content
 Interoperation is Voluntary
 Interface Technology (Support for Isvs)
 DCOM: Microsoft Standard
 CORBA, Etc...
91
Security and Data Quality
CSE
2102

Security
 System Security in the Broad Sense
 Attacks: Penetrations, Denial of Service
 System (and Information) Survivability
 Security Fault Tolerance
 Replication for Performance, Availability, and
Survivability

Data Quality
 Web Data Quality Problems




Local Updates with Global Effects
Unchecked Redundancy (Mutual Copying)
Registration of Unchecked Information
Spam on the Rise
92
Legacy Data Challenge
CSE
2102


Legacy Applications and Data
 Definition: Important and Difficult to Replace
 Typically, Mainframe Mission Critical Code
 Most are OLTP and Database Applications
Evolution of Legacy Databases
 Client-server Architectures
 Wrappers
 Expensive and Gradual in Any Case
93
Electronic Medical Record Architectures
CSE
2102

Provider-Based Systems have Two Variants
 All Data In House





Limited In House – Off Site Storage (Larger,
Multi-Site Practices





Larger Providers (Clinics)
Control All Own Data
Sizeable IT Staff for 24-7 Operations
Control of Own Backups
Smaller Providers – Limited IT Staff
Desire Out-of-Box Solution
Local Data for Ease of Access
Remote Storage – Promotes Off-Hours Access
Even 1st Variant – Service for “Backups”
94
Key Challenges to Integrating Data
CSE
2102





Security and Privacy
 PHI and PII
 HIPAA
 FERPA
 WIC, Social Security (Medicaid/Medicare)
regulations
 State statutes
Alteration/disruption of business practices
Unique identification of individuals/cases
Accuracy and reliability of data
Disparate hardware/software platforms
95
EMR for Large Providers - AllScript
CSE
CSE
2102
2102
96
EMR for Smaller Providers
CSE
CSE
2102
2102
Provider’s Office
Local
EMR
Vendor’s Location
Server/Data Farm
Patient
Data
Remote
EMR
Remote Access
97
Integrating Clinical Repositories
CSE
2102


Provider/Hospital Relationship
 Provider has Privileges at Hospital
 Provider Chooses Office-Based EMR
 More Easily Integrated with Hospital EMR
 Emerging at Community Hospital Level
Example:
 Milford Hospital, MA
 All Area Providers with Privileges Linked in
 Ability to See Patient Records, Tests, at Hospital
 Unclear on Uploads from Providers to Hospital
 However, No Link to UMass Medical Center (of
which Milford Hospital is Affiliated)
98
Integrating Clinical Repositories
CSE
2102
99
Integrating Clinical Repositories
CSE
CSE
2102
2102
100
Integrating Clinical Repositories
CSE
CSE
2102
2102
101
Integrating Clinical Repositories
CSE
CSE
2102
2102
NHIN Prototype Phase I
102
Integrating Clinical Repositories
CSE
CSE
2102
2102
NHIN Prototype Phase II
103
CSE
2102
104