SEng 5861: Software Architecture

SEng 5861: Software Architecture
Lecture 6 Dr. Michael Whalen Fall 2010 SEng 5861 - Mike Whalen

Topics for Today Questions / Comments from Last Week Grading on presentations / project Midterm review & expectations Components and interfaces Distribution Functional view Information view SEng 5861 - Mike Whalen

Updates I am adding a supplemental reading (short) for the 10/29 class Eight Fallacies of Distributed Computing Explained http://www.rgoarchitects.com/Files/fallacies.pdf I will speak briefly to some of these fallacies today I am sorry for not getting slides / grades up sooner! My excuse: I had pneumonia this week I’m feeling better now  thanks to Levaquin. SEng 5861 - Mike Whalen

Functional viewpoint SEng 5861 - Mike Whalen

Functional Viewpoint Concerns Functionality Interfaces External Internal Design philosophy coupling, separation of concerns, Interaction volume, Functional flexibility SEng 5861 - Mike Whalen

Example Component Diagram http://en.wikipedia.org/wiki/File:Component-based_Software_Engineering_%28CBSE%29_-_example_2.gif SEng 5861 - Mike Whalen

…this sounds a lot like OO design Cohesion, coupling, separation of concerns?! Didn’t we cover this in 5802? Other than switching diagram notation, what has changed? What do you think? SEng 5861 - Mike Whalen

Component Diagram: Differences from In-Process Design Physical Distribution Multiple Interfaces per component ILoyaltyAccount Lifecycle No “class” concept Component Registry Version 2.0 Versioning http://en.wikipedia.org/wiki/File:Component-based_Software_Engineering_%28CBSE%29_-_example_2.gif SEng 5861 - Mike Whalen

Component-based design SEng 5861 - Mike Whalen

The Component: Szyperski Szyperski defines a component precisely by enumerating its characteristic properties as follows: A software component is a unit of composition with contractually specified interfaces and explicit context dependencies only. A software component can be deployed independently and is subject to composition by third party. Building Reliable Component-based SystemsChapter 1 - Basic Concepts in Component-Based Software Engineering

Implications of Szyperski’s Definition The following implications arise as a result of Szyperski’s definition: For a component to be deployed independently, a clear distinction from its environment and other components is required. A component must have clearly specified interfaces. The implementation must be encapsulated in the component and is not directly reachable from the environment. Building Reliable Component-based SystemsChapter 1 - Basic Concepts in Component-Based Software Engineering

The Component: D'Souza and Wills D'Souza and Wills define a component as A reusable part of software, which is independently developed, and can be brought together with other components to build larger units. It may be adapted but may not be modified. A component can be, for example, a compiled code without a program source, or a part of a model and/or design. Building Reliable Component-based SystemsChapter 1 - Basic Concepts in Component-Based Software Engineering

Describing a Component To be able to describe a component completely the component should consist of the following elements: A set of interfaces provided to, or required from the environment. An executable code, which can be coupled to the code of other components via interfaces. Building Reliable Component-based SystemsChapter 1 - Basic Concepts in Component-Based Software Engineering

Interfaces An interface of a component can be defined as a specification of its access point, offering no implementation for any of its operations. This seperation makes it possible to: Replace the implementation part without changing the interface; Add new interfaces (and implementations) without changing the existing implementation, Building Reliable Component-based SystemsChapter 1 - Basic Concepts in Component-Based Software Engineering

Describing an Interface Interfaces defined in standard component technologies using techniques such as Interface Definition Language (IDL) are: Sufficient in describing functional properties. Insuffiecient in describing extra-functional properties such as quality attributes like accuracy, availability, latency, security, etc. Building Reliable Component-based SystemsChapter 1 - Basic Concepts in Component-Based Software Engineering

Contracts A more accurate specification of a component's behavior can be achieved through contracts. A contract is comprised of: The Invariant, the global constraints which the component will maintain; The Pre-condition, the constraints which need to be met by the client; The Post-condition, the constraints which the component promises to establish in return. Building Reliable Component-based SystemsChapter 1 - Basic Concepts in Component-Based Software Engineering

How Contracts specify Component Interaction A contract specifies the interactions among components, in terms of: The set of participating components; The role of each component through its contractual obligations, such as type and casual obligations; The invariant to be maintained by the components; The specification of the methods which instantiate the contract. Building Reliable Component-based SystemsChapter 1 - Basic Concepts in Component-Based Software Engineering

Component Frameworks While frameworks in general describe a typical and reusable situation at a model level, a component framework describes a “circuit-board” with empty slots into which components can be inserted to create a working instance. Component Framework Coordination Services (transactions, persistence..) Building Reliable Component-based SystemsChapter 1 - Basic Concepts in Component-Based Software Engineering

Component Models The two concepts Component Models and Component Frameworks are sometimes intermixed. A component model defines a set of standards and conventions used by the component developer whereas a component framework is a support infrastructure for the component model. Component model Building Reliable Component-based SystemsChapter 1 - Basic Concepts in Component-Based Software Engineering

Relationships Between Concepts Interface that satisfies contracts Component-type Specific interface Component implementation Independent deployment Component model Component Framework Coordination Services (transactions, persistence..) Building Reliable Component-based SystemsChapter 1 - Basic Concepts in Component-Based Software Engineering

Current Component Specification Techniques syntactic specifications Microsoft’s Component Object Model (COM) Common Object Request Broker Architecture (CORBA) JavaBeans SOAP Building Reliable Component-based SystemsChapter 2 -Specification of Software Components

IDL Example interface ISpellCheck : IUnknown { HRESULT check([in] BSTR *word, [out] bool *correct); }; interface ICustomSpellCheck : IUnknown { HRESULT add([in] BSTR *word); HRESULT remove([in] BSTR *word); }; library SpellCheckerLib { coclass SpellChecker { [default] interface ISpellCheck; interface ICustomSpellCheck; }; }; Building Reliable Component-based SystemsChapter 2 -Specification of Software Components

Specification Uses the primary uses of such specifications are: Type checking of client code. A base for interoperability between independently developed components and applications. An important aspect of interface specifications is how they relate to substitution and evolution of components Building Reliable Component-based SystemsChapter 2 -Specification of Software Components

Substitution Substituting a component Y for a component X is said to be safe if: All systems that work with X will also work with Y From a syntactic viewpoint, a component can safely be replaced if: The new component implements at least the same interfaces as the older components, or The interface of the new component is a subtype of the interface of the old component. Building Reliable Component-based SystemsChapter 2 -Specification of Software Components

Specifying the Semantics of Components Current component technologies assume that the user of a component is able to make use of such semantic information. COM dictates that the error codes produced by an operation are immutable, i.e. changing these is equivalent to changing the interface Building Reliable Component-based SystemsChapter 2 -Specification of Software Components

Interfaces A component: Implements a set of interfaces that each consists of a set of operations. In addition, a set of pre-conditions and post-conditions is associated with each operation. Building Reliable Component-based SystemsChapter 2 -Specification of Software Components

A Pre-condition Is an assertion that the component assumes to be fulfilled before an operation is invoked. Will in general be a predicate over the operation’s input parameters and this state Building Reliable Component-based SystemsChapter 2 -Specification of Software Components

A Post-condition Is an assertion that the component guarantees will hold just after an operation has been invoked, provided the operation’s pre-conditions were true when it was invoked. Is a predicate over both input and output parameters as well as the state just before the invocation and just after Building Reliable Component-based SystemsChapter 2 -Specification of Software Components

An Invariant Is a predicate over the interface’s state model that will always hold A set of invariants may be associated with an interface. Building Reliable Component-based SystemsChapter 2 -Specification of Software Components

Interface specification diagram This model allows the same state to be associated with several interfaces Building Reliable Component-based SystemsChapter 2 -Specification of Software Components

Semantic Specification in a UML metamodel Building Reliable Component-based SystemsChapter 2 -Specification of Software Components

Interface Specification context ISpellCheck::check(in word : String, out correct : Boolean): HRESULT pre: word <> “” post: SUCCEEDED(result) implies correct = words->includes(word) context ICustomSpellCheck::add(in word : String) : HRESULT pre: word <> “” post: SUCCEEDED(result) implieswords = words@pre->including (word) context ICustomSpellCheck::remove(in word : String) : HRESULT pre: word <> “” post: SUCCEEDED(result) implies words = words@pre->exluding(word) Building Reliable Component-based SystemsChapter 2 -Specification of Software Components

Component specification diagram Similarly to interface specification diagrams, components specification diagrams are used to specify which interfaces components provide and require. Specifying a component that provides interfaces Building Reliable Component-based SystemsChapter 2 -Specification of Software Components

Inter-interface Constraints The component specification is completed by the specification of its inter-interface constraints, an example constraint is formulated in OCL below. context SpellChecker ISpellCheck::words = ICustomSpellCheck::words Building Reliable Component-based SystemsChapter 2 -Specification of Software Components

ISomeInterface <<comp spec>> SomeComponent IAnotherInterface IUsedInterface Interface dependency Building Reliable Component-based SystemsChapter 2 -Specification of Software Components

Typeless component interfaces (soap) SEng 5861 - Mike Whalen

What is SOAP? Slide from: www.cs.columbia.edu/~knarig/SOAP.ppt

What is SOAP? Lightweight protocol used for exchange of messages in a decentralized, distributed environment Facilitates interoperability in a platform-independent manner Used for Remote Procedure Calls W3C note defines the use of SOAP with XML as payload and HTTP as transport, but other transport protocols can be used such as SMTP and SIP. Slide from: www.cs.columbia.edu/~knarig/SOAP.ppt

Advantages of SOAP Uses HTTP which is widely used and scalable Wide remote system interoperability Flexible for growth because of XML properties It but can be used for RPC. Slide from: www.cs.columbia.edu/~knarig/SOAP.ppt

Disadvantages of SOAP No good way to describe the serialization pattern (XML schema is optional at this point) Parsing of SOAP packet and mapping to objects reduces performance Doesn’t implement security because it is a wire protocol—relies on HTTP Slide from: www.cs.columbia.edu/~knarig/SOAP.ppt

SOAP Ecosystem SEng 5861 - Mike Whalen Image from: http://www.iks.inf.ethz.ch/education/ws03/eai/SOAP.pdf

SOAP Elements Envelope (mandatory) Top element of the XML document representing the message Header (optional) Determines how a recipient of a SOAP message should process the message Adds features to the SOAP message such as authentication, transaction management, payment, message routes, etc… Body (mandatory) Exchanges information intended for the recipient of the message. Typical use is for RPC calls and error reporting. Slide from: www.cs.columbia.edu/~knarig/SOAP.ppt

SOAP Elements SOAP Encoding Envelope package Header/Body pattern Similar to how HTTP works Header Body Slide from: www.cs.columbia.edu/~knarig/SOAP.ppt

Simple Example <Envelope> <Header> <transId>345</transId> </Header> <Body> <Add> <n1>3</n1> <n2>4</n2> </Add> </Body> </Envelope> c = Add(n1, n2) Slide from: www.cs.columbia.edu/~knarig/SOAP.ppt

SOAP Request <SOAP-ENV:Envelope xmlns:SOAP-ENV=“http://schemas.xmlsoap.org/soap/envelope/” SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/”> <SOAP-ENV:Header> <t:transId xmlns:t=“http://a.com/trans”>345</t:transId> </SOAP-ENV:Header> <SOAP-ENV:Body> <m:Add xmlns:m=“http://a.com/Calculator”> <n1>3</n1> <n2>4</n2> </m:Add> </SOAP-ENV:Body> </SOAP-ENV:Envelope> Slide from: www.cs.columbia.edu/~knarig/SOAP.ppt

SOAP Request Scopes the message to the SOAP namespace describing the SOAP envelope <SOAP-ENV:Envelope xmlns:SOAP-ENV=“http://schemas.xmlsoap.org/soap/envelope/” SOAP-ENV:encodingStyle= "http://schemas.xmlsoap.org/soap/encoding/”> ...etc... </SOAP-ENV:Envelope> Establishes the type of encoding that is used within the message (the different data types supported) Slide from: www.cs.columbia.edu/~knarig/SOAP.ppt

SOAP Request Qualifies transId ...etc... <SOAP-ENV:Header> <t:transId xmlns:t=“http://a.com/trans”>1234</t:transId> </SOAP-ENV:Header> <SOAP-ENV:Body> <m:Add xmlns:m=“http://a.com/Calculator”> <n1>3</n1> <n1>4</n2> </m:Add> </SOAP-ENV:Body> ...etc... Defines the method Slide from: www.cs.columbia.edu/~knarig/SOAP.ppt

SOAP Response <SOAP-ENV:Envelope xmlns:SOAP-ENV=“http://schemas.xmlsoap.org/soap/envelope/” SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/”> <SOAP-ENV:Header> <t:transId xmlns:t=“http://a.com/trans”>345</t:transId> </SOAP-ENV:Header> <SOAP-ENV:Body> <m:AddResponsexmlns:m=“http://a.com/Calculator”> <result>7</result> </m:AddResponse> </SOAP-ENV:Body> </SOAP-ENV:Envelope> Slide from: www.cs.columbia.edu/~knarig/SOAP.ppt

SOAP Response <SOAP-ENV:Envelope xmlns:SOAP-ENV=“http://schemas.xmlsoap.org/soap/envelope/” SOAP-ENV:encodingStyle= "http://schemas.xmlsoap.org/soap/encoding/”> <SOAP-ENV:Header> <t:transId xmlns:t=“http://a.com/trans”>345</t:transId> </SOAP-ENV:Header> <SOAP-ENV:Body> <m:AddResponse xmlns:m=“http://a.com/Calculator”> <result>7</result> </m:AddResponse> </SOAP-ENV:Body> </SOAP-ENV:Envelope> Response typically uses method name with “Response” appended Slide from: www.cs.columbia.edu/~knarig/SOAP.ppt

SOAP Fault Used to carry error and/or status information within a SOAP message Appears within the SOAP body Defines the following: faultcode (mandatory) algorithmic mechanism for identifying the fault defined in the SOAP spec Faultstring (mandatory) human readable explanation of the fault Slide from: www.cs.columbia.edu/~knarig/SOAP.ppt

SOAP Fault faultactor (optional) information about who caused the fault to happen URI value identifying the source Detail error information related only to the Body element. if not present then indicates that the fault is not related to the Body element. Slide from: www.cs.columbia.edu/~knarig/SOAP.ppt

SOAP Fault Example <SOAP-ENV:Envelope xmlns:SOAP-ENV=“http://schemas.xmlsoap.org/soap/envelope/” SOAP-ENV:encodingStyle= "http://schemas.xmlsoap.org/soap/encoding/”> <SOAP-ENV:Body> <SOAP-ENV:Fault> <faultcode>SOAP-ENV:Server</faultcode> <faultstring>Internal Application Error</faultstring> <detail xmlns:f=“http://www.a.com/CalculatorFault”> <f:errorCode>794634</f:errorCode> <f:errorMsg>Divide by zero</f:errorMsg> </detail> </SOAP-ENV:Fault> </SOAP-ENV:Body> </SOAP-ENV:Envelope> Slide from: www.cs.columbia.edu/~knarig/SOAP.ppt

SOAP Encoding Based on a simple type system that has common features with programming languages and databases Types are either simple (scalar) or compound which is a composite of several parts An XML schema which is consistent with this type system can be constructed Use of schemas is encouraged but NOT required Slide from: www.cs.columbia.edu/~knarig/SOAP.ppt

Component distribution SEng 5861 - Mike Whalen

Why distribute? Scale Redundancy Security / Isolation Better utilization of hardware resources Cost: use cheaper “commodity” hardware Future flexibility SEng 5861 - Mike Whalen

Component Packaging and Distribution We want components to “behave the same” whether they reside locally on the same computer or are distributed on a different machine Middleware provides services to support semi-transparent distribution of components Not totally transparent: new classes of errors exist when components are distributed. What are these? Also, latency increases dramatically SEng 5861 - Mike Whalen

Component Packaging & Distribution Core Assets Technology Dependent Adaptors Middleware Buses SEng 5861 - Mike Whalen Image from: Enterprise SOA. Service-Oriented Best Practices

Remote Procedure Calls / Object Brokers Same semantics whether or not client and server on same computer Most RPC systems are synchronous (blocking) Examples: OMG CORBA, Microsoft COM, Open Group DCE, W3C SOAP SEng 5861 - Mike Whalen

Message-Oriented Middleware One-way message is queued and later processed (asynchronous) Decouples sender and receiver Message queues ensure that messages are not lost Message typically relate to transaction to be executed Example: SMTP (e-mail), IBM MQ Series, Tibco Rendezvous Client Application Server Application …or… Subscriber Publisher Subscriber Publisher Subscriber SEng 5861 - Mike Whalen

…but it’s more subtle than it looks Possible to implement MOM on top of RPCs and vice-versa. How? You tell me. Also possible to implement asynchronous communication over RPCs Pass in a callback interface Client is notified upon completion of the method SEng 5861 - Mike Whalen

Fallacies of distributed computing http://www.youtube.com/watch?v=8YX-gqRdK_8 SEng 5861 - Mike Whalen

…and you must avoid the seven eight fallacies The network is reliable Latency is zero Bandwidth is infinite The network is secure Topology doesn't change There is one administrator Transport cost is zero The network is homogeneous - Peter Deutsch SEng 5861 - Mike Whalen

Components and the Functional Model Functional model is often a component connector diagram Display relevant components Describe component dependencies via interfaces Distribution protocol is often expressed as a comment on component connections SEng 5861 - Mike Whalen

Import Figure 16-2 HERE SEng 5861 - Mike Whalen

How do we partition system? SEng 5861 - Mike Whalen

Pitfalls Poorly defined interfaces Poorly understood responsibilities Infrastructure modeled as functional elements View overload Inappropriate level of detail God elements SEng 5861 - Mike Whalen

Know Your Scope and Responsibilities SEng 5861 - Mike Whalen

Exercise: functional view of airport parking system SEng 5861 - Mike Whalen

Airport Parking Controller You are asked to build the automated parking system at MSP airport Support ePark: Also support ticketed parking: user receives a ticket and pays either by credit card or cash Simply insert your credit or debit card into the card reader at the ramp entrance. This will record the time you entered airport parking. Use the same credit or debit card to pay at an ePark® exit lane. The system is fully automated; there is no waiting in line for a cashier. SEng 5861 - Mike Whalen

Airport Parking Controller Basic functionality: users should be able to: Enter the parking lot if space is available Either via ticket or credit card Exit the parking lot at any time Pay either via cash or credit card But there is much more to it! What if user uses different credit card to enter/exit? What if there are insufficient funds? What if I am unable to reach VISA server? Etc. etc. etc. SEng 5861 - Mike Whalen

Some Use Cases SEng 5861 - Mike Whalen

Airport Controller Create the top-level component model Use a UML diagram model First describe components Then describe interfaces Does this app need to be distributed? If so, would you use MOM, RPC, or both? SEng 5861 - Mike Whalen

Information viewpoint SEng 5861 - Mike Whalen

Information Viewpoint How do we organize (and manage) large volumes of data Static views: Entity Relationship Diagram You know these from SEng5702! Lifecycle Quality Accuracy Timeliness Ownership SEng 5861 - Mike Whalen

Information Flow Modeling Where is data created and destroyed? How do data items change as they flow through the system? Concern can also be addressed (somewhat) using scenarios, but that is not their primary focus SEng 5861 - Mike Whalen

Data Ownership Is data item owned by exactly one process? If multiple copies exist, Is one the master? Is data synchronized? How often? What are consequences of “stale” data SEng 5861 - Mike Whalen

Data Ownership Grids Mapping data ownership to systems Relationships: Owner, Creator, Updater, Deleter, Reader, Copy, Validator Shows possible conflicts in data ownership Catalog and Purchasing both may modify product SEng 5861 - Mike Whalen

Data Lifecycle and Retention Data lifecycle: what is the process for creating, modifying, archiving, and deleting data For many industries, lifecycle may be regulated Financial transactions must be stored for NNN years Patient-identifying data for a study must be disposed of within XXX days. Archiving data Cannot usually store data on disk indefinitely Must be archived to more permanent storange This may affect availability Induces requirements on disk size SEng 5861 - Mike Whalen

Information Lifecycle Models Possible to represent as UML Statecharts or Entity Life Histories SEng 5861 - Mike Whalen Slide from: Eoin Woods, Viewpoints and Perspectives, SATURN 2008 (www.eoinwoods.info)

Pitfalls Data incompatibilities Units, representation (e.g. endianness), text format (ASCII vs. Unicode) Poor data quality Assess risk! How do we know data is bad? Scenarios for ‘bad’ user input What are fixup procedures? Manual? Automated? Information degradation Inadequate capacity What is expected data load? What are amounts of data that can be supported by OS, Database Time to load, move, batch data SEng 5861 - Mike Whalen

What Have We Learned? A bit about components and interfaces IDL and Middleware for components Distributed components Information modeling SEng 5861 - Mike Whalen

SEng 5861: Software Architecture