A middleware-neutral common services software infrastructure

1
A middleware-neutral common services software
infrastructure

• Steve Wampler
• National Solar Observatory
• ICALEPCS2005

2
What is ATST?
Advanced Technology Solar Telescope

• 7X photon collecting power
• Unvignetted light path
• Prime focus heatstop/occultor
• Integrated 1300 actuator AO
• Rotating Coudé lab
• Hybrid enclosure
• Haleakala, Maui, Hawaii

3
Observatory SW Trends

• Away from custom toward
• Commodity hardware (PC), distributed systems
• Commodity OS (Linux, FreeBSD, etc.)
• Common Services infrastructure
• COTS/Community communication middleware
• Standard software models (tiered, separation of
  technical and functional architectures,
  container/component (ala .NET, EJB, CORBA CCM)
• Common high-level models and architectures

4
Common Services

• Common framework for all observatory software
• ALMA ACS is excellent example
• ATSTCS draws from general ACS model
• Much more than just a set of libraries
• Separates technical and functional architectures
• Provides bulk of technical architecture through
  Container/Component model (like .NET, EJB, and
  CORBAs CCM)
• Allows application developers to focus on
  functionality
• Provides consistency of use
• System becomes easier to maintain and manage

5
Communication Middleware

• Avoids need to write communication infrastructure
  in-house
• Less effort
• Less in-house expertise required
• Access to outside expertise
• Benefit from wide-spread use
• Often provides rich set of features
• Supports actions required to run in a distributed
  environment
• Lots to choose from (both commercial and
  community)

6
Whats wrong with Middleware?

• 900-lb gorilla
• Promotes dependency on small set of vendors
• Hard to control direction
• Typically deeply integrated into common services
• Difficult to change once integrated (lots to
  choose from, but once you choose, youre stuck)
• Sometimes obsolete before deployment
• Adopting standards instead of specific packages
  can help, but
• Standards not particularly agile
• Can still get stuck as technology advances

7
ATST Common Services
8
Many services available
9
Service Layers

• Uniform access from Components
• Bridge between functional and technical

• Service tools
• Component-specific data

• All knowledge of service implementation isolated
  by the respective Service Tool
• Tool chaining keeps tools small and focused

10
Containers/Components
11
Toolbox Loaders
12
An Example Event Service
ICE Event Service Tool
JacORB Event Service Tool
13
An Example Log Service
Buffered DB Log Service Tool
Post Log Service Tool
Print Log Service Tool

• Three service tools chained

14
How well is ATSTCS working?

• Approach seems successful (demonstrated by alpha
  release of Common Services with ICE and CORBA
  versions of services)
• Choice of service tool has no impact on component
  development
• Already helped in unexpected ways
• ICE/CORBA service tools easy to write
• Both similar architectures
• Both align well with access helper models
• Less aligned services likely to be harder
• Changes are well isolated at service tool layer,
  however

15
But wait, theres more

• Service tools can be changed dynamically
• Can customize tool sets on a per Container or
  even per Component case
• Easy to compare effects of middleware choices
• Can more easily pick different services from
  different middleware
• Can help with system migration as software
  technology advances and to help integrate legacy
  systems
• E.g. chain ICE and CORBA tools together
• Avoids need for big bang system upgrades