Swipe to navigate through the chapters of this book
This chapter describes two types of service management applications. The first type is an application that follows the source, collector, interpreter, and display architectural design pattern. A service knowledge management system (SKMS) is used as a detailed example. Most service management applications follow this pattern. The other type described is a policy or business process management application. This also follows the source, collector, interpreter, and display pattern, but it also has more complicated transactions that may require more complex interfaces. Cloud implementations both benefit and challenge implementations of both types.
Please log in to get access to this content
To get access to this content you need the following product:
ITIL Service Transition. London: TSO, 2011. 181–195.
For the full list, see www.itil-officialsite.com/SoftwareScheme/EndorsedSoftwareTools/EndorsedSoftwareTools.asp . Accessed June 2014.
These are architectural reasons for using a cloud. There are, of course, also business and administrative reasons, such as capitalization and amortization strategies.
Tapping into the Domain Object Model (DOM) in the browser is usually more effective, but that is another subject entirely.
Marvin Waschke. Cloud Standards. New York: Apress, 2012. Pages 226–232 discuss TCP/IP.
Marvin Waschke. Cloud Standards. New York: Apress, 2012. Pages 245–259 are a summary of the HTTP.
SOAP once stood for Simple Object Access Protocol. SOAP has evolved to be not simple, not confined to object access, and not exactly a protocol. Therefore, the World Wide Web Consortium (W3C) SOAP working group declared SOAP no longer an acronym. REST stands for Representational State Transfer. Both these are discussed in more detail in the next section, “Data Collection and Consolidation.”
More on this in a moment, but a simple example of a model problem is a financial asset application that differentiates between servers and desktops and a configuration management application that treats both as computers. If the data collector is simply a pass-through, the data interpretation may have three entities (servers, desktops, and computers) that are hard to interpret.
OData is a standard initially developed by Microsoft and now maintained by Organization for the Advancement of Structured Information Standards (OASIS). See https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=odata . Accessed July 2014.
SOAP once stood for Simple Object Access Protocol. As SOAP developed, it became neither simple nor primarily used for object access, so now SOAP officially is no longer an acronym. The protocol is now a World Wide Web Consortium (W3C) standard. See www.w3.org/TR/soap/ . Accessed July 2014.
See Marvin Waschke. Cloud Standards. New York: Apress, 2012, pp. 229–232, for some of the issues involved in connection-oriented and non-connection-oriented interaction.
HTTP has drifted almost as far from its roots as SOAP. HTTP is now used in ways that do not much involve hypertext, passing everything from relational data to blocks of code.
cURL is a command-line client for Uniform Resource Locators (URLs) written in C and available on many platforms. On the command line, it is spelled curl. cURL sends and receives raw HTTP from a command line, and it is all that is needed to use REST, although for most purposes, more elaborate software is employed. Because it is simple and offers a transparent window into activity on the wire, cURL is useful for testing and debugging. For further information, see http://curl.haxx.se/ . Accessed September 2015.
Marvin Waschke. Cloud Standards. New York: Apress, 2012. Pages 174–185. This book describes SCSI and various forms of network storage.
The Distributed Management Task Force has published a standard that addresses some aspects of this problem. See http://dmtf.org/standards/cmdbf . Accessed July 2014.
See http://dmtf.org/standards/cim . Accessed July 2014.
For more on Teiid, see http://teiid.jboss.org/about/ . Accessed September 2015.
In this case, backward compatibility means that an SKMS data collector built to work with the API of an early release of an application should work equally well with a later release without modification to the collector. In addition, the information in the SKMS display from a later release should be as valuable as the information from an earlier release. The later requirement is often more difficult for an application builder to maintain than the former. The first requirement places constraints only on the form of the API. The latter requirement also places constraints on changes to the data structure of the application, which can seriously hold back the evolution of the application.
See http://dmtf.org/standards/cmwg . Accessed July 2014.
Statelessness and idempotency are discussed in Chapter 13. An idempotent message can be repeated with the same effect as issuing it only once. Web applications that request that you click only once when submitting a transaction are not idempotent. The danger is that the second click will cause the transaction to be repeated.
- The Edifice
- Sequence number
- Chapter number
- Chapter 7