1. Interpreter Style Examples
Micro coded machine
Implement machine code in software.
Cash register / calculator
Emulate a clever machine using a cheap one.
Database plan
The database engine interprets the plan.
Presentation package
Display a graph, by operating on the graph.
(c) Ian Davis
Spring 2017

2. Interpreter Style Advantages
Simulation of non-implemented hardware, keeps cost of hardware affordable.
Facilitates portability of application or languages across a variety of platforms.
Behaviour of system defined by a custom language or data structure, making software easier to develop and understand.
Separates the how do we do this, from the how do we say what it is we want to do.
(c) Ian Davis
Spring 2017

3. Java Architecture
(c) Ian Davis
Spring 2017

4. Interpreter Style Disadvantages
Extra level of indirection slows down execution.
Java has an option to compile code.
JIT (Just In Time) compiler.
Can’t step outside language as interpreted
(c) Ian Davis
Spring 2017

5. Message Oriented Architectures
Spring 2017
(c) Ian Davis

6. Message Oriented Architecture
Client/Server
Service Oriented Architecture (SOA)
Peer to Peer
Publisher/Subscriber
Message Bus
Ajax (Synchronous/Asynchronous)
Mobile code (Eg. Javascript, Applets)
Spring 2017
(c) Ian Davis

7. Client-Server Advantages
Distribution of data is straightforward.
Transparency of location.
Mix and match heterogeneous platforms.
Easy to add or upgrade servers.
Functional client server interface.
Simplifies distant levels of recursion.
One server can support multiple clients
(c) Ian Davis
Spring 2017

8. Client-Server Disadvantages
Security
No central register of names/services -- hard to find out what services are available
Hard to asynchronously communicate with server. Eg. cancel database query..
Server can’t initiate communication with clients. The best it can do is provide complex responses (callback) when its services are requested.
(c) Ian Davis
Spring 2017

9. Client-Server Disadvantages
Overhead of packing and unpacking data encoded in messages, particularly when client and server on same machine. (In good client-server implementations this problem is avoided).
Potential restrictions on the data types and structures that can be passed. Eg.__int64, unicode, etc.
Uncertain server lifetime
Unpredictable server load
(c) Ian Davis
Spring 2017

10. Remote Procedure Calls
Interface Definition Language IDL
RPCGEN
Low level client proxy stub
Layered architecture
Maps procedure calls to messages (marshalling)
Maps message replies to procedure return value
High level server mainline
Event driven architecture
Maps messages to procedure calls
Maps return value to reply message
Spring 2017
(c) Ian Davis

11. Component Object Model (COM)
Factory
Dynamic Linking of Objects at runtime
IUnknown interface
QueryInterface(REFIID riid, void **interfacePP)
AddRef(void)
Release(void)
All method invocation is via obtained interface
Implementation transparent
Winter 2016
(c) Ian Davis

12. DCOM COM DCOM Dynamic loading and connection to an interface
Class Factory loads object with Iunknown interface
QueryInterface, AddRef, Release
DCOM
Provides a transparent remote COM interface
Implemented using the RPC strategy
Microsoft reinvented their own IDL
Spring 2017
(c) Ian Davis

13. Broker Architecture Clients shouldn’t know how to reach Service
Offers additional Dynamic Services
For adding, removing, exchanging, activating and locating components as needed
Security may be enforced by brokers
Who can talk to what, and how
Broker may act as an adaptor (Bridge)
Load balancing, etc.
Spring 2017
(c) Ian Davis

14. RPCs Versus ORBs Handles security/adaptors/etc. (c) Ian Davis
Spring 2017

15. Common Object Request Broker CORBA
Goals
Language independence
OS independence
Interface mismatch translation (bridging)
Encapsulate and extend the RPC paradigm
Provide handles to multiple servers/services
Security, communication of errors, etc.
Spring 2017
(c) Ian Davis

16. Reasons it struggled IDL defined but not the marshalling
Not compatible across different vendors
Your CORBA can’t talk to my CORBA
Location transparency
Can’t treat all objects the same way
Designed by a committee (who disagreed)
Failure to enforce common standards
Your CORBA is not like my CORBA
Poor implementations of the standard
Spring 2017
(c) Ian Davis

17. Message Bus Architecture
Context
N2 number of possible peer-peer connections
Problem
Need to reduce cost of adding new connections
Forces
Want to reduce application dependencies
Applications use different interfaces
Don’t want every application to know all interfaces
Spring 2017
(c) Ian Davis

18. Message Bus Solution All peers communicate with the bus
Bus has an agreed-upon message schema
Bus has a common set of command messages
Bus provides shared infrastructure
For managing peer-peer connections
For sending messages to recipients
Spring 2017
(c) Ian Davis

19. https://msdn.microsoft.com/en-us/library/ff647328.aspx Spring 2017
(c) Ian Davis