Upload
dustin-hancock
View
240
Download
0
Tags:
Embed Size (px)
Citation preview
Enterprise Computing
Distribution and components
Overview This section of the module focuses on the evolution from custom coded
integration of units of code to CORBA to J2EE.
It explains for what distributed computing means and what components and containers mean. Demystifies and makes clear the concepts. Provides enough details to allow students to find out the rest
Two main drivers for the evolution to CORBA: The need to integrate across multiple systems The need to reduce the skills required to complete these integrations.
Two main drivers for the evolution to J2EE: The need to create eCommerce systems The need to reduce the skills required to complete these systems.
2
3
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.
Note: This does not mean that you should never consolidate applications into a single suite with high degree of sharing of models and processes (e.g. SAP).
4
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.
5
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.
6
7
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.
8
Solution: 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,
CORBA
An example of a distributed architecture
10
Overview of CORBA CORBA stands for Common Object Request Broker
Architecture
It is a industry standard, language neutral, platform independent, open system for doing distributed computing
CORBA is maintained by the Object Management Group (OMG)
It is widely used in industries such as telecommunications, health care, and banking…
Basis of many J2EE standards IIOP, JTS, JNDI etc etc.
11
CORBA Characteristics Platform Neutral:
CORBA is designed to specify how systems should communicate in an heterogeneous environment Different OS, programming languages and
architectures Mappings for C, C++, Java, COBOL, Smalltalk and
some scripting languages
Open: OMG specifications are open to anyone who wishes
implementing them
12
CORBA Interfaces Interfaces define the services that a client is allowed to
call upon a server without specifying any implementation.
A CORBA object is said to support or implement an interface
Interfaces are specified in CORBA's Interface Definition Language (IDL)
13
CORBA Interfaces IDL is used to define the method calls
This includes the types and number of arguments and the return type
interface EUStats {
readonly attribute long date;
string getMainLangs(in string countryname);
long getPopulation(in string countryname);
string getCapital(in string countryname); };
14
Object Request Broker Communications over CORBA are based on the client-server
principle the client sends a request to the server, which returns a
response Who is the client and who is the server is defined upon the
request
All requests are sent through interfaces and go through the Object Request Broker (ORB)
15
Object Request Broker
The ORB acts as an intermediary, taking client requests formatting them in a manner to send over TCP/IP based
connections decoding them on the other end and delivering the request to the server
The work done by ORB is transparent to the clients and servers
However, client/servers must explicitly invoke infrastructure services in most cases Code level invocations for security, persistence,
transactionality etc.
16
CORBA Model
Client StubSkeleton
Server-SideComponent
Client-Side Network Middle Tier
invokes
returnresults
connect toremoteobject invoke
returnresults
returnresults
Stub and Skeleton are auto-generated; client “thinks” its making a localcall, most networking details are hidden from client; the main detailis obtaining a reference to the remote object naming service
CORBA services
17
Location, communication and interfaces definitions are not sufficient to build complex systems.
Also required are services such as Security Transactions Management Event notification …
CORBA included standards for these services.
Components
19
Interfaces: What was learnt from CORBA
An interface of a component is defined as a specification of its access point, offering no implementation for any of its operations. Supporting loose coupling between the provider of the interface and entities consuming the
interface.
Sufficient in describing functional properties.
It is insufficient in describing extra-functional properties such as quality attributes like accuracy, availability, latency, security, etc. These must be delivered by the environment.
Do not address the semantic, only the syntactic
20
Need for containers: What was learnt from CORBA
CORBA dealt effectively integration between units of code.
CORBA was still difficult to use for a developer because it required the unit developer to Understand what the CORBA middleware did Be able to invoke the middleware with lines of code.
Solution: Use components which specify what they need from the environment. The environment is called a container.
21
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
22
The Component: Two definitions General definition:
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.
Technically focused definition: A unit of composition with contractually specified interfaces and
explicit context dependencies only.
Business focused definition: A component can be deployed independently and can be subject
to composition by a 3rd party implying that the Implementation must be encapsulated in the component and is
not directly reachable from the environment A clear distinction from its environment and other components
is required
23
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.
24
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.
25
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.
26
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.
Coordination Services (transactions, persistence..)
ComponentFramework
27
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
28
Relationships Between Concepts
Interface that satisfies contracts
Component implementation
Component model
Independent deployment
Component-typeSpecific interface
Coordination Services (transactions, persistence..)
ComponentFramework
29
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.
30
Back to CORBA: The CORBA Component Model
Base CORBA did not provide a container-like component model Explict calls to infrastructure services
CORBA Component Model (CCM) attempted to fill that gap Interface and Assembly Framework : The Container Approach Lifecycle
Why didn’t it take off?