Technologies

The following technologies and specifications are instrumental in our framework, both as integral or replaceable components. Click on each one to read a concise description of the technology and our use of it:

• CIM

  CIM is a relatively new standard from the Distributed Management Task Force (DMTF) of the IETF that defines a complete, object-oriented and extensible information model to represent configuration data. It covers a vast spectrum of configuration information, ranging from the logical (such as device capabilities, operational status, software dependencies) to the physical (e.g., temperature, power supply, physical location, enclosure, cabling, card placement), and relates all these entities via associations. Logical and physical aspects of the same entity like the functionality of a chip as adapter and its packaging can also be related.

  Each group of conceptually equivalent entities is represented as a class, and each entity by an instance of the class, which is identified by the values of some of its properties, called key properties. These key properties allow associations to refer to one instance unequivocally. Classes can be derived to represent more concrete entities, like Ethernet adapters vs generic network adapters.

  Associations are one of the good points of CIM, as they can range between 1-to-1 to many-to-many, have attributes of their own, they can inherit from other association classes and point to derived classes. There are also weak associations, which make the identity of the weak end dependent on the other. For example, the identity of a file is not only dependent on its name, but also on the file system in which it is contained.

  Associations can expose very useful information. For instance, if we notice a decrease in the throughput of a web application, we can follow the association of this application with a web server, that of the web server with a file system associated with a RAID array, and finally discover that one of the disks associated with the RAID had a mechanical failure that caused the performance loss. For illustrative purposes, shows part of the hierarchy of the CIM classes used in our domain: system services and network interfaces.

• XML

  XML is a simplified subset of SGML proposed by the W3C, and loosely related to HTML, the language of the web. XML describes a family of tree-based hyerarchical tag-delimited text-based languages. Each of these languages can be defined with several classes of schemas and parsed by a compliant parser. XML allows its users to offload the parsing, processing and validating of input and output data to standard elements that can be easily replaced or implemented on hardware.

  XML is used extensively in our framework to interchange data and to allow convenient transformation by XSLT templates.

• XSLT

  XSLT is an W3C specification that defines a declarative, XML-based functional language that can represent arbitrary transformations on XML trees. The result can be XML or another text format, and there are many implementations, in Java, C, Perl, Python and even hardware appliances.

  XSLT is based on the concept of template rules, which act as functions called when they match a pattern in the input, and can be recursive.

• XForms
  XForms is the W3C standard designed to replace HTML forms, and also represent generic user interfaces. XForms accept XML data as input and output, allow spreadsheet-like real-time recalculation and offline validation, calculate data, change form format dynamically depending on data. This funtionality had normally been implemented in Javascript, which was both difficult and unreliable. Since XForms forms output XML, they can be easily integrated in XML processing pipelines.
• OWL
  OWL is an W3C standard ontology language which represents formally knowledge domains organized as hierarchical classifications and supports reasoning tasks on them, such as concept satisfiability and consistency. OWL supports three flavors, OWL Lite, OWL-DL, and OWL Full, which represent various compromises between expressivity and computability. We chose OWL-DL as the format for our ontologies. Among the OWL flavors, OWL-DL has the best balance between expressivity and efficiency; Lite is too restrictive and Full is undecidable and inefficient. All are based on description logics, that are fragments of first order logic (FOL), in turn, propositional logic with existential and universal quantifiers. Full FOL is not used because of its undecidability and computational intractability
• CORBA
  CORBA is an body of OMG (Object Management Group) specifications with the common purpose of enabling seamless interoperability of software components, and ensuring that such components, written in several languages, are able to communicate transparently in a distributed environment. The attributes and methods of the objects of this components are described in IDL, a interface description language akin to C++. Based in this description, code-generation utilities produce glue code for both clients and servers in their respective languages. This glue code redirects standard local calls to an ORB (Object Request Broker), usually a linked library, which has the responsibility of calling remote objects. CORBA specifications also include an efficient binary protocol (GIOP) for remote communications among ORBS.
• Web Services
  Web Services Web Services are web-accessible services defined by a series of W3C specifications which include:

  • SOAP.- An XML-based envelope format to wrap Web Services messages for transfer across existing transport protocols (like HTTP).
  • WSDL.- An XML-based message description format that defines the operations supported by a service, the input and output messages supported by each operation and, finally, the XML format of these messages.
  • UDDI.- A publication service for WSDL descriptions and other metadata about Web Services.

  The Web Services suite of specifications is used for two different, but similar, purposes: to expose interoperable interfaces to remote objects, much like CORBA, and to implement message-based architectures (as opposed to object, remote-procedure-call based). The latter results in looser-coupled interfaces than those of CORBA, in which changing the message format is less prone to produce client breakage.