63
1 Architectural Styles Team 1: Interpreter; event driven Team 2: Peer-to-peer; plug-in Team 3: Service-oriented; publish- subscribe Team 4: Rule-based; mobile code

1 Architectural Styles Team 1: Interpreter; event driven Team 2: Peer-to-peer; plug-in Team 3: Service-oriented; publish-subscribe Team 4: Rule-based;

Embed Size (px)

Citation preview

Page 1: 1 Architectural Styles  Team 1: Interpreter; event driven  Team 2: Peer-to-peer; plug-in  Team 3: Service-oriented; publish-subscribe  Team 4: Rule-based;

1

Architectural Styles

Team 1: Interpreter; event driven Team 2: Peer-to-peer; plug-in Team 3: Service-oriented; publish-subscribe Team 4: Rule-based; mobile code

Page 2: 1 Architectural Styles  Team 1: Interpreter; event driven  Team 2: Peer-to-peer; plug-in  Team 3: Service-oriented; publish-subscribe  Team 4: Rule-based;

2

Architectural Style: Interpreter

Team Onesies: Jaime Pena, Carlos Montijo

Page 3: 1 Architectural Styles  Team 1: Interpreter; event driven  Team 2: Peer-to-peer; plug-in  Team 3: Service-oriented; publish-subscribe  Team 4: Rule-based;

3

◦ What is it?

◦ What problem does it solve?

◦ How does it solve the problem?

◦ Who are the actors or main elements?

◦ How do they relate to each other?

◦ What are the strengths and drawbacks?

◦ Example applications?

Interpreter

Page 4: 1 Architectural Styles  Team 1: Interpreter; event driven  Team 2: Peer-to-peer; plug-in  Team 3: Service-oriented; publish-subscribe  Team 4: Rule-based;

4

Takes a program written in one language and interprets it to another language to execute a series of commands

Also known as Virtual Machine Style

Interpreter: What is it?

Page 5: 1 Architectural Styles  Team 1: Interpreter; event driven  Team 2: Peer-to-peer; plug-in  Team 3: Service-oriented; publish-subscribe  Team 4: Rule-based;

5

Facilitates coding in high level language, which can be interpreted into lower level language

Interpreter can be used in different machines

Suitable for applications in which most appropriate language or machine for executing solution is not directly available

Interpreter: What problem does it solve?

Page 6: 1 Architectural Styles  Team 1: Interpreter; event driven  Team 2: Peer-to-peer; plug-in  Team 3: Service-oriented; publish-subscribe  Team 4: Rule-based;

6

Interpreter translates programming language for the user without requiring user to know the language

Interpreter allows for portability

Code interpreted in one machine will execute the same in another

Interpreter: How does it solve the problem?

Page 7: 1 Architectural Styles  Team 1: Interpreter; event driven  Team 2: Peer-to-peer; plug-in  Team 3: Service-oriented; publish-subscribe  Team 4: Rule-based;

7

Interpreter Engine◦ receives input and generates output

Interpreter State◦ state of interpreter engine

Program State◦ progress of code interpreted

Data Store Field◦ source code

Interpreter: Who are the actors?

Page 8: 1 Architectural Styles  Team 1: Interpreter; event driven  Team 2: Peer-to-peer; plug-in  Team 3: Service-oriented; publish-subscribe  Team 4: Rule-based;

8

Input to the interpreted program component is sent to the program state, where it is read by the program running on the interpreter 

Program output is placed in the program state, where it can result in output from the interpreted program component's interface

Interpreter: How do they relate to each other?

Page 9: 1 Architectural Styles  Team 1: Interpreter; event driven  Team 2: Peer-to-peer; plug-in  Team 3: Service-oriented; publish-subscribe  Team 4: Rule-based;

9

Page 10: 1 Architectural Styles  Team 1: Interpreter; event driven  Team 2: Peer-to-peer; plug-in  Team 3: Service-oriented; publish-subscribe  Team 4: Rule-based;

10

Advantages Portability and

flexibility of application or languages across various platforms

Supports dynamic change

“Sandbox” safety

Disadvantages Slow Hard to design and

test Cannot generate

all possible programs to be executed

Advantages vs. Disadvantages

Page 11: 1 Architectural Styles  Team 1: Interpreter; event driven  Team 2: Peer-to-peer; plug-in  Team 3: Service-oriented; publish-subscribe  Team 4: Rule-based;

11

Java, Java Virtual Machine (JVM) Python-based applications Lisp Perl

Example Applications

Page 12: 1 Architectural Styles  Team 1: Interpreter; event driven  Team 2: Peer-to-peer; plug-in  Team 3: Service-oriented; publish-subscribe  Team 4: Rule-based;

12

Architectural Style: Event-Driven

Team Onesies:Alexandra Rebollosa, Achim Schweighofer, Heber Ramirez

Page 13: 1 Architectural Styles  Team 1: Interpreter; event driven  Team 2: Peer-to-peer; plug-in  Team 3: Service-oriented; publish-subscribe  Team 4: Rule-based;

13

A framework that orchestrates behavior around the production, detection and consumption of events as well as the responses they evoke

Request/Response pattern

Consists of “event creators” and “event consumers” Event: Any identifiable occurrence that has significance for

system hardware/software Creator: Source of the event, only knows the event has occurred Consumer: Entity that needs to know the event has occurred,

they might be involved in processing the event or they might simply be affected by the event

Event-Driven : What is it?

Page 14: 1 Architectural Styles  Team 1: Interpreter; event driven  Team 2: Peer-to-peer; plug-in  Team 3: Service-oriented; publish-subscribe  Team 4: Rule-based;

14

Real-time analysis of data and response of system

Takes care of discrepancies in the system by following step-by-step rules◦ E.g., when buying online using Amazon, a login is

required in order to complete an order. If the customer is not a registered user, a new user must be created

Event-Driven : What problem does it solve?

Page 15: 1 Architectural Styles  Team 1: Interpreter; event driven  Team 2: Peer-to-peer; plug-in  Team 3: Service-oriented; publish-subscribe  Team 4: Rule-based;

15

It enables a large number of creators and consumers to exchange status and response information in near real-time.

Most effective when existing business rules, triggers, and related stored procedures are surfaced and made available to the middleware’s event processor.

In the short run, this means additional work for the database administrator.In the long run, it simplifies data management by making changes easier.

Event-Driven : How does it solve the problem?

Page 16: 1 Architectural Styles  Team 1: Interpreter; event driven  Team 2: Peer-to-peer; plug-in  Team 3: Service-oriented; publish-subscribe  Team 4: Rule-based;

16

Event Generator◦ Detects an event

Event Channel◦ Entry point to function, TCP/IP-Connection, File …

Event Processing Engine◦ Selection of appropriate reaction

Downstream Event-Driven Activity◦ Reaction to event

Event-Driven: Who are the actors?

Page 17: 1 Architectural Styles  Team 1: Interpreter; event driven  Team 2: Peer-to-peer; plug-in  Team 3: Service-oriented; publish-subscribe  Team 4: Rule-based;

17

Event generator senses facts and converts the collected data into a standardized form

The collected data is transferred over event channels to event engine (asynchronously)

Event processing identifies the event, selects and executes the appropriate reaction Downstream event-driven activity

Event-Driven: How do they relate to each other?

Page 18: 1 Architectural Styles  Team 1: Interpreter; event driven  Team 2: Peer-to-peer; plug-in  Team 3: Service-oriented; publish-subscribe  Team 4: Rule-based;

18

Advantages Strong support for

reuse. Adding and

replacing components with minimum effect on other components in the system.

Disadvantages Loss of control, for

example, in which order will components be evoked?

Correctness hard to ensure since it depends on order of invocation.

Advantages vs. Disadvantages

Page 19: 1 Architectural Styles  Team 1: Interpreter; event driven  Team 2: Peer-to-peer; plug-in  Team 3: Service-oriented; publish-subscribe  Team 4: Rule-based;

19

Java Swing API JavaScript WinForms API

Example Applications

Page 20: 1 Architectural Styles  Team 1: Interpreter; event driven  Team 2: Peer-to-peer; plug-in  Team 3: Service-oriented; publish-subscribe  Team 4: Rule-based;

20

1. http://books.google.com/books?id=WHMksQOj6ScC&pg=PA76&lpg=PA76&dq=interpreter+software+architecture&source=bl&ots=Wz3582xfgT&sig=E18v3bzd0LMGcKGHQynBW5Y5dh0&hl=en&sa=X&ei=waMoT4CBCuiU2AWOy83iAg&ved=0CHcQ6AEwCA#v=onepage&q=interpreter%20software%20architecture&f=false

2. http://etd.lsu.edu/docs/available/etd-07082004-152330/unrestricted/Banerjee_thesis.pdf

3. http://www.thomasalspaugh.org/pub/fnd/architecture.html#Interpreter

4. http://cs.queensu.ca/~ahmed/home/teaching/CISC322/F09/slides/CISC322_03_ArchitectureStyles.pdf

5. https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=4&ved=0CFUQFjAD&url=http%3A%2F%2Fwww.courses.utep.edu%2FPortals%2F870%2Ff11-s12%2520handouts%2FSlides%2FL04b-%2520More%2520Software%2520Architectures.pptx&ei=EEYuUqnhGaacygHwvoHwBQ&usg=AFQjCNGxOvLMOaUHiBd6duOo46mlx5BbBw&sig2=bnzA9WbAGiwme8hbIiGemA&bvm=bv.51773540,d.aWc&cad=rja

6. http://se.inf.ethz.ch/courses/2011a_spring/soft_arch/lectures/14_softarch_styles.pdf

7. http://kristiannissen.wordpress.com/2009/10/15/javascript-event-driven-architecture/

8. http://en.wikipedia.org/wiki/Event-driven_architecture

9. http://www.omg.org/soa/Uploaded%20Docs/EDA/bda2-2-06cc.pdf

10. http://searchsoa.techtarget.com/definition/event-driven-architecture

11. http://msdn.microsoft.com/en-us/architecture/aa699424.aspx

Sources

Page 21: 1 Architectural Styles  Team 1: Interpreter; event driven  Team 2: Peer-to-peer; plug-in  Team 3: Service-oriented; publish-subscribe  Team 4: Rule-based;

21

Architectural Styles: Peer-to-Peer & Plug-

InTeam 2

Monica GalindoAndrea Dominguez

Berenice OlivasSteven Werner

Carlos LuevanosDaniel Guzman

Page 22: 1 Architectural Styles  Team 1: Interpreter; event driven  Team 2: Peer-to-peer; plug-in  Team 3: Service-oriented; publish-subscribe  Team 4: Rule-based;

22

Peer-to-Peer Type of decentralized and distributed 

network architecture in which individual nodes in the network (called "peers") act as both suppliers and consumers of resources.

(http://en.wikipedia.org/wiki/Peer-to-peer)

The P2P style allows the client and server to swap their roles in order to distribute and synchronize files and information across multiple clients. It extends the client/server style through multiple responses to requests, shared data, resource discovery, and resilience to removal of peers.

(http://msdn.microsoft.com/en-us/library/ee658117.aspx)

Page 23: 1 Architectural Styles  Team 1: Interpreter; event driven  Team 2: Peer-to-peer; plug-in  Team 3: Service-oriented; publish-subscribe  Team 4: Rule-based;

23

Topology

Page 24: 1 Architectural Styles  Team 1: Interpreter; event driven  Team 2: Peer-to-peer; plug-in  Team 3: Service-oriented; publish-subscribe  Team 4: Rule-based;

24

What Problem does it solve? They solve the client-server problem where

client nodes request access to resources provided by central servers.

No need for centralized coordination from servers

Page 25: 1 Architectural Styles  Team 1: Interpreter; event driven  Team 2: Peer-to-peer; plug-in  Team 3: Service-oriented; publish-subscribe  Team 4: Rule-based;

25

How does it solve the problem? By allowing peers to make their resources

available to other network participants Resources such as processing power, disk

storage or network bandwidth

Page 26: 1 Architectural Styles  Team 1: Interpreter; event driven  Team 2: Peer-to-peer; plug-in  Team 3: Service-oriented; publish-subscribe  Team 4: Rule-based;

26

Main elements Peers: independent components, having their own

state and control thread. Connectors: Network protocols, often custom. Data Elements: Network messages Topology: Network (may have redundant connections

between peers); can vary arbitrarily and dynamically Supports: decentralized computing with flow of

control and resources distributed among peers. Highly robust in the face of failure of any given node.

• Caution: Scalable in terms of access to resources and computing power. But caution on the protocol.

(csse.usc.edu/classes/cs578_2013/Styles.ppt)

Page 27: 1 Architectural Styles  Team 1: Interpreter; event driven  Team 2: Peer-to-peer; plug-in  Team 3: Service-oriented; publish-subscribe  Team 4: Rule-based;

27

How do they relate to each other? They relate to each other by sharing all

their components i.e processors

Page 28: 1 Architectural Styles  Team 1: Interpreter; event driven  Team 2: Peer-to-peer; plug-in  Team 3: Service-oriented; publish-subscribe  Team 4: Rule-based;

28

Advantages

It is easy to install and so is the configuration of computers on this network.

All the resources and contents are shared by all the peers, unlike server-client architecture where server shares all the contents and resources.

P2P is more reliable as central dependency is eliminated. Failure of one peer doesn’t affect the functioning of other peers. In case of Client –Server network, if server goes down whole network gets affected.

There is no need for full-time System Administrator. Every user is the administrator of his machine. User can control their shared resources. 

The over-all cost of building and maintaining this type of network is comparatively very less.

http://www.ianswer4u.com/2011/05/peer-to-peer-network-p2p-advantages-and.html#axzz2ePzeqMIW

Page 29: 1 Architectural Styles  Team 1: Interpreter; event driven  Team 2: Peer-to-peer; plug-in  Team 3: Service-oriented; publish-subscribe  Team 4: Rule-based;

29

Disadvantages In this network, the whole system is decentralized thus it is

difficult to administer. That is one person cannot determine the whole accessibility setting of whole network.

Security in this system is very less. Viruses, spywares, trojans, and malwares can easily be transmitted over this P2P architecture.

Data recovery or backup is very difficult. Each computer should have its own back-up system.

Lot of movies, music and other copyrighted files are transferred using this type of file transfer. P2P is the technology used in torrents.

http://www.ianswer4u.com/2011/05/peer-to-peer-network-p2p-advantages-and.html#axzz2ePzeqMIW

Page 30: 1 Architectural Styles  Team 1: Interpreter; event driven  Team 2: Peer-to-peer; plug-in  Team 3: Service-oriented; publish-subscribe  Team 4: Rule-based;

30

Challenges Distribution of copyrighted files. Security issues. Bandwidth consumption.

http://www.slideshare.net/srijish/p2p-principle-architecture-and-challenges-presentation

Page 31: 1 Architectural Styles  Team 1: Interpreter; event driven  Team 2: Peer-to-peer; plug-in  Team 3: Service-oriented; publish-subscribe  Team 4: Rule-based;

31

Examples Fault Tolerance: Decentralized logical

networks which could support any type of data.

BitTorrent: P2P file sharing protocols. It accounts for a significant amount of traffic on the Internet.

Peercasting: Like broadcasting. Method of streaming content to consumers.

http://p2peducation.pbworks.com/w/page/8897427/FrontPage

Page 32: 1 Architectural Styles  Team 1: Interpreter; event driven  Team 2: Peer-to-peer; plug-in  Team 3: Service-oriented; publish-subscribe  Team 4: Rule-based;

32

Plug-in Architecture

[1]

Structural version:Futuristic Vertical City Holds Plug-In Hexagonal Housing Units

Software version:We currently use all the time…

Page 33: 1 Architectural Styles  Team 1: Interpreter; event driven  Team 2: Peer-to-peer; plug-in  Team 3: Service-oriented; publish-subscribe  Team 4: Rule-based;

33

Software Architecture: Plug-in

A plug in is a software component that adds a specific feature to an existing software application

Works as a puzzle piece, adding to the big picture, not changing it

[2]

Page 34: 1 Architectural Styles  Team 1: Interpreter; event driven  Team 2: Peer-to-peer; plug-in  Team 3: Service-oriented; publish-subscribe  Team 4: Rule-based;

34

Reasons to Have Plug-in Support to enable third-party developers to create

abilities which extend an application to support easily adding new features to reduce the size of an application to separate source code from an application

because of incompatible software licenses.

Page 35: 1 Architectural Styles  Team 1: Interpreter; event driven  Team 2: Peer-to-peer; plug-in  Team 3: Service-oriented; publish-subscribe  Team 4: Rule-based;

35

What problem does it solve? Many, even unknown ones…

◦ Adding functionality for specific purpose Examples: OneTab for Chrome Browser

Page 36: 1 Architectural Styles  Team 1: Interpreter; event driven  Team 2: Peer-to-peer; plug-in  Team 3: Service-oriented; publish-subscribe  Team 4: Rule-based;

36

More Example Applications

Firefox

[3]

Page 37: 1 Architectural Styles  Team 1: Interpreter; event driven  Team 2: Peer-to-peer; plug-in  Team 3: Service-oriented; publish-subscribe  Team 4: Rule-based;

37

More Example Applications

Word

[4]

Page 38: 1 Architectural Styles  Team 1: Interpreter; event driven  Team 2: Peer-to-peer; plug-in  Team 3: Service-oriented; publish-subscribe  Team 4: Rule-based;

38

How does it solve the problem?

Provides framework for developers to add features

Does not require source code to do it

Page 39: 1 Architectural Styles  Team 1: Interpreter; event driven  Team 2: Peer-to-peer; plug-in  Team 3: Service-oriented; publish-subscribe  Team 4: Rule-based;

39

Example Plug-In Framework

Page 40: 1 Architectural Styles  Team 1: Interpreter; event driven  Team 2: Peer-to-peer; plug-in  Team 3: Service-oriented; publish-subscribe  Team 4: Rule-based;

40

Who are the actors (i.e., main elements)?

Separate valid plug-in modules◦ Implemented independently◦ Usually one function/focus◦ Contribute functionality to many applications that

fit the architecture Host Application

Page 41: 1 Architectural Styles  Team 1: Interpreter; event driven  Team 2: Peer-to-peer; plug-in  Team 3: Service-oriented; publish-subscribe  Team 4: Rule-based;

41

How do they relate to each other?

Each plug-in has a well defined interface Host application must define a plug-in

architecture Plug-in fits like a piece to a puzzle

(application) Abstract base class (principle class) included

as part of plug-in bundle◦ Support code and resources

Host application checks if it conforms to requirements◦ If yes, then an instance is generated

Page 42: 1 Architectural Styles  Team 1: Interpreter; event driven  Team 2: Peer-to-peer; plug-in  Team 3: Service-oriented; publish-subscribe  Team 4: Rule-based;

42

Pros and Cons

Strengths

Expandability◦ Include new features

Parallel Development◦ Multiple features can be

developed simultaneously

Clear Development◦ Well defined interface

Simplicity◦ Plugin typically only does

one thing

Weaknesses

Extensibility◦ Poor interface design

restricting extension Maintainability

◦ Managing backward compatibility

Complexity◦ Plugin interactions cause

bugs Testing

◦ Cumbersome without mock plugin runner

Page 43: 1 Architectural Styles  Team 1: Interpreter; event driven  Team 2: Peer-to-peer; plug-in  Team 3: Service-oriented; publish-subscribe  Team 4: Rule-based;

43

Resources: Peer-to-Peer http://

www.slideshare.net/srijish/p2p-principle-architecture-and-challenges-presentation

http://www.ianswer4u.com/2011/05/peer-to-peer-network-p2p-advantages-and.html#axzz2ePzeqMIW

http://msdn.microsoft.com/en-us/library/ee658117.aspx

csse.usc.edu/classes/cs578_2013/Styles.ppt http://www.dmst.aueb.gr/dds/pubs/jrnl/2004-

ACMCS-p2p/html/AS04.html http://p2peducation.pbworks.com/w/page/88

97427/FrontPage (http://en.wikipedia.org/wiki/Peer-to-peer)

Page 44: 1 Architectural Styles  Team 1: Interpreter; event driven  Team 2: Peer-to-peer; plug-in  Team 3: Service-oriented; publish-subscribe  Team 4: Rule-based;

44

Resources: Plug-in Images:

◦ [1] http://inhabitat.com/plug-your-hexagonal-house-into-this-vertical-city/◦ [2] https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/LoadingCode/Concepts/Plugins.html◦ [3] https://addons.mozilla.org/en-US/firefox/◦ [4] http://msdn.microsoft.com/en-us/library/office/◦ aa189710(v=office.10).aspx

References◦ http://stackoverflow.com/questions/2818415/what-are-the-advantages-and-disadv

antages-of-plug-in-based-architecture

◦ https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/LoadingCode/Concepts/Plugins.html

Page 45: 1 Architectural Styles  Team 1: Interpreter; event driven  Team 2: Peer-to-peer; plug-in  Team 3: Service-oriented; publish-subscribe  Team 4: Rule-based;

45

Software Architecture

Publish-Subscriber StyleService-Oriented Style

Page 46: 1 Architectural Styles  Team 1: Interpreter; event driven  Team 2: Peer-to-peer; plug-in  Team 3: Service-oriented; publish-subscribe  Team 4: Rule-based;

46

Publish-Subscriber

What? Why?

Message pattern where senders of the messages (publishers) do not program the messages to be sent directly to a specific receiver (subscribers).

 the message will be seen by a subscriber once they have subscribed to the publisher

publishers don’t have to know who the subscribers are

subscribers will only have information of subscribers that they are interested with

Page 47: 1 Architectural Styles  Team 1: Interpreter; event driven  Team 2: Peer-to-peer; plug-in  Team 3: Service-oriented; publish-subscribe  Team 4: Rule-based;

47

Publish-Subscriber How: This architecture uses filtering in order to ensure that

only certain information is delivered to specific users Actors:

◦ Publisher◦ Event Channel◦ Subscriber

Actor Relations:◦ Subscribers choose which publisher they wish to receive

information for◦ Publishers publish an even to a “channel” ◦ The channel receives information of subscribers as well as

publishers allowing the subscriber to receive pertinent information from the chosen publisher

Page 48: 1 Architectural Styles  Team 1: Interpreter; event driven  Team 2: Peer-to-peer; plug-in  Team 3: Service-oriented; publish-subscribe  Team 4: Rule-based;

48

Publish-Subscriber

Strength Drawbacks

 scalability, through clever protocols the publisher/subscriber pattern allows for higher  message loads from a small number of data center

This favors scalability through parallel operations, and tree or network based routing

by not being dependent on each other they can work independently  despite the state of the others.

The pattern must  be carefully coded to allow certain features like guaranteed delivery of messages

There may be an assumption of an audience when one may not be present

Loose Coupling is also a disadvantage because it is hard to guarantee outcomes since the publisher has little information from subscribers

Examples: RSS Feeds, YouTube

Page 49: 1 Architectural Styles  Team 1: Interpreter; event driven  Team 2: Peer-to-peer; plug-in  Team 3: Service-oriented; publish-subscribe  Team 4: Rule-based;

49

Service-Oriented

What? Why?

Computing based on request and reply.

Provides application functionality as service.

Allow easy cooperation of a large number of computers that are connected over a network.

Modules driven implementation. It gives the ability to develop new functions rapidly.

Improved information flow. Organizational flexibility. Lower software

development and management costs. (re-use).

Security attacks. Data confidentiality and

integrity. Maintenance and

upgrade. Reliability.

Page 50: 1 Architectural Styles  Team 1: Interpreter; event driven  Team 2: Peer-to-peer; plug-in  Team 3: Service-oriented; publish-subscribe  Team 4: Rule-based;

50

Service-Oriented How: This architecture takes advantage of previously defined services

in order to promote re-usability as well as quick delivery of services

Actors: ◦ Service provider, ◦ Service directory (registry),◦ Service consumer

Actor Relations:◦ The service provider publishes and secures the service

in a service directory.◦ The service consumer locates and accesses the

service in the service directory. ◦ The service consumer manages the service provided

by the service provider.

Page 51: 1 Architectural Styles  Team 1: Interpreter; event driven  Team 2: Peer-to-peer; plug-in  Team 3: Service-oriented; publish-subscribe  Team 4: Rule-based;

51

Service-Oriented

Strengths Drawbacks

◦ Service can be re-used.◦ Messaging: control,

monitoring, transformation, security.

◦ Complex event processing (ability to adapt)

◦ service discovery◦ Virtualization (improved

reliability)◦ Model-driven implementation.◦ Easy maintenance. ◦ Loose Coupling

◦ Overhead◦ Complexity◦ Configuration

management ◦ Governance◦ Hard to implement when

starts at zero.

Examples: TurboTax, Wells Fargo, Cricket wireless, Facebook, Dropbox

Page 52: 1 Architectural Styles  Team 1: Interpreter; event driven  Team 2: Peer-to-peer; plug-in  Team 3: Service-oriented; publish-subscribe  Team 4: Rule-based;

52

Resources (P.S.) Birman, K. and Joseph, T. "Exploiting virtual

synchrony in distributed systems" in Proceedings of the eleventh ACM Symposium on Operating systems principles (SOSP '87), 1987

Hasan, Souleiman, Sean O'Riain, and Edward Curry. 2012. "Approximate Semantic Matching of Heterogeneous Events.“

http://msdn.microsoft.com/en-us/magazine/hh201955.aspx

http://en.wikipedia.org/wiki/Publish%E2%80%93subscribe_pattern

Page 53: 1 Architectural Styles  Team 1: Interpreter; event driven  Team 2: Peer-to-peer; plug-in  Team 3: Service-oriented; publish-subscribe  Team 4: Rule-based;

53

Resources (S.O.) http://searchsoa.techtarget.com/definition/

service-oriented-architecture http://www.javaworld.com/javaworld/jw-06-

2005/jw-0613-soa.html http://www.opengroup.org/soa/source-

book/soa/soa_features.html www.exforsys.com

Page 54: 1 Architectural Styles  Team 1: Interpreter; event driven  Team 2: Peer-to-peer; plug-in  Team 3: Service-oriented; publish-subscribe  Team 4: Rule-based;

54

Rule-Based System

Page 55: 1 Architectural Styles  Team 1: Interpreter; event driven  Team 2: Peer-to-peer; plug-in  Team 3: Service-oriented; publish-subscribe  Team 4: Rule-based;

55

What is it? Software that can duplicate human

knowledge and reason from it. A collection of knowledge, which can be a

set of rules. Database of facts Based on Condition-Action Rules

Page 56: 1 Architectural Styles  Team 1: Interpreter; event driven  Team 2: Peer-to-peer; plug-in  Team 3: Service-oriented; publish-subscribe  Team 4: Rule-based;

56

What Problem Does it Solve and How? Shortage of experts.

◦ Duplicating expert reasoning quickly.

Page 57: 1 Architectural Styles  Team 1: Interpreter; event driven  Team 2: Peer-to-peer; plug-in  Team 3: Service-oriented; publish-subscribe  Team 4: Rule-based;

57

Who are the actors? And How do they Relate to each other?

Rule EngineInference

EngineProcess

Rule BasePermanent

Data

Working Memory

Temporary Data

User Interface

Page 58: 1 Architectural Styles  Team 1: Interpreter; event driven  Team 2: Peer-to-peer; plug-in  Team 3: Service-oriented; publish-subscribe  Team 4: Rule-based;

58

Strengths and Drawbacks Strengths

◦ Knowledge of experts can be duplicated.◦ Can be adapted to many different fields.◦ Easy for humans to understand

Drawbacks◦ Can only be used were knowledge can be

describe as an If-Then statement.◦ The larger the number of statements the slower

the system will perform.◦ Is it possible to capture all knowledge?

Page 59: 1 Architectural Styles  Team 1: Interpreter; event driven  Team 2: Peer-to-peer; plug-in  Team 3: Service-oriented; publish-subscribe  Team 4: Rule-based;

59

Example Applications AI Voice Server Health Care Financial Service.

Page 60: 1 Architectural Styles  Team 1: Interpreter; event driven  Team 2: Peer-to-peer; plug-in  Team 3: Service-oriented; publish-subscribe  Team 4: Rule-based;

60

Mobile Based Architecture

Page 61: 1 Architectural Styles  Team 1: Interpreter; event driven  Team 2: Peer-to-peer; plug-in  Team 3: Service-oriented; publish-subscribe  Team 4: Rule-based;

61

Mobile Code: Strengths and Weaknesses Code is portable since it can run anywhere No installation load on server is reduced, since the code is

run on client machine interoperability user unaware that mobile code is executing

on their machine

Page 62: 1 Architectural Styles  Team 1: Interpreter; event driven  Team 2: Peer-to-peer; plug-in  Team 3: Service-oriented; publish-subscribe  Team 4: Rule-based;

62

Applications java applets activeX controls macros in MS office scripts

Page 63: 1 Architectural Styles  Team 1: Interpreter; event driven  Team 2: Peer-to-peer; plug-in  Team 3: Service-oriented; publish-subscribe  Team 4: Rule-based;

63

Sources

 "Mobile Code." Mobile Code. 11 Sept. 2013 <http://courses.ischool.berkeley.edu/i206/f97/GroupC/sld003.htm>.

"Mobile Code Security." Mobile Code Security. 11 Sept. 2013 <http://seit.unsw.adfa.edu.au/staff/sites/lpb/papers/mcode96.html>.

Ireson-Paine, Jocelyn. "What is a rule-based system?" What is a rule-based system? 14 Feb. 1996. 11 Sept. 2013 <http://www.j-paine.org/students/lectures/lect3/node5.html>.