Date post: | 19-Jan-2016 |
Category: |
Documents |
Upload: | alfred-simmons |
View: | 214 times |
Download: | 0 times |
A middleware-neutral common services software infrastructure
Steve Wampler
National Solar Observatory
ICALEPCS’2005
What is ATST?
•7X photon collecting power
•Unvignetted light path
•Prime focus heatstop/occultor
•Integrated 1300+ actuator AO
•Rotating Coudé lab
•Hybrid enclosure
•Haleakala, Maui, Hawaii
Advanced Technology Solar Telescope
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
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 CORBA’s CCM)
• Allows application developers to focus on functionality
• Provides consistency of use• System becomes easier to maintain and manage
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)
What’s 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, you’re 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
ATST Common Services
Many services available
Service Layers
• Service tools• Component-specific data
• All knowledge of service implementation isolated by the respective Service Tool
• Tool chaining keeps tools small and focused
• Uniform access from Components• Bridge between functional and technical
Containers/Components
Toolbox Loaders
Toolbox Loader
Palate of Service Tools
Toolbox
Shared Private
An Example: Event Service
ContainersetToolBoxLoader(“atst.cs.ice.IceToolBoxLoader”);
setToolBoxLoader(“atst.cs.jaco.JacoToolBoxLoader”);
ComponentEvent.post(eventName, eventMessage);
ToolboxeventTool.post(getTimestamp(), appName, eventName, eventMessage);
ICEEvent Service
Tool
JacORBEvent Service
Tool
An Example: Log Service
ComponentLog.warn(“M2 temp overload);
ToolboxlogTool.log(getTimestamp(), appName, “warning”, message);
Buffered DBLog Service
Tool
PostLog Service
Tool
PrintLog Service
Tool
• Three service tools chained
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
But wait, there’s 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