Middle ware

1
Middle ware CORBA

• Alzahra University, Branch IT Management
• SSADM Course
• By Leila Ghaffari
• Spring 1384

2
CONTENTS

• Part One Middle ware
• Part Two CORBA
• References

3
Part One Middle ware

• What is a Three-layer architecture (3LA) ?
• what does a 3LA provide that a 2LA doesn't ?
• Why would one want to use a 3LA?
• Two Approaches
• Why writing an application using a 2LA model is
  easier than writing a 3LA?
• Why MCL is adopted a 3LA?
• Summary and Conclusions

4
What is a Three-layer architecture (3LA) ?

• A non-computing example
• Within a computing context

5
A non-computing example

• The travel agent represents a real-world parallel
  to the concept of the three-layer architecture.
  In this example, the customer is equivalent to
  the front-end application, the agent to the
  middle-layer logic, and the various reservation
  systems to back-end IT systems.

6
The Travel Agent
7
A non-computing example

• A customer makes a simple request to the agent,
  perhaps asking for the cheapest fare to a
  destination. The customer does not have direct
  access to airline guides or booking systems, but
  the agent does, and will transform the customer's
  query into a series of enquiries to different
  systems, compare and consolidate the results, and
  give the customer the answer. If a service
  changes (the advent of the Eurotunnel booking
  system for example) only the agent needs to be
  aware of this, the customer can be completely
  unaware of it and yet can still benefit from the
  services which it offers.

8
A non-computing example

• The key point is that the client knows what
  questions he wants to ask (how to get to Paris)
  but is completely unaware of the work that the
  agent is doing on his behalf.

9
Within a computing context

• It is important to state that the 3LA model
  describes an application framework for developing
  on-line transaction processing (OLTP) systems.
  Whilst the concepts of separating logic into
  presentation, business rules and data management
  components applies equally well to batch
  processing and MIS/Data Warehousing systems, the
  rest of this paper is directed towards the
  framework in which OLTP applications should be
  developed.
• The Gartner Group separates the layers of a
  client-server application into presentation,
  function and data management. These functions can
  be partitioned in 5 different ways as illustrated
  in figure 2.

10
The Gartner Definitions of Client Server
Architectures
11
Within a computing context

• Depending on the technology chosen, an
  application may implement one or many of these
  scenarios.
• A 3LA is usually taken as supporting models 2 3
  (remote presentation/distributed function) and
  tending towards a 'thin client/thick server'
  model.
• This should be distinguished from a thick
  client/thin server model typified by Oracle
  Version 6 which would be seen as a classic 'two
  layer model' and described as model 4 in the
  Gartner model.

12
Layered models compared

• This figure compares a two and three layer
  models with the "traditional" mainframe model

13
What does a 3LA provide that a 2LA doesn't ?

• The separation of the business rules from the
  presentation layer (the user-facing front end
  normally a GUI) enables the business rules to be
  used by many different presentation layers. This
  might seem self-evident, but the fact that (in
  theory at least) a Web browser front-end can
  access the same functionality as a Power builder
  application provides the capability for reuse
  across many applications areas that do not share
  the same GUI code or even the same platform.
• The separation of the business rules from the
  data management functions provides you with the
  capability of implementing business rules that do
  not depend on the underlying data structure.
  Using our travel agent as an example, the
  business rule that describes how the question
  'what is the cheapest way to Paris on a Tuesday'
  is answered need not be dependent on knowing how
  the BR, channel tunnel and Sealink timetables are
  accessed.
• The addition of a third physical layer enables
  functionality that would previously have been
  "buried" within the client code to be made
  available in its own right. There are several
  potential advantages in this approach, including
  the ability to share common business logic (see
  below), and the fact that the code which
  implements this logic can be run on a robust and
  managed platform. This is particularly important
  where several different back-end systems must be
  accessed, since the desktop workstation is freed
  of the need to support multiple protocols.

14
Why would one want to use a 3LA?

• one would choose to use a 3LA whenever more than
  one of the following conditions apply
• There is a wish to reuse business functionality
  across many front-end systems and especially when
  the front-ends are written in different
  languages.
• The acquisition of data to display on the
  presentation layer comes from many sources
• There is complex processing to be done outside
  the back-end systems
• There are several different communications
  protocols involved
• There is potentially a large number of
  client/server users
• There is a network capacity limitation, and a
  consequent need to avoid SQL traffic
• There is a need to perform read-ahead and
  store-and-forward cacheing

15

• There is a more subtle advantage that a 3LA model
  has over a 2LA - namely that it supports the
  concept of the use of services rather than simply
  the accessing of data.
• Typically in a 2LA environment the presentation
  layer must know exactly what data it needs, where
  it is and how to access it. The presentation
  layer will read and write to the database
  directly. Thus whenever the data changes, the
  presentation layer will need to be amended.
• A 3LA model uses the concept of services (or
  agents in the previous analogy).
• This concept of having an "agent" to act on
  behalf of applications is one of the powerful
  architectural ideas which is made possible by the
  three-layer architecture as opposed to a simple
  client/server design.

16

• A service-based approach involves the creation of
  a set of processes which implement business
  functions which can then be used by any other
  process which needs that function. Examples of
  the functions involved include looking up a
  customer balance, updating address details,
  changing an employee's status, etc. This type of
  business logic has traditionally been built into
  individual applications, and has not been
  accessible from outside those applications.
• In the 3LA, the presentation layer calls upon the
  business rules in the middle layer to perform
  specific requests (e.g. 'add a customer' or
  'retrieve account balance'). The business rules
  determine how to perform the function 'retrieve
  account balance'. Consequently, when the
  processing to support the business rule changes
  then only the business rule code must be changed
  rather than the presentation layers that invoke
  the rule.

17
Applications share common services

• This figure illustrates the concept of many
  applications sharing a range of services

18
Two Approaches

• Data-everywhere approach.
• In this paradigm, the presentation layer is given
  access to data in the back-end systems. To make
  it easy for the presentation layer the data will
  usually be made available in an 'SQL-format' even
  if it is held as VSAM or DB2 (EDA/SQL is a good
  example of the 'data-everywhere' approach).
• API approach.
• In this paradigm the presentation layer has no
  direct access to back-end data. Instead, it calls
  upon a service (such as 'retrieve customer
  balance') without knowing or caring about where
  the data to support the request resides.
• It is up to each organisation to determine which
  model they wish to follow. Within MCL we are very
  strong on the API approach - to such an extent
  that our newest 3LA application (BQS - discussed
  later) does not have any SQL calls from the
  desktop application, all access is provided
  through services invoked by an API.

19
Why writing an application using a 2LA model is
easier than writing a 3LA?

• Less infrastructural work is required to build
  the required foundation for a 2LA than a 3LA
• Most current CASE tools tend to support a 2LA
  model rather than a 3LA one.
• Development tools (e.g. debuggers) are less well
  developed for 3LA languages than 2LA ones.

20
Why MCL is adopted a 3LA?

1. Give the appearance of integration
2. To support re-use across applications
3. To provide consistent process logic
4. To isolate users from the churn of functionality

21
a) Give the appearance of integration

• The Customer Services Assistants (CSA's) require
  access to a large amount of functionality and
  data to perform their jobs. They need to register
  faults, answer queries about bills, take change
  of address details, etc. MCL has a large number
  of 'back-end' systems that support these various
  functions.
• The time taken to train our CSA's on all the
  systems is becoming a significant bottleneck on
  deploying new staff in this area.
• By giving the CSA's a single, consistent
  interface regardless of the back-end system the
  training time and costs are reduced considerably.

22
b) To support re-use across applications

• Within MCL we have a large number of presentation
  systems to support the various user communities.
  These systems are often written in different
  languages and run on different platforms.
• By separating the presentation logic from the
  business logic we can increase the amount of code
  and functionality that can be reused across the
  various applications

23
c) To provide consistent process logic

• The large number of back-end systems within MCL
  means that the business process to support
  'update customer address' can be very
  complicated.
• Having decided once what the process should be we
  want each application to use the same code. Thus
  when the process changes (for example we reduce
  the number of systems that hold address from 15
  to 5) then only the service (middle) layer code
  need change not all the application layers that
  invoke the service.

24
d) To isolate users from the churn of
functionality

• Systems are usually upgraded/replaced to suit the
  requirements and needs of a specific user
  community. It is usually the case that there is a
  wider user community that is interested in the
  information but does not care which system is
  being used to supply it.
• For these users there are considerable benefits
  in isolating them from the churn of functionality
  that results when one system is replaced with
  another. Giving the user an interface independent
  of the system providing the data enables such
  differences to be concealed.

25
Summary Conclusions

• a) Implementing a 3LA is not simple. The
  technology is not yet at the stage where it can
  be employed 'straight out of the box'. You will
  need to employ good low-level technical people if
  you want to succeed.
• b) As with any new technology, you need to be
  sure that the benefits outweigh the risks. If you
  can afford to wait six months do so (and in six
  months time ask the same question again).
• c) The technology is a means not an end. It is
  easy to get drawn into the technology without
  appreciating the wider aspects.
• In fact, within MCL we feel that we have the
  technology under control and that the success or
  failure of the 3LA architecture is more dependant
  on organisational issues than anything else.

26
Summary Conclusions

• d) Make sure that you start small. Start with a
  pilot to ensure that the technology fits your
  skills and that your organisation is capable of
  dealing with the changes that the 3LA will bring.
  
• e) Don't convert an entire 'legacy' application
  to a 3LA overnight.
• Start by creating services 'on-demand' when they
  are required. It is perfectly reasonable for some
  users to continue to access the back-end systems
  via 3270 terminals whilst other users are given a
  GUI presentation.

27
Summary Conclusions

• f) Use your legacy functions wherever you can.
  Try and create wrappers around the existing code
  rather than rewriting all the code onto a new
  platform.
• g) Performance of a 3LA is surprisingly good.
  Whilst first impressions might suggest that 3LA
  means lots of connections between lots of boxes,
  all that is happening is that a 3LA makes
  explicit what is happening in the background on a
  2LA.
• Expect your 3LA application to perform as well as
  your 2LA and to scale up better.

28
Summary Conclusions

• h) A 3LA gives you a platform to implement
  time-dependant processing (e.g. only update the
  billing system when the provisioning system has
  accepted the order). In a 2LA model this type of
  processing is difficult to implement.
• i) Don't underestimate the culture change that
  the 3LA will require. It will take people longer
  than you realise to understand the implications
  of a 3LA on the way they design and implement
  systems.
• j) Be aware that 're-use' will not happen by
  accident, you will need to put in a program to
  ensure it happens.
• k) And finally..... remember that "in a journey
  of a thousand miles the first step is the
  hardest".

29
Part Two CORBA

• What is CORBA?
• The object management group (OMG)
• CORBA IDL
• For User Provider
• A way of phrasing
• The Basic Mechanics of issuing a request
• CORBA advantages
• Standards
• CORBA clients
• CORBA servers
• Other Middle ware

30
What is CORBA?

• CORBA (Common Object Request Broker Architecture)
  is a very general and open industry standard for
  working with distributed objects. We think it is
  an important new development in the field of bio
  informatics.
• CORBA was developed by the Object Management
  Group (OMG), a large non-profit consortium that
  includes the major software vendors (Sun, DEC,
  IBM, Apple, Hewlett-Packard, etc. etc.) as well
  as end users.

31
The Object Management Group (OMG)

• The Object Management Group, is a non-profit
  consortium created in 1989 with the purpose of
  promoting theory and practice of object
  technology in distributed computing systems.
• It aims to
• reduce the complexity
• lower the costs
• hasten the introduction of new software
  applications.
• Originally formed by 13 companies, OMG
  membership grew to over 500 software vendors,
  developers and users..

32
The Object Management Group (OMG)

• OMG realizes its goals through creating standards
  which allow interoperability and portability of
  distributed object oriented applications.
• They do not produce software or implementation
  guidelines only specifications which are put
  together using ideas of OMG members who respond
  to
• Requests For Information (RFI)
• Requests For Proposals (RFP)
• The strength of this approach comes from the
  fact that most of the major software companies
  interested in distributed object oriented
  development are among OMG members.

33
CORBA IDL

• To achieve language, site and platform
  independence, an interface to the objects is
  written in a specification language called CORBA
  IDL or shortly IDL.

34
FOR User Provider

• To the user of an object (e.g., an applet), it
  specifies the available data types, object types
  and their methods. To the provider, it specifies
  which objects and functionality have to be
  provided.
• TO a user, the IDL specification is a promise
  from the provider. To the provider, the IDL
  specification is an obligation to the user.
• Therefore, IDL specifications should be general
  and stable.

35
A way of phrasing

• CORBA is to object oriented computing what the
  World Wide Web is to documents.
• IDL is to CORBA what HTML is to the World Wide
  Web.

36
The Basic Mechanics of issuing a request
37
CORBA ORB Architecture
38
Components

• Object is a CORBA programming entity that
  consists of
• an identity
• an interface
• an implementation, which is known as a Servant.
• Servant is an implementation programming
  language entity that defines the operations that
  support a CORBA IDL interface.
• Servants can be written in a variety of
  languages, including C, C, Java, Smalltalk, and
  Ada.
• Client is the program entity that invokes an
  operation on an object implementation.

39
Components

• Object Request Broker (ORB) provides a
  mechanism for transparently communicating client
  requests to target object implementations.
• ORB Interface is a logical entity that may be
  implemented in various ways (such as one or more
  processes or a set of libraries). To decouple
  applications from implementation details, the
  CORBA specification defines an abstract interface
  for an ORB. This interface provides various
  helper functions.
• CORBA IDL stubs and skeletons serve as the
  glue'' between the client and server
  applications, respectively, and the ORB. The
  transformation between CORBA IDL definitions and
  the target programming language is automated by a
  CORBA IDL compiler. The use of a compiler reduces
  the potential for inconsistencies between client
  stubs and server skeletons and increases
  opportunities for automated compiler
  optimizations.

40
Components

• Dynamic Invocation Interface (DII) allows a
  client to directly access the underlying request
  mechanisms provided by an ORB.
• Dynamic Skeleton Interface (DSI)
• is the server side's analogue to the client
  side's DII.
• allows an ORB to deliver requests to an object
  implementation that does not have compile-time
  knowledge of the type of the object it is
  implementing.
• The client making the request has no idea
  whether the implementation is using the
  type-specific IDL skeletons or is using the
  dynamic skeletons.
• Object Adapter
• assists the ORB with delivering requests to the
  object and with activating the object
• associates object implementations with the ORB.
• can be specialized to provide support for certain
  object implementation styles (such as OODB object
  adapters for persistence and library object
  adapters for non-remote objects)

41
CORBA Advantages

• CORBA allows the interconnection of objects and
  applications, regardless of
• the computer language of the applications that
  provide or use the objects
• the machine architecture of the computers
  involved
• the geographical location of the computer
  (connection through the Internet)

42
Standards

• CORBA itself is an international standard, but by
  itself is not enough to build up systems out of
  software components.
• The OMG has wide-ranging efforts underway to
  standardize commonly used components.
• They fall apart in two areas
• Common Object Services
• Facilities

43
Common Object Services (COS)

• These are IDL specifications of basic
  functionality commonly needed to implement and
  use CORBA objects. The specifications are written
  in IDL. Important Common Object Services are
• Cos Naming
• Trader
• Cos Life Cycle
• Cos Query
• Property

44
Facilities

• These are IDL specifications of functionality
  commonly needed to implement complete
  applications. They are subdivided in two
  divisions
• Horizontal Common Facilities It is aimed at
  providing high level general functionality for
  working with objects. They include standards such
  as the User Interface and Information Management
  facilities.
• Vertical Market Facilities It offers more
  specific standards for working with objects in a
  particular business or scientific domain.
  Examples include Transportation, Accounting, and
  most importantly the Life Sciences.

45
CORBA Clients

• sequencing trace viewer
• EST clients
• Pfam (protein family and alignment database)
• Radiation Hybrid Map Viewer
• Querying the Radiation Hybrid Database with
  different clients
• There are various demos clients which access the
  EMBL database.

46
EBI CORBA Servers
Name Description Authors/ maintainers
EMBL servers EMBL Nucleotide Sequence Database servers EMBL CORBA
RHdb servers The Radiation Hybrid Database CORBA servers Rhdb team
EST specific servers EST clusters and alignment CORBA servers, EuroGeneIndexes Patricia Rodriguez-Tomé
EST specific servers EMEST, EST database corba server Juha Muilu
AppLab CORBA-Java based Application Wrapper Martin Senger
47
Comparison within CORBA, Legion and Globus
CORBA Legion Globus
Security Kerberos, SSL and others Kerberos v5 GSS API to come GSI offers GSS API, SSL X509 certificates, Kerberos
Accessing resources Methods on other objects Tools permit remote job submission, file staging Tools permit remote job submission, file staging
Resource discovery Offers naming and trading services Limited MDS handles resource information
Communication ORB used for method invocation LOIDs Nexus and globus_io used for remote calls
Fault tolerance None Checkpointing via libraries, C and C Can query for machine status
48
References

• Mercury's Experiences with 3 Layer Architectures
  ,Authors
• Alasdair Arthur - email 100016.1255_at_compuserve.co
  m
• Peter Burke - email 70314.2335_at_compuserve.com
• Version 1.0b ,November 1995
• OMG95a Common Object Request Broker
  Archictecture, OMG, July, 1995.
• OMG95b Common Object Services Specification,
  OMG 95-3-31, 1995
• Vinoski Steve Vinoski, CORBA Integrating
  Diverse Applications Within Distributed
  Heterogeneous Environments, IEEE Communications
  Magazine, February, 1997.