COTS Interoperability

1
COTS Interoperability

• Jesal Bhuta
• jesal_at_usc.edu
• USC Center for Systems Software Engineering
• http//csse.usc.eduJanuary 29, 2007

2
Outline

• Motivation and Context
• COTS Interoperability Evaluation Framework
• Demonstration
• Conclusion and Future work

3
COTS-Based Applications Growth Trend

• Number of systems using OTS components steadily
  increasing
• USC e-Services projects show number of CBAs rise
  from 28 in 1997 to 70 in 2002
• Standish groups 2000 survey found similar
  results (54) in the industry Standish 2001 -
  Extreme Chaos

CBA Growth Trend in USC e-Services Projects
Standish Group Results
4
COTS Integration Issues

• COTS products are created with their own set of
  assumptions which are not always compatible
• Example Java-Based Customer Relationship
  Management (CRM) and Microsoft Access integration
• CRM supports JDBC, MS Access supports ADODB
• CRM assumes database always active, MS Access
  requires to be activated

5
Case Study Garlan et al. 1995

• Develop a software architecture toolkit
• COTS selected
• OBST, public domain object oriented database
• Inter-views, GUI toolkit
• Softbench, event-based tool integration mechanism
• Mach RPC interface generator, an RPC mechanism
• Estimated time to integrate 6 months and 1
  person-year
• Actual time to integrate 2 years and 5
  person-years

6
Problem Reduced Trade-Off Space

• Detailed interoperability assessment is effort
  intensive
• Requires detailed analysis of interfaces and COTS
  characteristics, prototyping
• Large number of COTS products available in the
  market
• Over 100 CRM solutions, over 50 databases 5000
  possible combinations
• This results in interoperability assessment being
  neglected until late in development cycle
• These reduce trade-off space between
• medium and low priority requirements chosen over
  cost to integrate COTS

7
Statement of Purpose

• To develop an efficient and effective COTS
  interoperability assessment framework by
• Utilizing existing research and observations to
  introduce concepts for representing COTS products
• Developing rules that define when specific
  interoperability mismatches could occur
• Synthesizing (1 and 2) to develop a comprehensive
  framework for performing interoperability
  assessment early (late inception) in the system
  development cycle

Efficient Acting or producing effectively with
a minimum of unnecessary effort Effective
Producing the desired effect (effort reduction
during COTS integration)
8
Proposed Framework Scope

• Specifically addresses the problem of technical
  interoperability
• Does not address non-technical interoperability
  issues
• Human computer interaction incompatibilities
• Inter/intra organization incompatibilities

9
Motivating Example Large Scale Distributed
Scenario

• Manage and disseminate
• Digital content (planetary science data)
• Data disseminated in multiple intervals
• Two user classes separated by distributed
  geographic networks (Internet)
• Scientists from European Space Agency (ESA)
• External users

10
Interoperability Evaluation Framework Interfaces
11
COTS Representation Attributes
12
COTS Definition Example Apache 2.0
13
COTS Interoperability Evaluation Framework
14
Integration Rules

• Interface analysis rules
• Example Failure due incompatible error
  communication
• Internal assumption analysis rules
• Example Data connectors connecting components
  that are not always active
• Dependency analysis rules
• Example Parent node does not support
  dependencies required by the child components
• Each rule includes pre-conditions, results

15
Integration Rules Interface Analysis

• Failure due incompatible error communication
• Pre-conditions
• 2 components (A and B) communicating via data
  /or control (bidirectional)
• One components (A) error handling mechanism is
  notify
• Two components have incompatible error
  output/error input methods
• Result
• Failure in the component A will not be
  communicated in component B causing a permanent
  block or failure in component B

16
Integration Rules Internal Assumption Analysis

• Data connectors connecting components that are
  not always active
• Pre-conditions
• 2 components connected via a data connector
• One of the component does not have a central
  control unit
• Result
• Potential data loss

Component A
Component B
Pipe
17
Integration Rules Dependency Analysis

• Parent node does not support dependencies
  required by the child components
• Pre-condition
• Component in the system requires one or more
  software components to function
• Result
• The component will not function as expected

18
Demonstration
19
Framework Application to Motivating Example

• Identify interface mismatches between components
• Internal assumption mismatches between components
• COTS dependency verification
• Recommends connectors to be used for voluminous
  data intensive interaction

20
General Mismatches Resolution Strategies

• Online bridge
• In this method a new component (Br) is introduced
  to resolve packaging conflicts between two
  components (e.g. JDBC-MySQL Connector)
• Offline bridge
• One component being integrated is persistent
  data-store (e.g. RTFtoHTML)
• Wrapper
• One component encapsulates a wrapper W (with
  similar functionality as of Online-Bridge)
• Mediator
• Connector C is capable of supporting several
  alternatives for given packaging commitments

21
General Mismatches Resolution Strategies

• Intermediate representation
• Connector C simultaneously supports conversion
  amongst multiple data formats by first converting
  to a format of its own commitment (e.g. Corba)
• Unilateral negotiation
• One of the components supports multiple packaging
  methods
• Bilateral negotiation
• Both components (A and B) support multiple
  packaging methods. Policy is negotiated at
  execution time or runtime (e.g. a web-browser and
  a secure server)
• Component extension technique
• One of components provides supports extension
  mechanisms (e.g. Mozilla firefox)

22
Example Deployment Diagram
23
Questions