Abstract

Middleware is a classical component of large heterogeneous distributed systems. The history of middleware is rooted in software engineering, based on the observation that programming abstractions can do two important things at the same time: (1) They can help to make programming more efficient by providing support for tasks that have to be solved repeatedly. (2) They can provide abstractions that hide heterogeneity, so that applications using these abstractions can communicate regardless of differences on lower layers.

Tools Shape Your Mind

If the only tool you have is a hammer, you tend to see every problem as a nail.

Abraham Maslow

Tools Should Change…

• …so should your mind!
• Computers moved from tools to models
  • early computer applications were simple and isolated tasks
  • today's businesses are build around what computers can do
  • IT architects have become very influential in how well a business works
  • IT architects are believed to know how what reasonable architecture is
• The complexity of problems has increased
  • Operating Systems were built for local computations
  • Distributed Systems were built for cooperating computers
  • what exactly should support cooperating people/businesses?

Tool Fundamentalism

• Adapting to a changing environment can be challenging
  • re-shaping the way you think about problems
  • learning new skills and tools
  • some people like change and new ideas and re-structuring their minds
  • but other people only do it when they really have to do it
• Tools can be bent
  • you can program FORTRAN in any language!
  • you can program object-oriented in any language!
  • tools should provide good support for the task they were built for
  • tools should provide feedback when they are misused
  • in the end, it is the users responsibility to use a tool properly

Boundary Objects

• Mediator between strategists and IT implementers
  • strategists tend to ignore the impact of implementation-level issues and decisions
  • IT implementers tend to ignore the longer term and wider focus perspective of their work
• Sound knowledge at both interfaces is required
  • there must be good reasons for a certain design or tool
  • there must be good reasons against a certain design or tool
  • highly skilled people need to be convinced rather than being forced
• Tools for being a better boundary object
  • most tools are designed to work for one set of customers
  • being a boundary object can be a tough job
  • SSME@UCB is working towards building better tools

Operating Systems

• Early computers were stand-alone systems
  • programming had to be done on a very low level
  • even the concept of device drivers was a step forward
• OSs were modularized for extensibility and maintainability
  • early examples of modular software systems
  • operating system design was a hot research field in the 80's & 90's
  • message passing (rather than APIs) was one proposed design for OSs

Distributed Operating Systems

• Operating Systems were designed to run on a single machine
• Distributed operating systems should hide a complex resource infrastructure
  • the ideal was to be able to program and operate a cluster of machines as one computer
  • the two main problems were resource management and programming abstractions
• Distributed operating systems never took off
  • Distributed File Systems for using network disks
  • programming was too specialized and probably too complicated

Distributed Systems

• Layered on top of Operating Systems
  • became popular with the advent of computer networking
  • providing higher-level abstractions than Distributed Operating Systems
• Definition these days is vague and the term has become unpopular
  • too many things have become distributed systems (The Network is the Computer)
  • research is still going on, but under different brand names
• Distributed systems probably are closely coupled systems
  • applications in a distributed environment that can be regarded as one application
  • middleware has emerged as how distributed systems are being built
  • loosely coupled systems probably do not fall into that category

Beyond Distributed Systems

• Not yet an established name for this field
  • Service Oriented Architecture (SOA) is the current buzzword to use
  • Services Science may become an established field in the future
• Loosely coupled vs. closely coupled
  • cooperating components without a single point of control
  • versioning and extensibility play a key role (independent deployment)
  • mapping between different models (subsets of models may be sufficient)
• These new applications introduce many challenges
  • evolving existing Distributed Systems concepts may be an answer
  • introducing other ways of building applications may be an answer
  • the decision what is better has not yet been made
  • it can be very hard to see where people are coming from and where they want to go

Anyware

• Middleware became popular in the 80's
  • any software between the operating system and applications
  • first used for distributed applications
• Very loosely defined, very little meaning
  • everything that should be reused has been put into middleware frameworks
  • mainly programming abstractions which should be reusable
  • one very popular candidate is Remote Procedure Call (RPC)
• RPC is good and bad
  • as a programming abstraction, it is useful (distribution of program parts)
  • as a modeling abstraction, it is dangerous (close coupling)
  • RPC is not bad per se, but RPC as a paradigm has consequences

RPC

RPC and Middleware

• RPC is a very fundamental mechanism
  • Remote Method Invocation (RMI) is the object-oriented extension
  • messaging infrastructures sometimes are also built on top of RPC
• RPC leaves a lot of questions open
  • how to find peers to connect to
  • how failure and recovery should be handled
  • whether there is some registry of servers and procedures
• Middleware often addresses all the questions

RPC-Oriented Middleware

• RPC is a dangerous hammer
  • procedures typically are written for small tasks
  • procedures typically have simple interfaces
  • the complexity is exposed as the number of procedures
  • interaction with such a module requires using all these interfaces in the right way and sequence
• Granularity of software is an important consideration
  • fine-grained software has a lot of interdependencies and is one big application
  • coarse-grained software should minimize interdependencies and result in cooperating applications
• Middleware is designed by IT specialists
  • it addresses the question how distributed applications can be programmed more easily
  • this may simply mean: how can I distribute my workload over a number of servers?
  • it does not necessarily answer the question whether this model is appropriate from other viewpoints

Viewpoints

Boundary Object Viewpoints

• RPC is a natural choice from the computational viewpoint
  • this is how systems have been designed for a long time
  • why not continue to build them like this on a larger scale?
• Document engineering is better from the enterprise viewpoint
  • this decision has to be reflected in the computational design as well
  • without commitment and understanding, models will be misinterpreted
• Facilitating communications and understanding is a key point
  • there must be some shared concepts people can refer to
  • communicating the implications of design decisions

Two Implementations

1. The service that has to be implemented is simple
   • how to get a pen from the office supply office
2. IT people come up with a highly detailed set of RPCs
   • different calls for submitting the type, the account, the office number, …
   • access is handled by getting the shelf number and other service internals
   • if not called in right sequence, the process fails
3. Enterprise people come in and want a service-oriented interface
   • the fine-grained interface has to be replaced by a coarse-grained one
4. IT people walk away and redesign their interfaces
   1. all information is now in one big document, returned is another big document (including a map to the shelf)
   2. alternatively, all non-essential information could be removed (in: account; out: pen)

Object Request Broker (ORB)

• Local interface for remote method calls
  1. calls to remote methods are dispatched to the ORB
  2. the ORB locates the remote object
  3. the remote ORB activates the remote object (if necessary)
  4. both ORBs communicate to transmit call and result
  5. the ORB locally delivers the results
• CORBA is the specification around ORBs
  • ORBs can be implemented in any way deemed appropriate
  • Inter-ORB Protocol (IOP) lets ORBs communicate in a standardized way
  • before CORBA 2, ORBs were closed rather than open

ORB Architecture

Distributed OO Programming

• RPC on steroids
  • based on object-orientation rather than imperative languages
  • provides platform-independent RPC
  • provides an environment for managing RPCs
• CORBA has its roots in a closed world view
  • CORBA 1 does not provide inter-ORB communications
  • CORBA 2 does not provide support for software components
  • CORBA 3 mimics EJB or .NET

*IOP

• CORBA is about exchanging messages
  • objects have interfaces with exposed methods
  • method calls (and replies) are transmitted over the network
• Inter-ORB Protocol (IOP) describes how ORBs communicate
• General IOP (GIOP) is an abstract definition of the protocol
• Internet IOP (IIOP) defines how to layer IOP on top of TCP
• XML IOP (XIOP) encodes IOP as XML messages over HTTP
  • another great example of random everything-over-anything layering
  • if the whole environment if governed by CORBA, why bother to use XML?

The CORBA Hammer

• Middleware is a religion and a cash-cow
  • because it is extremely complex, it is also extremely versatile
  • implementing good or bad architectures does not depend on the middleware
  • buy-in into a specific middleware may generate a lot of programmer hours
• CORBA architectures tend to be brittle and closed
  • they are open (to anybody using CORBA)
  • CORBA typically results in very tightly coupled systems
  • acceptable for a subset for problems

History Repeats Itself

• Traditional Middleware often solves problems with tightly coupled distributed systems
• Some people have done too much hammering
• The Web did not succeed because of pointy brackets
• All tools are dual use tools, so tool names do not mean a lot
• Boundary objects should be able to promote responsible tool use