Software engineering and Middleware : a Roadmap Wolfgang Emmerich

1
Software engineering and Middleware a
Roadmap Wolfgang Emmerich

• Presented By
• Sagar Morabia
• CS589_Fall2006

2
Distributed systems

• Why
• - Time available for designing new systems is
  limited
• - Time available for providing new services
  is decreasing.
• Fault-tolerant
• Scalable
• Complex
• Multiple points of failure
• A better fit for integrated, highly scalable,
  and adaptable systems

3
Middleware

• Applications
• ? Middleware ?
• Operating system
• Hardware
• Infrastructure that allows multiple processes to
  interact across the network. Its basic role is
  that of co-ordination and communication. It
  implements session and presentation layer.

4
Typical Middleware Requirements

• Network Communication
• Coordination
• Reliability
• Scalability
• Heterogeneity
• Enhanced Security
• Application Oriented services
• Interaction with other network services.

5
Network Communication

• Implement lower level network layers
• - DS are usually built on top of transport
  layer.
• Provide higher level primitives
• - app engineers should be able to request
  parameterized services
• Support marshalling unmarshalling

6
Co-ordination

• Support concurrent execution by synchronization
  based on threading policies
• - deferred synchronous client
• - asynchronous - server
• Restore component states based on activation
  policies.

7
Reliability

• Handle individual requests
• - Best Effort
• - Atmost once
• - Atleast once
• - Exactly Once
• Handle multiple requests
• - K reliability
• - Time outs
• - Totally Ordered
• Accommodate different levels and extensions
  (reliable delivery, order preservation, ACID
  properties)
• Support replication

8
Scalability

• Load Balancing
• -Access transparency
• -Location transparency
• -Migration transparency
• -Replication transparency

9
Heterogeneity

• Integrate elements from various contexts
• -hardware
• -software
• -operating system
• -middleware
• Support interoperability

10
Middleware Solutions
11
Middleware Solutions .
12
Weakness

• Transactional
• - it creates undue overhead if there is no
  use of transactions.
• - marshalling and unmarshalling needs to be
  done manually.
• - portability is reduced due to no
  standardized approach for defining the services
  offered by server components
• MOM
• - Supports only at-least once reliability
• - Does not support ACID properties
• - Limited support for scalability and
  heterogeneity.
• RPC
• - Not scalable and fault tolerant
• - Not reflexive

13
State-of-art

• Flexible Middleware
• -Trading using a trader in place of naming
  service/mechanism
• -Reflection mechanism to discover the types of
  the classes and define method invocation at
  runtime
• -Application-level Transport Protocol
• Scalable Middleware
• -Replication
• Real-time Middleware
• - Lack on prioritization on requests
• - High memory requirements
• Middleware for Mobile Computing
• - Lack of continuous bandwidth availability
• - Problems of network outages
• - Increased complexity of software and size
  efficient data representation

14
Future Research

• Requirements Engineering
• -quantification of non-functional goals
• -adaptation to unstable requirements
• Software Architecture
• -addressing global properties and non functional
  requirements
• -calibrated models for validation
• -Distributed software engineering research
  needs to identify notations, methods and tools
  that support architecting. Research needs to
  provide methods that help software engineers
• to systematically derive software
  architectures that will meet a set of
  non-functional requirements and overcome the
  guesswork that is currently being done.
• Design
• -development of middleware design notations,
  methods, and tools

15
Middleware in Embedded Software

• Embedded software
• -specialized
• -demanding QoS on certain subdomains
  (telecommunications, multimedia, command control
  systems)
• Middleware
• -simplify composition and configuration of
  distributed systems
• -limitations exist (lack of real-time features
  prioritization, performance optimizations,
  non-functional requirement support, heavy memory
  requirements)
• -future is promising (industry supported
  flexible, adaptable, optimized, and standardized
  infrastructures, e.g Real-time CORBA, TAO)

16
Likes and Dislikes in the paper..

• Likes
• - One of the better roadmap papers.
• - Systematic
• - timelined
• - Good identification of relation between SE
  and MW.
• - Future needs well identified.
• Dislikes
• - No explanation of relation between SE and MW
• - Security aspect has been ignored.

17
Discussion

• Thank You