Navigation:
Documentation
Archive



Page Tree:

Child pages
  • Workshop Discussion Draft 1.0 - The Cloud

This wiki space contains archival documentation of Project Bamboo, April 2008 - March 2013.

Skip to end of metadata
Go to start of metadata

PLEASE READ - WORKSHOP DISCUSSION DRAFT - WORK IN PROGRESS

This document is version 1.0 of the Workshop Discussion DRAFT of the Bamboo Program and shall be used as the basis for work in Workshop 4. The purpose of this document is to frame a dialog among participants and as such, share preliminary and provisional information regarding the Bamboo Program. This will allow institutions and organizations participating in the Bamboo Planning Process to help determine (1) the long term future of Bamboo and, most importantly, (2) define what activities Bamboo will carry out in its first three year implementation phase (from 2010-2012). Unlike previous versions, this draft is designed to solicit input from the participants taking part in Bamboo Workshop 4. Changes, edits and recommendations collected at and immediately after Workshop 4 shall be incorporated into the Bamboo Program Document v1.1.

Please note that we are updating this document frequently based on wide ranging input from the Bamboo community. These updates are indicated as ".1", ".2", ".3", etc updates. In addition, we will occasionally make major document revisions. These are noted as "1.X", "2.X", and so forth. Between major document revisions there may be some inconsistencies in language used between the sections of the document.

The content and direction expressed within the sections of this document shall be considered as provisional and will be subject to potentially substantial change between this version and the final edition of the Bamboo Program slated for release in Fall 2009.


4. The Cloud


Table of Contents



The core of our approach centers around services and a cloud model of delivery. By using this admittedly nebulous and sometimes confusing term, we're introducing more than simply an approach to sharing services, gadgets or resources; we're expressing an infrastructure direction that minimizes risk to any one institution, is inherently redundant, has the potential to be of low cost to maintain, and introduces the potential for broad adoption across institutions, organizations and geographical boundaries in a sustainable and reliable manner. Although at a technical level, most of the pieces in this section can exist outside of a cloud approach, it is in tying them together for the common good of the Bamboo Community and the arts and humanities as a whole where collective value is gained. Therefore, we've opted to cluster all of these elements together within the notion of The Cloud.
While the term 'service' may be used to describe a broad or general operational capability (e.g., a social bookmarking service, an interlibrary loan service, an e-mail service, an academic computing support service, or other forms of technical expertise), the term is used in a narrower sense in this section of the Bamboo Program Document. Services, in the sense intended here, are relatively small units of software that deliver a set of capabilities grouped to most flexibly facilitate (a) interoperability with other software and/or digital content; and/or (b) combination and recombination with other services in support of multiple tasks or workflows.

Services are usually "under the hood" components of digital tools or applications with which a person engages directly. Tools and applications are relatively larger aggregations of software, and may be composed partly or wholly of services. A familiar example might be Google's mapping service, which is accessed by programmers and web page designers using the Google Maps API (Application Programming Interface). Those who use Google mapping services to find their way to a restaurant or an archaeological excavation or a conference on 18th century French literature might use a web browser (a tool) to view a web page (a digital resource created for display using the tool) that calls on the Google Maps API to display the portion of the page that is a map; the service API exists at some remove from the user's perspective (i.e., "under the hood"). Similarly, the services described in this section may be closely related to or integrated with tools, but are not end-user oriented tools themselves. This document's Section 3.4, "Tools and Content Guide" further describes Bamboo's relationship to digital tools and content sources that are closer to the practice of scholarship than "services" in the sense intended here.

This Shared Technology Services section of the Bamboo Program Document begins with two sub-sections that address the "under the hood" character of services.

First, the Services Atlas will be a mechanism to link these "under the hood" elements to things that are more familiar to those who seek technology that benefits scholarship. Faculty and librarians in the arts and humanities disciplines, with the exception of those who have particular interests in the nuts-and-bolts of technology, are generally less concerned with "services" per se, and more concerned with tools and digital content; with the way tools and content can be applied to the constituent steps or activities of scholarship; and with the larger concepts, issues, and goals of scholarship. The Services Atlas is intended to serve as a bridge between levels of detail and perspectives native to Bamboo's multiple communities, so that scholars who wish to explore the technologies they use or contemplate using can trace from descriptions and artifacts that are familiar, all the way into the detailed models and specifications that are usually of most interest to technologists. Similarly, the Services Atlas will offer a means for technologists (and their funders and managers) to trace the software artifacts they build (or fund or manage) to the broad or specific ways that technology is adding value to scholarship.

Second, the Bamboo Exchange will provide a means for those engaged in scholarship to make connections that will help them to advance their work using services. The Bamboo Exchange will enable scholars to find tools and digital methodologies of value and interest to them, and expertise to help them build or use services that can enable or enhance those tools and methodologies to better fit scholarly need.

The latter sub-sections of the Shared Technology Services section of the Program Document address some of the logistical aspects of identifying, refining, and making services available for use (Services Lifecyle), and partnering with extant tools projects, digital archives, and others to broaden the field of easily interoperable digital aids to arts, humanities, and interpretive social sciences scholarship (Tool and Application Alignment Partnerships and Content Interoperability Partnerships).

4.1. Services Atlas

The Services Atlas records and delivers community input (Scholarly Narratives, Recipes, Activities, Tool examples, Content/Resource examples, Service Families, Service Candidates, Service Contracts, and extant Services - including community-contributed references to information outside the formal bounds of Bamboo) in easily updated, linked, annotatable forms that may be mixed, matched, categorized, and re-categorized in order to render the community's understanding of scholarly practice accessible from the multiple perspectives of diverse stakeholders native to Bamboo. Dynamic ability to incorporate and view evolving input and analysis, and quickly and clearly draw connections to broader context, will benefit faculty, librarians, funders, institutional leaders, technical architects, and service developers. These varied views of a changing landscape will enable informed governance by key stakeholders in arts, humanities, and interpretive social sciences scholarship. The services atlas is not a user interface, web page, or application; it is exposed as a set of services that may be presented in a tool, page, portal, or interface of one's choice, including but not limited to the Bamboo Exchange.

A Service Atlas is, for Bamboo's purposes, a gateway to a collection of information - some general some detailed - that in its expression and linkages permits individuals with different interests, skills, experience, and perspectives to understand the nature and utility of services, their purpose and relevance, the tools that incorporate them, and the body of work they are meant to support. A Service Atlas is intended to help faculty, librarians, funders, institutional leaders, technical architects, and service developers to navigate a large collection of information at the level of detail that will most effectively illuminate understanding from the viewer's or user's perspective. The services atlas is not a user interface, web page, or application; it is exposed as a set of services that provide access to information that may be presented in a tool, page, portal, or interface of one's choice, including but not limited to the Bamboo Exchange.
The Bamboo Services Atlas will fulfill a number of purposes:

  1. Identify Existing Services: Provide a mechanism for characterizing and discovering extant services that support scholarly practice (such a mechanism is often called a "services registry"). Characterization may include expert review from one or more perspectives (including scholars' assessment of value to/impact on scholarship; durability, from a curatorial point of view; and/or technically-relevant metrics).
  2. Connect Technology Services to Scholarly Practice: Provide mechanisms to record and retrieve relationships between scholars' description of their work and services, tools, & content that support that practice.
  3. Enable Categorizations: Enable application to Atlas content of tags, keywords, and/or categories, whether contributed by users or generated by data-mining software; and, by providing access to data elements, their metadata, and their relationships, enable representation of Atlas content in the context of these contributed or generated ontologies, taxonomies, and/or folksonomies. Different representations thus enabled might be suited to a scholar's exploration of elements of interest (narratives, recipes, tools), to strategic planning tasks such as prioritization and application for funding (focusing on service families and the scholarship they advance), or to technologists' work such as modeling, designing, and implementing services (focusing on service modeling, design, and contracts).
  4. Translate Across Communities: Provide a means for Bamboo's multiple communities to nurture trust and understanding by identifying each others' activities and concerns from multiple points of view, and to assure that technology investments support scholarly need both as currently conducted and into an evolving future.
  5. Surface Elements of Scholarly Practice that can be enhanced or advanced by technology services: By exposing its content for representation, the Atlas, to the extent it is populated, will describe areas of scholarly practice in the Arts, Humanities, and Interpretive Social Sciences that are suited to automation (i.e., suited to enhancement or support via shared technology services, including services whose function is to provide access to hardware-bound capabilities such as storage or telepresence).
  6. Surface Unsupported Scholarly Practice: Provide a vehicle for identifying extant, anticipated, and/or intended practice of scholarship for which automating services and tools do not exist or are not known to Bamboo. Creating support for new and intended practice may have transformative effects, whose value must be judged and whose nature must be governed by communities of scholarship.

In order to fulfill these purposes, the Bamboo Services Atlas will incorporate artifacts that describe both activities and objects involved in scholarship ('verbs and nouns,' or 'steps and ingredients' - cf. Scholarly Narratives & Recipes); and support multiple points-of-entry to its content to facilitate understanding from multiple perspectives. Information will be exposed at multiple levels of detail (or 'granularity'), and be filterable via annotation, search, and discovery mechanisms designed to open access to audiences with different points of view. Though the Services Atlas is conceived as a (set of) 'back-end' service(s) - that is, the Atlas itself will have an API (Application Programming Interface), not a user-interface - it will support recording of and access to the characteristics of Atlas elements that are of interest to diverse communities of its users. (Bamboo will implement at least one user-interface to the Services Atlas; cf. Bamboo Exchange, below.)

The Bamboo Service Atlas will be composed from:

  • Community contributions such as the Scholarly Narratives, Recipes, Activities, Tool examples, and Content/Resource examples being collected and recorded during the Bamboo Planning Phase on the project's wiki, including community-contributed references to information outside the formal bounds of Bamboo;
  • Functionality of extant software (of most any origin) as analyzed and 'factored' into capabilities and services; and,
  • Functionality of software 'in the pipeline' (i.e., software in some stage of planning, design, or development - within or beyond Bamboo community borders - but not yet in release or use) as analyzed and 'factored' into capabilities and services.

The Bamboo Services Atlas will consume and expose identifying and characterizing information about services from the Bamboo Service Registry, which will provide services to register and discover services, to record and obtain service contracts, and to record and discover information about service usage (consumption).

The Bamboo Services Atlas and Bamboo Exchange, once implemented, are expected to offer much simpler and more fully facilitated input, update, and hyperlinking capability than offered by the Bamboo Planning Wiki. The goal will be to provide access to Atlas content in accessible formats that are easily updated, hyperlinked, and annotatable. The Atlas and its Bamboo-provided user interface will support means to organize, mix, match, categorize, and re-categorize its constituent elements in order to render the community's understanding of scholarly practice accessible from the multiple perspectives of diverse stakeholders native to Bamboo. Dynamic ability to incorporate and view evolving input and analysis, and quickly and clearly draw connections to broader context, will enable informed governance by key stakeholders in arts, humanities, and interpretive social sciences scholarship.

Evolution of the Bamboo Service Atlas will occur gradually and iteratively. The collection and recording of information that is occurring in 2008-2009 on the Planning Wiki should be regarded as building an initial body of information to populate the Atlas, and evolving its information architecture. Atlas elements and functionality are expected to be made available through services that may be composed and rendered in a variety of end-user views and tools, such as web browsers, faceted browsers, and scholarly-networking platforms, in addition to the Bamboo Exchange. The Services Atlas is not intended to catalog the totality of knowledge about scholarly practice, digital tools, or shared technology services; it will be useful to the extent it is well-populated with information by responsible and thoughtful contributors.

4.2. Bamboo Exchange

The Bamboo Exchange will serve as a focal point for information about services, tools, and content, including but not limited to services incorporated in the Service Atlas; and as a venue for resource exchange between marketplace participants. Incentives to participate in this marketplace will include a community-driven award system (including monetary rewards), expanded metrics about the way services are used by scholars and campuses, publicity, channels of communication to and feedback from the community of institutions and disciplines participating in Bamboo, as well as an avenue for access to Bamboo's experimental "incubator" service-deployment platform (cf.Local and Incubator Services, below).

The Exchange will allow scholars to discover new resources for their activities, explore and compare the relative capabilities of these resources, and to initiate exchanges of resources. The Exchange will feed information into, and receive information from, the Scholarly Network, to allow scholars to make informed choices among the resources offered via the exchange. The Exchange will allow resource providers to publicize and track the use of their resources, including the ability for experts (including librarians, programmers, consultants, and architects) to join and be compensated for project work housed at other institutions. The Exchange is inspired by several models in use elsewhere - Common Solutions Group, the United Way, ARTFL, and a range of online communities which track reputation and participation.

The Bamboo Exchange is a service to the entire community of Bamboo, and will be composed of a group of services developed or adapted, then deployed by, Bamboo Partners (cf. Common Services, below); and made available to the community in the form of plug-ins and/or widgets. The Exchange will be based on open interface standards that allow it to be easily incorporated into and presented/used within existing portal, virtual research environments, or other aggregation and/or research workflow systems and tools.

4.2.1 Enabling Discovery

The Bamboo Exchange will seek to aggregate and disseminate information about available services, tools, and content relevant to scholarship in arts, humanities, and interpretive social sciences, from a broad range of providers, but will also acknowledge that no single catalog can describe this space comprehensively. Because technology applicable to scholarship has been and will continue to be developed for scholars, projects, disciplines, institutions, et al., outside the auspices of Bamboo, mechanisms will be implemented to automatically harvest public information from builders and providers, as well as from other catalogs, in order to make their work and offerings discoverable from within the Bamboo Exchange; as well as mechanisms that allow service builders/providers to actively and explicitly register information in the Bamboo Exchange.

Bamboo Exchange mechanisms for discovery of available services, including but not limited to those incorporated in the Services Atlas, will help scholars identify whether their need is already addressed before they put out a "bid" to technologists who might be interested in filling or helping to fill a gap. These mechanisms will also help technologists identify services that they might compose into new, enhanced service offerings. An exchange system (perhaps based on RFPs  - Requests for Proposals - or other auction mechanisms) will enable people who need services developed to identify them, and people who want to build or provide services to share or sell them.

4.2.2 Exploration and Comparison

The Bamboo Exchange will allow for the browsing of resources, each expressed in a consistent manner to support comparison and transparency. One useful analogy which has been suggested here is the nutrition label -- a standardized view of the contents and capabilities of a resource, to allow for evaluation of the suitability, interoperability, and sustainability it offers for a given purpose and context. The Bamboo Exchange will track usage of developed services, and provide for collection of feedback; these data will be modeled, collected, and presented in ways that are meaningful to scholars and to technologists. In addition, all of this information will be exposed via an API - Application Programming Interface - so that other services and projects can incorporate and extend the capabilities of the Exchange. There may be minimum constraints for participation in the Bamboo Exchange, such as open source software licensing. Another key question will be whether and how any notion of "membership" in a Bamboo, higher education, or other community may in some situations change or restrict the availability of a given resource.

4.2.3 Initiating Exchanges of Resources

Several of the planning workshops surfaced a similar idea: what about a 'craigslist' (online classified ad system) for scholars? How can a faculty member at one institution connect with a digital humanist at another institution, simply in order to be pointed in the right direction for a technology solution and avoid reinventing the wheel? How can highly skilled research assistants be supported during gaps between grants? Through both free-form postings and an RFP forum, the Exchange will allow institutions to contract with other institutions for the use of resources. These resources might be technology, but one particular area of value is the ability to contract human resources through the exchange. This enables a scholar to gain access to expertise at other institutions for purposes of collaboration, wayfinding, and project work. For example, a scholar at the University of Puget Sound who needs access to an XSLT (Extensible Stylesheet Language Transformations) expert at the University of Chicago would be able to contract for a few hours of her time. The Exchange will support the exploration of multiple models for easing the transactional barriers between the resource pools at different institutions.

4.2.4 Rewarding Open and Interoperable Resource Creation

We will encourage and incentivize the community to build services more likely to become Bamboo "Common Services" -- i.e. those that adhere to community-determined development guidelines and standards for data/content interoperability. Some incentives include the opportunity to participate in a "Bamboo Incubator" (cf. Local and Incubator Services, below), and a community funding redistribution model which provides resources to selected community projects. An appropriate algorithm and strategy for funding redistribution will be determined by the community. Strawman proposal.

4.3. Shared Services Lifecycle

Sub-section 4.3.1, "Local and Incubator Services," describes early phases of discovery, adoption, or development of services of interest to the Bamboo Community. Sub-section 4.3.2, "Common Services," describes a phase of service refinement that addresses concerns like sustainability, standards-compliance, and reliability. Sub-section 4.3.3, "Bamboo Service-Delivery Appliances and the Bamboo Cloud," describes how Bamboo intends to make services available for use.


4.3.1 Local and Incubator Services

Working services that are not yet refined and offered as "common" may be provided from local or regional deployments by Bamboo institutions, and listed with appropriate descriptors of service quality in the Bamboo Exchange. A deploying institution or group of institutions would be wholly responsible for availability and maintenance of such services; Bamboo as a consortium would make no guarantee regarding these limited or experimental deployments. Services deployed in Local and Incubator contexts are considered to be potential candidates for refinement, standardization, and adoption as "Common Services." Services deployed in these contexts may originate in the work of Bamboo member-institutions, or in the broader universe of service builders; it is the latter case that comprises Bamboo Incubator Service deployments, which will generally be segregated into a separate and parallel deployment context from services that originate in the development efforts of Bamboo members. The "incubator" concept is borrowed from W3C and Apache.

Bamboo Members involved in Explore and Plan layers of activity may identify services and service-providers evolving independently of Bamboo that are of 'preliminary interest'; and may invite deployment in a 'pre-consortial' context that offers exposure to the provider/builder and opportunity for exploration to Bamboo's community of scholarship. Local and Incubator deployments are avenues by which services may be identified - through exposure, experimentation, and observation of scholarly usage - for possible selection as candidates for refinement, standardization, and adoption as "Common Services." At least initially, no cost-recovery model is assumed to be available in the provision of services deployed in Local and Incubator contexts. Therefore, it is reasonable and expected that limits will be imposed on the quantity of resources that may be consumed as these services are utilized. Such limits will be an explicit element of Service Level Agreements (SLAs) associated with these service deployments.

These 'pre-consortial' deployment avenues recognize that a world of tool and service development has occurred, is occurring, and will continue outside the formal auspices of Project Bamboo, and that innovative development and use of software is likely to occur at the edges and beyond the borders of Bamboo's processes for aligning characteristics, standards-compliance, and deployment requirements of software services. Bamboo will therefore make explicit provision for its partners to offer, from within a Bamboo context, services for scholarship at levels of availability and refinement that fall outside a definition of "Common Services" (see below).

Services such as these, that are not "Common Services," but are served (hosted/deployed) by Bamboo partner institutions and organizations:

  • may be listed and linked to other elements in the Bamboo Service Atlas, and accessed via the Bamboo Exchange;
  • may be deployed in a standard "Bamboo Appliance" if the service meets some minimal alignment to Bamboo deployment infrastructure; or on some other infrastructure operated by the host institution or organization (a less-preferred alternative once a "Bamboo Appliance" is available);
  • will not be supported by any consortial guarantees of quality (Service Level Agreements, SLA);
  • will express the level of service quality that is guaranteed by the host;
  • may originate in service development work done by a Bamboo Member or by others;
  • will, if the service originates in work outside the community of Bamboo Membership, be deployed in a separate and clearly differentiable "Incubator" context, modeled on the "entry path" concept that underlies the W3C and Apache incubators;
  • may utilize compute, storage, and network resources within the service-hosting infrastructure; or may "wrap" requests for resources provided elsewhere;
  • will require some form of identification (e.g., user or application ID) in order to track usage and facilitate notification of service outages or other changes; and,
  • will be made available to scholar-users without membership-related restrictions - that is, scholars affiliated with institutions or organizations who are not involved with Project Bamboo, and (tentatively) scholars not affiliated with any institution or organization.

4.3.2 Common Services

Services of broad, deep, or otherwise valuable utility may become candidates for refinement into "Common Services." Service interfaces that have been refined through a process of architectural modeling, design, alignment to applicable standards, and coordination to maximize interoperability, then developed as production-ready reference implementations, will be considered "Common Services." As such, they can and will be deployed by Bamboo member institutions for use by the global community of scholars in a redundant, distributed network of Bamboo Appliances that comprise the Bamboo Cloud. These services will include those that enable core digital infrastructure of the Bamboo Community (the Services Atlas and its component entities; and the Bamboo Exchange, including its elements). Additional services will deliver direct support to scholarship by enabling Scholarly Networking (cf. Section 3 of the Bamboo Program Document) and automating workflows (recipes) that add value to the arts, humanities, and interpretive social sciences. Some classes of service will provide resources delivered directly from servers operated by Bamboo member institutions; while others will wrap (call) or refer to compute, storage, and/or service-delivery resources operated by others. Service Level Agreements for services offered from the Bamboo Cloud, as well as those for underlying services hosted elsewhere, will be clearly articulated to service consumers.

Common Services deliver qualities that the Bamboo Consortium guarantees. These will address sustainability, stability, availability, composability (i.e., usability in multiple workflows), standards-compliance, scalability, and robustness. Architectural coherence is also a key quality of Common Services, intended to forestall problems that would otherwise follow from a scatter of arbitrary decisions (not related to delivery of functionality) that might be made if development is not constrained by architectural principles and a standards orientation. With the exception of services deployed in close proximity to distributed tools or content, Common Services are expected to be deployable on a standard Bamboo Appliance for service-delivery. Common Services will support or permit usage tracking (technical and functional), and add value to scholarship in the arts, humanities, and interpretive social sciences. A fundamental aspect of the commonality of "Common Services" is their composability into multiple workflows ("recipes") and interoperability with one another.

Once a service is accepted at the Bamboo Plan layer as a candidate, there is a set of refining activities that must occur before it is capable of delivering the qualities enumerated above, and is thus eligible to be considered a "Common Service." The current draft of this document does not attempt to enumerate these activities.

Existing services may be proposed for "Common Service" candidacy by Bamboo Members. A usual path to candidacy includes evolution of a service to a point where it is deployed, used, and studied in a Local or Incubator context (see Local and Incubator Services, above). Bamboo Members with responsibilities in the Plan areas of work will actively seek to identify candidates from services emerging in the larger world of digitally-enabled scholarship, as well as within the Bamboo Exchange, Local Services, and Incubator Services contexts. Anyone may propose a service or set of services to Bamboo as potential candidates. Services emerge as candidates for refinement into Common Services because they:

  • are, or are potentially, of broad, deep or otherwise valuable utility to one or multiple areas of scholarly practice in arts, humanities and/or interpretive social science;
  • would provide, in appropriate proportion to the effort and resources needed to evolve them, greater value if engineered to deliver Common Service qualities;
  • abstract or may, with relative ease, be refactored to abstract basic/utility functions and entities (such as authorization or persistence functionality; and entities representing a person or organization);
  • separate generally-applicable functionality from that which is specific to particular domains or corpora;
  • exist already, fit well within, or may, with relative ease, be refactored to fit well within loosely-coupled architectures;
  • already run or can, with relative ease, be refactored to run atop stable, well-supported open-source technology stacks;
  • are implemented using good coding and documentation practices; and,
  • take and return standards-compliant input and output, or can, with relative ease, be refactored to do so.

Services that exist only as concepts must be adopted by a service design/development team in order to advance the concept to a point at which it can be meaningfully considered for candidacy, as described above. Such development teams may be Bamboo Members or not, and may have institutional, organizational, disciplinary, functional, or other focus.

Some classes of Common Services will provide resources delivered directly from servers operated by Bamboo member institutions; while others will wrap (call) or refer to compute, storage, and/or service-delivery resources operated by others. Service Level Agreements (SLAs, cf. #Glossary) for services offered from the Bamboo Cloud, as well as those for underlying services hosted elsewhere, will be clearly articulated to service consumers.

An initial set of Common Services will enable core digital infrastructure of the Bamboo Community (the Services Atlas and its component entities; the Bamboo Exchange, including its elements; and services that enable Scholarly Networking).

4.3.3 Bamboo Service-Delivery Appliances and the Bamboo Cloud

A "Bamboo Appliance" for service-delivery is expected to evolve as a standardized (probably virtual) server provisioned with a technology stack on which services may be deployed and made available for consumption. A number of distributed Bamboo Appliances will respond to service requests addressed to and routed from the Bamboo Cloud, via a mechanism that provides load-balancing, fail-over capability, and diagnostics of the "health" of constituent appliances. It will also be possible to request and receive service functionality from a Bamboo Appliance directly (e.g., via Local and Incubator deployment contexts described above).

Bamboo Members active in the Plan layer of the consortium will be responsible for defining the architecture and technology requirements for this appliance and for the Bamboo Cloud; Bamboo Members active in the Build layer will be responsible for implementing, testing, distributing, and maintaining them. Bamboo Appliances and the Bamboo Cloud will be constituted on a technology platform (or combination of technology platforms) identified in the Bamboo Plan layer of activity. Some technologies that may be considered include cloud services provided by commercial vendors; and open-source infrastructures such as Eucalyptus, Nimbus, and Sun Microsystem's Open Cloud Platform.

An early conceptual diagram of appliances supporting a "cloud" from which services may be accessed follows:




Bamboo Service Delivery Appliances and the Bamboo Cloud. This diagram is a very preliminary, rough, and tentative conceptual model of a set of Bamboo Appliances comprising the Bamboo Cloud.

Services delivered from Bamboo Appliances will, in some cases, provide resources delivered directly from the Appliance; while others will wrap (call) or refer to compute, storage, and/or service-delivery resources that originate elsewhere. Service Level Agreements (SLAs, cf. #Glossary) for services offered from Bamboo Appliances or from the Bamboo Cloud, as well as those for underlying services hosted elsewhere, will be clearly articulated to service consumers.
An early set of services will offered from the Bamboo Cloud will be those that enable core digital infrastructure of the Bamboo Community (the Services Atlas and its component entities; the Bamboo Exchange, including its elements; and services that enable Scholarly Networking). Some content is likely to be hosted in the Bamboo Cloud, including content related to the Services Atlas, Bamboo Exchange, Scholarly Networking infrastructure, and related Bamboo community endeavors; the appropriateness and extent of Bamboo cloud-hosting for digital content such as primary and secondary sources of scholarly interest will evolve over time, in accordance with community-directed decision making processes, partnerships, and resource availability.

The technology stack that enables service delivery is conceived as a "Bamboo Service Platform." It will be composed from existing, open-source technologies such as service containers, service buses, and orchestration engines, and provide the means to host and deliver services to the community.

4.4. Tool and Application Alignment Partnerships

Bamboo will partner with interested tool and application projects and developers to wrap and/or deliver functionality (automation capabilities) as services that can be deployed alongside, and interoperate with, Bamboo Common Services. By exposing capabilities from other projects and providers as Bamboo-affiliated services, broader and more diverse uptake of those capabilities is more likely; such exposure will also enrich the pool of service candidates being considered for refinement into Bamboo Common Services. These partnerships will deepen and broaden the Bamboo ecosystem with expertise and experience rooted in domain- and function-centric communities.

Some of the most fertile ground for development of automation capability in arts, humanities, and interpretive social science scholarship to date has been in discipline- or tool-focused communities and projects, such as (but in no way limited to) ARTFL, MONK, the Perseus Digital Library, SEASR, and Zotero. As the technology landscape evolves toward delivery of decomposed functionality as services, some discipline- and tool-focused projects will likely be interested in delivering their capability in an architecture congruent with Bamboo's. This will present opportunities for partnership.

In collaborative negotiation with projects whose valuable algorithms and implementations can be enhanced by alignment and partnership with Bamboo architecture, mutually beneficial incentives will be defined and exchanged to best advance scholarship as a whole in the arts, humanities and interpretive social sciences. Broader and more diverse uptake of partner-delivered capabilities is a likely incentive Bamboo can offer. In the other direction, Bamboo will benefit from enrichment of the pool of service candidates being considered for Local and Incubator deployments and refinement into Bamboo Common Services, and from an ecosystem deepened and broadened by expertise and experience rooted in domain- and function-centric communities.

4.5. Content Interoperability Partnerships

Bamboo will partner with interested content (digital resource) providers to enable Bamboo Common Services to discover, search, and appropriately operate on their diverse and distributed holdings. Similarly, partnerships with interested repository platform providers will enable Bamboo Common Services to discover, search, and appropriately operate on resources hosted on platforms of strategic value to communities of arts, humanities, and interpretive social science scholarship. These efforts will likely take the form of modeling, implementing, and deploying service interfaces that conform to extant and emerging standards to expose strategically identified content stores and platforms. Bamboo-facilitated exposure of content via service interfaces will broaden uptake and trans-disciplinary opportunities for scholarship, as well as suggest additional candidates for refinement into Bamboo Common Services.

Objects of scholarly interest - "content" or "digital resources" in a world of bytes and networks - are the gravitational centers around which much or most scholarship in the arts, humanities, and interpretive social sciences orbits. Improving the ability of scholars to discover, inquire of, compare, integrate, decompose, and re-integrate objects of interest that reside in diverse repositories, as well as to digitize and store additional objects-of-interest, are fundamental goals of cyberinfrastructure in the academy, and key interests expressed by many participants in Bamboo workshops and in other venues - from blogs to white papers - focused on what IT can do for scholars.

Bamboo will therefore partner with library, archive, and repository partners, and those who deliver platforms on which digital repositories are hosted and accessed, to collaboratively develop interfaces and content-transformation services that will maximize exposure of unique features of diverse partners, while leveraging commonality or similarity by conforming to extant and emerging standards to broaden the field of inquiry and operation over diverse and distributed content repositories. These partnerships are likely to look to existing initiatives around the Open Content Alliance, the Internet Archive, the Digging into Data Challenge, and similar content-centric efforts; as well as standards-body and library-driven specifications for publishing digital resources such as OAI-PMH (Protocol and Metadata Harvesting), OAI-ORE (Object Resuse and Exchange), XTF(eXtensible Text Framework) and Jangle(AtomPub for library resources), to build upon a range of experience and practice in capture, archiving, discovery, and dissemination of digital content.

Intellectual Property issues are likely to play a part in any content interoperability efforts.

4.9. Section Glossary

This quickly-assembled glossary explains some of the terms used in this draft.

  • Activities - Steps (units of work, process, or procedure) that occur in the course of tasks or workflow that comprise scholarship. Cf. Activity Definitions.
  • API - cf. Application Programming Interface in this glossary.
  • Application ID - An alphanumeric string or other token of identification that ties usage of a service to another piece of software, such as another service or an application.
  • Application Programming Interface (API) - Instructions explaining how a body of software may be used to gain the benefit of its functionality. (From Wikipedia: a set of routines, data structures, object classes and/or protocols provided by [software] libraries and/or operating system services in order to support the building of applications.)
  • Bamboo Appliance - Shorthand for a 'service-delivery appliance' - a standardized (probably virtual) server provisioned with a technology stack (cf. Bamboo Service Platform in this glossary) on which services (e.g., web services) may be deployed and made available for use.
  • Bamboo Cloud - A collection of service-delivery 'applicances' (cf. Bamboo Appliance in this glossary) that collectively and redundantly, using load-balancing and fail-over mechanisms, hosts Bamboo Common Services (cf. 4.3.2 - Common Services, above)
  • Bamboo Service Platform - A set (stack) of technologies that provides the means to host and deliver services from a Bamboo Appliance (cf. Bamboo Appliance in this glossary).
  • Capability - In a service, a piece of work that the service can deliver on request.
  • Common Services - Cf. 4.3.2 - Common Services (above).
  • Narratives - Cf. "Scholarly Narratives" in this glossary.
  • Operation - A call (request) that can be made to a service to execute some piece of work, with formally defined input, output, and error messages
  • Recipes - Recipes describe how to achieve goals using information technology. Recipes are written for scholars and describe the tools and steps needed to complete a task in non-technical language. In short Recipes are built on the stories academics tell about what they want to do by generalizing to shared tasks and they allow Bamboo to organize technology to support those tasks. Cf. Recipes.
  • Refactor - (from Wikipedia): "The process of changing a computer program's internal structure without modifying its external functional behavior or existing functionality. This is usually done to improve external or internal non-functional properties of the software, such as code readability, to simplify code structure, to change code to adhere to a given programming paradigm, to improve maintainability, or to improve extensibility."
  • Scholarly Narrative - Expression of a particular aspects of scholarship, scholarly workflow, research, and/or teaching from a scholar's perspective, and in her own language. Cf. Scholarly Narratives Working Group.
  • Shared Technology Service - cf. Service, below.
  • Service - A unit of software that delivers a related set of capabilities. Services implement functionality (capabilities) that have been decomposed then logically grouped to flexibly facilitate (a) interoperability with other software and/or digital content; and/or (b) combination and recombination with other services in support of multiple tasks or workflows.
  • Service Atlas - A collection of information - some general some detailed - that in its expression and linkages permits individuals with different interests, skills, and perspectives to understand the nature and utility of services, their purpose and relevance, and the body of work they are meant to support. Cf. 4.1 - Services Atlas (above).
  • Service Candidate - A concept for a service. A grouping of capabilities modeled as a set appropriate for designing and implementing as a single service.
  • Service Contract - A formal expression of Service Design (i.e., operations and message structures, as well as additional information and parameters necessary to execute operations offered by a service).
  • Service Design - The operations and message structures (input, output, error), as well as additional information and parameters necessary to execute operations offered by a service.
  • Service Endpoint - The location (generally on a network, such as the internet) where an existing, operating service can be accessed (called) in order to request delivery of its functionality. A service endpoint is to a service what a URL is to a web page; in the familiar case of a web page, calling http://www.google.com in a browser fetches a web page from Google.
  • Service Level Agreement - An agreement describing a measurable level of service guaranteed by a service provider to a service receiver.
  • Service Model - A rough expression of capabilities that a service is expected to offer; less detailed and formal than Service Design, but more so than a Service Candidate.
  • Service Family - A group of related services.
  • SLA - Cf. Service Level Agreement, above.
  • User ID - An alphanumeric string or other token of identification that ties usage of a service to an individual (whether anonymized or not)
  • No labels

2 Comments

  1. Unknown User (jim.muehlenberg@doit.wisc.edu)

    Section 4. The Cloud, second last paragraph of overview - "Exchange will enable scholars to find tools and digital methodologies ... enable or enhance those tools and methodologies" - assume "content" should be added to "tools and methodologies" here?

    Section 4.1 Services Atlas - can we think of a broader term, as this contains much more than services?  Also, what's relationship of the Atlas to the Bamboo VRE (since the VRE takes the place of the wiki where all these objects are managed currently)?  Also, does this suggest that the Atlas delivers its content via the Exchange, using the Bamboo Common Environment?  (Again, an architectural diagram would help clarify things here.)

    Purpose 1. Identify Existing Services - should this also identify tools and content and recipes as well as services?

    Still in Section 4.1, section on "The Bamboo Service Atlas will be composed from" where it says "the formal bounds of Bamboo" - what are these bounds?  how can they be defined?  should they exist?

    Still in Section 4.1, a bit lower, "The Bamboo Services Atlas and Bamboo Exchange, once implemented, are expected to offer much simpler ... than ... Planning Wiki" - is this saying these combined equal the Bamboo VRE?

    Section 4.2 Bamboo Exchange, first sentence - when would tools and content be in the Exchange and not be in the Atlas?  is a bit confusing here

    Section 4.2.2 Exploration and Comparison, last sentence about "restrict the availability of a given resource" - could one assume each resource would/could have its own license, as can be the case in a digital repository like those using DSpace?

    Section 4.3.1 Local and Incubator Services, first paragraph - it's still not clear to me why we need to separate those two concepts (Local vs. Incubator), what value does that yield?

    Section 4.3.2 Common Services, first paragraph "and automating workflows (recipes)" - seems to give support to the notion of dynamic, active recipes from section 3.3.1.  Also, the discussion of services emerging as candidates for refinement into Common Services still leads me to ask if there should be a similar lifecycle concept for tools and content (promoting from in-the-wild to incubated to common somehow?)  Also, the last paragraph again seems to refer to the Bamboo VRE, is that correct?

    1. Unknown User (cjkainz@uchicago.edu)

      Mulling over your comments. Again, the VRE thing is a particular disconnect within the document (the problem with multiple authors with twice as many interpretations).