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

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

Java Architecture (c) Ian Davis Spring 2017

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

Message Oriented Architectures Spring 2017 (c) Ian Davis

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

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

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

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

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

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

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

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

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

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

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

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

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

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