Distribution and components

2

What is the problem? Enterprise computing is

Large scale & complex: It supports large scale and complex organisations

Spanning multiple organisations and functions: Must support many different business processes and data models.

Every changing: Must supporting evolving businesses, commercial relationships and regulation

Consolidating all “application logic” into a single application is very hard. Even if it implemented as a single system, it must still be easy

to change and hence contain its own internal structure.

3

The solution Therefore you need to be able breakdown applications

into units which Can be separately maintained and evolved Can be recombined to address new business problems. Can effectively use ‘bought in’ software and customised for a

individual organisation. Services can be reused for new applications Can be distributed across servers in multiple locations if required.

What technology and architectures are required to do this? Writing it all is difficult and requires the rare technical skills.

4

Class Exercise

Two applications A and B Each running on its own server. A cable links the two servers.

Describe the software required to allow application A to invoke a block of code in application B, and receive and successfully interpret the returning message from A.

Solution:

A mechanism for communicating between the units of code. Should be independent of the language the unit is written in. Should be independent of location or network.

A mechanism to locate where the other unit of code is located.

5

6

Exercise II What do you need to ensure that each unit

Can be separately maintained and evolved Can be recombined to address new business problems. Can effectively use ‘bought in’ software and customised for a

individual organization. Services can be reused for new applications Can be distributed across servers in multiple locations if

required.

7

Distributed architecture: Interfaces

An interface is A specification of its access point, offering no implementation details for any of its

operations. A contract between the provider of the interface and any client requiring its services

defined by the messages that are exchanged and data passed between the client and the server.

This separation (loose coupling) makes it possible to: Replace the implementation part without changing the interface; Add new interfaces (and implementations) without changing the existing

implementation,

8

Interfaces: Limitations

Sufficient in describing functional properties. i.e. How the function is called and the data returned

Does not provide an explanation of the what capabilities the interface provides.

Does not describe extra-functional properties such as quality attributes like accuracy, availability, latency, security, etc. These must be delivered by the environment.

9

Distributed architecture: Need for late binding

Embedding the precise location of a resource in code reduces the flexibility of the overall system

Using a name which is then resolved into the resource at run-time (known as late binding) allows the resources to be changed to support Load balancing Migration of the resource from one location to another Replacement of the resource

In the context of a distributed architecture, the name specifies the interface and any additional attributes required

10

Distributed architecture: Location service

A location service receives a request containing a resource name and returns one or more locations where the resource is available Location services are a subset of naming services and typically

referred to simply as naming services

A naming service is a commonly used architectural principle, examples include DNS

11

Distributed architecture: Protocol

Once a server has been identified supporting the interface... = A resource matching the name

A protocol must be agreed to exchange information In most distributed architectures, there is a single base protocol that is

supported by all systems participating in the architecture

The information exchanged is typically messages reflecting the structure of the interface The protocol supports the invocation of functions on the interface and

returning of values

Implementing a distributed architecture A distributed architecture defines the three elements

Interface, location service and protocol

Implementations of an architecture will provide toolkits and libraries to automatically generate the middleware code related to the interfaces and protocol

Implementations also provide services to provide location service Enterprise grade distributed architectures also include enterprise services such

as transactionality, security etc.

12

Skeleton

13

Implementing a distributed architecture

Client StubServer-Side

code

Client-Side Network Middle Tier

invokes

returnresults

connect toremoteobject invoke

returnresults

returnresults

Stub and Skeleton are typically auto-generated in a distributed system; client “thinks” its making a local call, most networking details are hidden from client; the main detail is obtaining a reference to the remote object naming service

14

Objectives of component technology

Programmer productivity, cost-effective deployment, rapid time to market, seamless integration, application portability, scalability, security are some of the challenges that component technology tries to address head on. Also targeted by CORBA but only partially successful

Component-based development aims at enabling higher level of software reuse has well defined services can be used in building many different applications can be reused in building larger components allow cross language and cross platform reuse

15

The Component: Three definitions A reusable part of software, independently developed,

which can be brought together with other components to build larger units. A component can be, for example, a compiled code without a

program source, or a part of a model and/or design.

A component can be deployed independently and can be subject to composition by a 3rd party Implementation must be encapsulated in the component and is not

directly reachable from the environment

A unit of composition with contractually specified interfaces and explicit context dependencies only Defines what is needed from a component

16

What is a component?

Expanding on the third definition on previous slide Described completely by:

1. A set of interfaces provided to other components

2. A set of requirements from the environment.

3. An executable code, which can be coupled to the code of other components via interfaces.

To improve the component quality, the following elements can be included in the specification of a component: The specification of non-functional characteristics, The validation code, Additional information.

17

What is an interface? An interface is

A specification of its access point, offering no implementation details for any of its operations.

A contract between the provider of the interface and any client requiring its services defined by the messages that are exchanged and data passed between the client and the server.

This separation (loose coupling) makes it possible to: Replace the implementation part without changing the interface; Add new interfaces (and implementations) without changing the existing

implementation,

18

Components and the environment

The environment is the software that the component runs on and which provides services it requires

The main purpose of frameworks is to support component execution and the process of component composition

Composition is the linking of components to complete a more complex task

19

Terminology: Software Frameworks

Software is built by "putting pieces together". Frameworks provide the context in which the pieces can be used.

A framework may be seen as: A reusable design of a system, A skeleton of an application which can be customised by an

application developer.

20

Component Frameworks A component framework describes a “circuit-board” with

empty slots into which components can be inserted to create a working instance.

(Frameworks in general describe a typical and reusable situation at a model level)

Coordination Services (transactions, persistence..)

ComponentFramework

21

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

22

Relationships Between Concepts

Interface that satisfies contracts

Component implementation

Component model

Independent deployment

Component-typeSpecific interface

Coordination Services (transactions, persistence..)

ComponentFramework

Component development roles Component developers obey the rules and formats specified by the

framework to develop and to specify the component Focus on the business logic, relying on the framework to deal with middleware

capabilities(distribution, transactionality, security)

Component assemblers use frameworks to compose systems from components in a more efficient and accurate way Take existing components, link them together to perform the required business

processing

Component deployers define the way the platform will provide middleware capabilities to the running system Set security policies, provisioning the system etc

23