1. Distribution and components
Enterprise Computing
Distribution and components

2. Distribution

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.

5. 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.

6. Exercise I 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. 8

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

12. 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.

13. Implementing a distributed architecture
Client-Side
Network
Middle Tier
connect to
remote
object
invokes
Skeleton
Stub
invoke
Client
Server-Side
code
return
results
return
results
return
results
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. Components

15. Characteristics of a component
Described completely by:
A set of interfaces provided to other components
A set of requirements from the environment.
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.

16. Objects and Components
The distinction between objects and components is at the conceptual level:
Components can be implemented using objects or any other methodology.
A component as a collection of objects, in which the objects co-operate with each other, and are intertwined tightly.
Components are architectural level entities
Components are often larger units of granularity than objects, and have complex actions at their interfaces.
Components often rely on environmental services
Persistent storage whereas objects have local state.

17. 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.

18. Coordination Services (transactions, persistence..)
Component Frameworks
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..)

19. 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

20. Relationships Between Concepts
Interface that satisfies contracts
Component-type
Specific interface
Component implementation
Independent
deployment
Component
model
Component
Framework
Coordination Services (transactions, persistence..)

21. Components and frameworks
Component specifications are essential for component users who are focused on the component features, functional and non-functional
The main purpose of frameworks is to support the process of component composition
Component developers must obey the rules and formats specified by the framework to develop and to specify the component, while component users will use frameworks to compose systems from components in a more efficient and accurate way.