Opening Up Library Systems Through Web Services and SOA Hype, or Reality?.

46 Pages·2010·2.019 MB·English

by  Marshall Breeding

November/December 2009
vol. 45 / no. 8
MEET THE W ! FACE OF Library Technology
NE IssN 0024-2586
ALA TechSource Online
R e p o R T s
expert Guides to Library systems and services
www.alatechsource.org
a publishing unit of the
(cid:262)(cid:1) Access a growing American Library Association
archive of more
than 8 years of
Library Technology
Reports (LTR) and
Smart Libraries
Newsletter (SLN)
(cid:262)(cid:1) Read full issues
online (LTR only) or
as downloadable
PDFs
(cid:262)(cid:1) Learn from
industry-leading
practitioners
(cid:262)(cid:1) Share unlimited
simultaneous
FREE SAMPLES @ alatechsource.metapress.com
access across your
institution
(cid:262)(cid:1) Personalize with
RSS alerts, saved
items, and emailed
favorites
(cid:262)(cid:1) Perform full-text
searches
LIBRARY TECHNOLOGY
UNCOVERED, EXPLORED, ONLINE
Subscribe to TechSource Online today!
alatechsource.metapress.com
Opening Up Library
Your support helps fund advocacy, awareness, and accreditation programs for library professionals worldwide. Systems through Web
Services and SOA:
Hype, or Reality?
by Marshall Breeding
ISBN 978-0-8389-5806-3
9 780838 958063
Library Technology
R e p o R T s
Expert Guides to Library Systems and Services
Opening Up Library Systems
through Web Services and SOA:
Hype, or Reality?
Marshall Breeding
www.alatechsource.org
Copyright © 2009 American Library Association
All Rights Reserved.
About the Author
Library Technology Marshall Breeding serves as the
Director for Innovative Technology
R e p oR Ts and Research at the Vanderbilt
University Libraries in Nashville,
Tennessee. He has authored sev-
American Library Association
eral previous Library Technology
50 East Huron St.
Chicago, IL 60611-2795 USA Report issues: “Electronic
www.alatechsource.org Se curity Strategies for Libraries,”
800-545-2433, ext. 4299
“Strategies for Measuring and
312-944-6780
312-280-5275 (fax) Implementing E-Use,” “Integrated Library Software: A Guide
to Multiuser, Multifunction Systems,” “Wireless Networks in
Advertising Representative Libraries,” “Web Services and the Service-Oriented Archit ec-
Brian Searles, Ad Sales Manager ture,” and “Open Source Integrated Library Systems.” Breeding
ALA Publishing Dept.
[email protected] is also a contributing editor to Smart Libraries Newsletter,
312-280-5282 published by ALA TechSource, and has authored the feature
1-800-545-2433, ext. 5282
“Automated Systems Marketplace” for Library Journal for the
last six years. His column “Systems Librarian” appears monthly
ALA TechSource Editor
in Computers in Libraries magazine. A regular on the library
Dan Freeman
[email protected] conference circuit, Breeding frequently speaks at Computers
312-280-5413 in Libraries, Internet Librarian, and other professional gather-
ings throughout the United States and internationally. He is
Copy Editor
a regular panelist on the LITA Top Technology Trends panel
Judith Lauber
at the ALA Annual and Midwinter conferences. Breeding cre-
ated and maintains the Library Technology Guides Web site at
Administrative Assistant
www.librarytechnology.org. For more information or to con-
Judy Foley
[email protected] tact the author, see http://staffweb.library.vanderbilt.edu/
800-545-2433, ext. 4272 breeding.
312-280-5275 (fax)
Production and Design
ALA Production Services: Troy D. Linker
Abstract
and Karen Sheets de Gracia
Over the last few years, Web services and the service-ori-
ented architecture (SOA) have become dominant themes in
Library Technology Reports (ISSN 0024-2586) is published eight times a
IT across many industries. Web-based computing, service-
year (January, March, April, June, July, September, October, and December)
by American Library Association, 50 E. Huron St., Chicago, IL 60611. It is orientation, and cloud computing increasingly displace the
managed by ALA TechSource, a unit of the publishing department of ALA. client/server approach favored by libraries in the past. In
Periodical postage paid at Chicago, Illinois, and at additional mailing offices.
library automation, one major trend involves evolving or
POSTMASTER: Send address changes to Library Technology Reports, 50 E.
Huron St., Chicago, IL 60611. rebuilding automation systems to adopt this new approach
to software. Purveyors of both open source and propri-
Trademarked names appear in the text of this journal. Rather than identify
or insert a trademark symbol at the appearance of each name, the authors etary library automation products increasingly emphasize
and the American Library Association state that the names are used for the ways in which they embrace openness, support appli-
editorial purposes exclusively, to the ultimate benefit of the owners of the
trademarks. There is absolutely no intention of infringement on the rights cation programming interfaces (APIs), or implement Web
of the trademark owners. services.
Libraries increasingly need to extract data, connect with
external systems, and implement functionality not included
with the delivered systems. Rather than relying on the
product developers for enhancements to meet these needs,
Subscriptions
wwwwww.a.alalatetecchhssoouurcrcee.o.orgrg
For more information about subscriptions and
Copyright ©2009 American Library Association individual issues for purchase, call the ALA Customer
All Rights Reserved. service Center at 1-800-545-2433 and press 5 for
assistance, or visit www.alatechsource.org.
Table of Contents
Chapter 1—Introduction 5
Scope 6
Intended Audience of This Report 6
Why Should Libraries Care about Application Programming Interfaces? 6
Possibilities Abound 7
Basic Concepts 8
API Implementation Models 9
What Is an API? 11
Proprietary APIs 12
APIs and Open Source 12
Standards as Open Interfaces 13
API Security 13
Terms of Service 13
With Power Comes Responsibility and Cost 14
No Universal Expectation for APIs 14
Chapter 2—Vendors and Products 15
CAse sTudies And CusTomeR Responses
Ex Libris 15
Duke University Libraries 18
Broome Community College 19
University of Tennessee 20
National Library of Australia 21
Evergreen 21
The Library Corporation 23
Innovative Interfaces 25
Koha 28
Polaris 29
SirsiDynix 31
Talis 34
VTLS 36
Notes 37
Chapter 3 —API Hype and Reality 39
Conclusions 41
Resources 42
Abstract (cont.)
libraries increasingly demand the ability to exploit their extent to which their automation products are able to
systems using APIs, Web services, or other technolo- interoperate and thrive in this growing realm of Web
gies. The demand for openness abounds, particularly in services. This report aims to assess the current slate of
libraries that exist in complex environments where many major library automation systems in regard to their abil-
different systems need to interact. As libraries develop ity to provide openness through APIs, Web services, and
their IT infrastructure, it’s imperative to understand the the adoption of SOA.
3

CChhaapptteerr X1
Introduction
Abstract In today’s environment, systems that are perceived
as being “closed” have diminished appeal. It sure sounds
In recent years, companies involved with both open
better to characterize an automation system as “open”
source and proprietary integrated library systems (ILSs)
and flexible, but what do the terms really mean? We will
have made a concerted effort to increase the openness—
explore some of the techniques that provide increased
that is, the degree of flexibility and interoperability—
access to data and internal functionality, focusing espe-
that their products offer to librarians and programmers.
cially on Web services and other application program-
This chapter of “Opening Up Library Systems through
ming interfaces.
Web Services and SOA: Hype or Reality” explores this
Many libraries might say that they do not want a
dynamic in the current ILS market. By taking a general
“black box” system that restricts users to the functionality L
look at what characteristics and functionality librar- ib
ians seek in their software and defining key terms, this in the interfaces provided by the vendor, with no access rar
to the internals of the system. Yet many libraries need a y
chapter sets the stage for an in-depth exploration of the T
turnkey system that helps them carry out their work with- ec
modern ILS trend towards APIs, Web services, and the h
out the need for any local programming or intervention. no
service-oriented architecture. We should emphasize that APIs offer additional opportu- log
y
nities for those that want to do more with their software, R
e
In the current phase of library automation, we’ve become but do not impose any technical requirements for libraries po
r
inundated with the language of openness. Open source that choose not to use them. ts

integrated library systems (ILSs) have emerged, prom- When it comes to the purveyors of proprietary soft- w
w
ising to give libraries more control over their software ware, claims of openness are also everywhere. The empha- w
than has been possible with proprietary, closed-source sis on openness may have been accelerated by the open .ala
products. Companies that produce and provide service for source movement, but it has been a steady theme for many tec
h
proprietary products have redoubled their efforts to offer years. Press releases and product literature gush with the so
u
more flexibility, openness, and interoperability through language of openness. The means to this openness are rce
Web services and other application programming inter- the adherence to standards and Web services and other .org

faces (APIs). A new front has developed in the competi- application programming interfaces.
N
tion among library automation alternative vendors, who This report aims to take a close look at the major ov
e
are racing to open up software and allow libraries more ILS products on the market and describe the approach m
b
access to their data and internal functionality. This new that each offers in delivering open access to its data and er/
emphasis on openness can be a great benefit to librar- functionality. Of particular interest are the APIs that each De
c
ies to the extent it that it actually offers new capabilities system offers to the libraries using its product. We will em
otherwise not available. Still, as implied by the title of describe and evaluate their scope and comprehensiveness be
this issue, it’s often difficult to distinguish products that and observe the extent to which each product offers these r 2
0
0
fully embrace openness from those where the claims don’t APIs through Web services, the preferred approach in the 9
quite match reality. current phase of information technologies.
5
Opening Up Library Systems through Web Services and SOA: Hype, or Reality? Marshall Breeding
Libraries have varying expectations when it comes Developers and other technical staff may already
to what they want from their automation products. Many be familiar with many of the concepts explained in this
simply want the system to function as documented, using report, but should find the examinations of how different
the interfaces and reports delivered with the system. Some APIs have been implemented in particular products to
ILS products target libraries that expect basic functional- be of interest. Systems librarians, Web developers, and
ity without the expectation of local programming. The others ready to extend their activities to include program-
products in this category serve a vital role in the library ming with the library’s ILS or other key infrastructure
automation arena. Libraries expecting to work with their components will learn basic concepts and the realm of
systems through local programming should be clear on tasks that can be accomplished using these interfaces.
which products offer this capability and which do not. Developers outside the library industry who may be
involved with libraries will find important information on
the integration capabilities offered by the major library
Scope
automation products.
Librarians and other library workers not directly
This report focuses on integrated library systems, the
involved with technology will benefit from understanding
core business application used to automate the work that
the concepts involved since this is an area of technology
takes place in libraries and to provide access to their col-
that has a direct impact on the information environment
lections and services. Libraries make use of many differ-
of the library and the information and functionality that
ent software components, such as discovery interfaces,
supports their work.
link resolvers, federated search tools, digital collection
The ability to work with library automation soft-
management systems, and institutional repository plat-
ware through an API benefits some types of libraries
forms. Although many of the same questions apply to
more than others. Those involved with larger and more
other genres of software, those lie outside the scope of
complex library organizations will have more opportuni-
this report.
ties to take advantage of the APIs and other integration
We further narrow the scope to the ILS products
technologies covered in this report. The key target orga-
widely used in the United States by the kinds of libraries
nizations include academic libraries of all sizes, large and
likely to have an interest in extensible systems. The types
medium-sized public libraries, special libraries supporting
of libraries in this category would include large research
large organizations, and national libraries. These libraries
libraries, municipal and large public library systems,
generally operate a variety of information systems within
and national libraries. The specific systems examined
9 their enterprise networks, with interdependencies that
0 will include those from Ex Libris, Innovative Interfaces,
20 often cannot be realized by out-of-the-box functionality.
er SirsiDynix, VTLS, Polaris, and The Library Corporation, The libraries require custom programming to get what
mb as well as Koha and Evergreen, which are widely adopted
ce open source ILS products. Even though Talis does not they need out of their software. Smaller libraries tend to
/De market its ILS in the United States, it has been an active use automation products as delivered by their develop-
ber proponent of this approach and warrants inclusion. ers, increasingly as a hosted service, and may have fewer
m needs that require programmatically extending the func-
e
ov tionality. Smaller libraries are also less likely to have the
N
Intended Audience of This Report technical staff to implement these capabilities.
g
or
e. This report aims to provide useful information to anyone
c
our involved with automation products in a library context, Why Should Libraries Care
s
ch especially those involved with defining or implementing about Application Programming
e
at technology strategies. Library administrators will find
al Interfaces?
w. information, presented in clear, nontechnical language,
w
w that will help them understand some of the options to The integrated library system, or ILS, provides the essen-
s extend and enhance their automation environment. These tial automation infrastructure for a modern library and
t
por extensions relate to extracting and manipulating data in represents one of the largest technology-related invest-
e
R ways that will support management decisions, allowing ments that a modern library makes. Libraries select from
y
g the library’s computer systems to work together more a variety of major products on the market, including both
o
ol efficiently and to better connect with the information sys- proprietary and open source flavors.
n
h
c tems of the broader organization. For library administra- Each library brings a unique set of expectations and
e
T
y tors and other nontechnical professionals, this report will requirements to the table as it implements its ILS. Through
brar provide information and context to help understand the a careful selection process, the library will identify the
Li claims and counterclaims of open source and proprietary system best suited to its fundamental requirements. Yet
software proponents. no prepackaged automation system will completely satisfy
6
Opening Up Library Systems through Web Services and SOA: Hype, or Reality? Marshall Breeding
all of the nuanced needs of every library. Equipped with an Extensible. An ILS embodies a specific set of fea-
API, libraries with their own programmers have the option tures and functions that are needed to automate
of creating functionality that fills in the gaps between the the internal operations of a library and provide its
system as delivered and their specialized requirements. users with access to its collections and services.
Library automation systems increasingly operate The set of features in a given ILS will continue
within a broader context of information systems. Espe- to evolve over time in response to the ongoing
cially in larger organizations, the ILS needs to communi- enhancement requests that emerge from the
cate with a variety of other business applications. libraries that use the software and from the devel-
Any ILS comes as a complete package designed to opment agenda of its developers. Many librar-
present a broad set of features and functionality through ies have specific automation needs not fulfilled
the user interfaces delivered with the system. These user by their ILS. These needs may not be shared by
interfaces, whether presented through a Web browser other libraries that use the software, making them
or implemented through a graphical Windows, Java, or unlikely candidates for the normal enhancement
Macintosh interface, allow human users to interact with process. An extensible system allows the ILS to
the software, searching for resources, performing trans- enhance its functionality without the intervention
actions, extracting reports, or carrying out other busi- of the programmers that created it. APIs provide
ness functions. In selecting a system, a library measures one of the most important vehicles for extending
the completeness of that system in terms of what can be an ILS according to the needs of a given library.
accomplished through these user interfaces. Vendor independence. The presence of a robust
The user interfaces provided with the ILS are the API can help reduce a library’s dependence on the
products of the people who develop the system. While organization that created and supports the ILS.
some aspects of the user interface can be adjusted by the With a closed system, only the vendor can make
configuration options selected by the library, the basic changes to the system to extend its functionality.
functional capabilities cannot be altered except by those An API provides a library with the ability to create
involved in the development of the software. customized functionality without the intervention
While many libraries find the functionality delivered of its developers. This capability enables the library
with the ILS to meet their automation needs, others benefit to have more flexibility; it is less hampered by an
from the ability to perform tasks beyond that of the deliv- unresponsive vendor and can accomplish tasks
ered software. A robust and well-documented set of APIs with its own staff that otherwise might require
empower the library to perform tasks with the ILS and the paid custom programming from the vendor. Lib
data it manages that go beyond the delivered system. The degree of independence gained by the ra
r
APIs associated with an integrated library system ability to take advantage of an API isn’t absolute. y T
e
enable interoperability, make its functionality extensible, The library continues to be dependent on the ch
n
and empower the library to be more independent of the product’s developers to maintain the product. If o
lo
organization that created the software: the company goes out of business or withdraws gy
R
the product, the programming invested may or e
Interoperability. For many libraries, a key concern may not be transferable to another ILS. po
r
lies in their ability to make the ILS communicate ts

effectively with other computer systems. The more w
w
that a library exists within an organization that w
makes use of multiple information systems, the Possibilities Abound .ala
more that it needs an ILS that can interact with tec
To help readers visualize why it’s important for an ILS to h
those other systems. In such a context, an ILS so
offer an API, some of the tasks that can be accomplished u
that cannot interoperate with other systems func- rc
e
tions as an isolated silo that may not support the might include: .org

library’s organizational and business needs. To OPAC replacement or enhancement. One of the
N
a large degree, interoperability can be achieved ma -jor trends today involves the transition from ov
e
through adherence to applicable national and traditional online catalogs to new-generation dis- m
b
international standards. Yet standards do not nec- covery interfaces. These new products often come er/
essarily address every possible aspect of the way from sources other than the developer of the ILS, De
c
that a library might need its ILS to interact with but thoroughly rely on the ability to extract data em
other business or information systems. APIs pick from and communicate in real time with the ILS. be
up where standards leave off, allowing libraries to It’s through APIs that it becomes possible for a r 2
0
0
create interoperability that cannot be achieved in third-party discovery interface to work seamlessly 9
other ways. with the ILS.
7
Opening Up Library Systems through Web Services and SOA: Hype, or Reality? Marshall Breeding
Many libraries need to enhance their existing These tasks represent only a few of the possibilities.
online catalog in ways beyond the standard Equipped with a well-developed API, a library should be
configurations that are offered. The display of able to respond to a wide variety of needs that arise involv-
book jackets, summaries, or reviews can be layered ing some aspect of information managed within its ILS.
onto catalog pages using an API.
It’s of increasing interest to embed library
content and services in external Web pages and Basic Concepts
portals. A flexible set of APIs in the ILS, especially
in the form of Web services, will help support This report focuses on techniques for providing librar-
these capabilities. ies more open access to their core automation systems.
The key approach that we will explore is the application
Connectivity with self-check and automated mate-
programming interface, or API. In today’s technology
rials handling equipment. The ability to take
environment, the preferred implementation of an API is
advantage of self-service and other external auto-
through Web services, which takes advantage of the pro-
mation systems may be enhanced through APIs.
tocols, structures, and technologies that support the Web.
Much of this connectivity is addressed in SIP2
Systems formed entirely out of Web services and that fol-
and NCIP protocols, but libraries may also be able
low a particular set of organizational principles can be
to enable additional efficiencies if they are able to
said to follow a service-oriented architecture, or SOA.
supplement these protocols through other APIs.
One of the most important concepts to understand
Single sign-on and authentication services. A key about an API is that it involves computer-to-computer
problem that many libraries face involves how interactions. Not to be confused with the user interface
their users sign in to their various applications. offered for humans, the applications programming inter-
Given the multitude of systems, it’s important to face involves allowing one computer system to interact
have some means of consolidating the function with other computer systems. As an application program-
that controls how users sign in. It may involve ming interface, it involves programmers. Those libraries
configuring the ILS to rely on an external authen- lacking technical staff capable of at least some software
tication service, or it may mean the ILS function- programming will not work with the APIs directly. Libraries
ing as an authentication service for external appli- without programming staff may benefit indirectly through
cation. Either way, the ILS must support the APIs capabilities executed on their behalf by third parties.
9 associated with authentication, such as LDAP, Some systems may have internal APIs designed for
0
20 ActiveDirectory, Kerberos, or Athens. the developers of the system, but these APIs may not be
er packaged in a way that makes them accessible to the per-
b Financial system integration. Many libraries need
m sonnel in the libraries that use the system. The presence
e to be able to exchange financial information with
c
e of APIs within the internal system framework designed
D other business systems in their institution. Pro-
er/ curement and fund management tasks that take for use by the software engineers that program the appli-
b
m cation itself may not be palatable platforms that will help
e place in the acquisitions module of the ILS often
v the personnel in the libraries that use the software cus-
o need to be transferred to an enterprise resource
N tomize it and maximize its capability. While the use of
planning (ERP) program (a genre of software that
g internal APIs reflects modern software design, we’re pri-
or large organizations use to manage their financial
e. marily concerned with APIs designed to be used by the
ourc data across different units) or other accounting libraries that implement the software. It’s these customer-
s systems for payment. In academic libraries, fees
ch facing APIs that directly benefit libraries using the soft-
e incurred in the library may need to be transferred
at ware, more so than the APIs that are geared more for use
al to a bursar’s office for collection through the stu-
w. by those involved with developing the application itself.
w dent’s institutional account. Some libraries may
w A customer-facing API needs to be largely abstract
want to offer online payments though through
s from the internal workings of the underlying system. It
ort their own or though their institution’s site using should offer high-level operations that do not require
ep third-party e-commerce products.
R detailed knowledge of the internal programming conven-
y
g Detailed reporting. Although all ILS products come tions within the ILS. The API should be independent of
o
ol with reporting modules that generally include the any given programming language or operating system.
n
h
c ability to produce customized reports, they may Most importantly, it must come with detailed documen-
e
T
y not have the ability to address all aspects of data tation that provides the library programmer with ade-
brar managed within the ILS. Many libraries are able quate information on the requests supported by the API,
Li to use an API to extract data in ways not possible the protocols and syntax involved, and the form of the
through standard reports. expected response.
8
Opening Up Library Systems through Web Services and SOA: Hype, or Reality? Marshall Breeding
API Implementation Models APIs in the form of reusable services. These services imple-
ment small units of work that form the building blocks of
As we approach the realm of application programming larger applications. The services may be used within the
interfaces, let’s think of applications that lack this archi- application at hand or exposed externally. Although any
tecture and step our way through progressive levels of new automation system created today would surely be
support. Figure 1 illustrates the most closed approach to service-oriented, most applications available in the library
programming. This type of application is completely self- arena predate the emergence of this approach and have to
enclosed. The software has exclusive access to any of the be retrofitted with service layers or APIs.
data involved. Whether the databases used are proprietary The history of library automation is dominated by
or based on standard relational database management sys- products that have evolved through many different cycles
tems (RDBMS) products, the customer has no access to of software architectures; few systems built from scratch
them other than through the interfaces delivered as part with new architectures of the prevailing age have emerged
of the software application. All of the functions of the and survived. Equipping these evolved systems with APIs,
software likewise cannot be accessed except through the especially in the form of Web services, represents one
interfaces delivered with the application for staff access or of the major factors in their forward progression. Those
public access, or through a reports module. that fail to adapt to this expectation may find themselves
Whether or not an application offers an API has little less competitive as the library automation market moves
to do with its completeness of functionality, sophistica- forward.
tion, or scalability. While ILS products that target small One of the first steps forward out of the purely propri-
libraries tend to be more self-enclosed, some of the legacy etary programming arena was for developers to take a more
systems serving larger libraries might also fall into this abstract approach to database access. Early automated sys-
category. The point of distinction here involves the nature tems managed data with proprietary methods. They stored,
of the application as entirely self-enclosed with no pro- indexed, and retrieved data in the most expedient and effi-
grammatic access to its internal data or functionality. cient ways possible, usually involving database functions
The extent to which a system offers APIs relates, to created by the developer of the application. Since almost all
a certain extent, to its vintage. Products designed more applications involve various aspects of data management,
than five years ago may not have originally incorporated the idea of continually creating this layer of functionality
APIs in their design. As these products evolved, most have within the application gave way to the use of third-party
come to include APIs that expose functionality through a database management systems. The use of a third-party
modern programming interface that may depend on inter- database management system allowed applications develop- L
ib
nal proprietary programming. ers to focus more of their resources on creating higher-level ra
r
Any major software application developed today functionality and less on reinventing lower-level data-access y T
would be programmed in a way that would naturally routines. The transition from database access routines writ- ec
h
involve APIs. The prevailing preferred approach to soft- ten for specific applications to third-party RDBMS prod- no
ware development involves the service-oriented architec- ucts often introduced a higher level of system overhead log
y
ture (SOA), which fundamentally embraces the concept of requiring more additional memory, disk storage, and pro- R
e
p
cessing power. These RDBMS products offered much more o
r
Application Based on internal advanced functionality and scalability. ts
proprietary programming The use of a third-party RDBMS comes with cost w
w
implications. Products such as Oracle require a separate w
.a
software license from the application software. When a la
te
library implements an ILS that uses a commercial RDBMS c
h
delivered s
product, it must either purchase the level of license o
interfaces required or take advantage of existing site license that its urce
.o
organization may have acquired. The ILS vendor may also rg

bundle the RDBMS license into its cost package. N
o
The use of proprietary databases continues to some v
e
Core extent in library automation systems. Two of the major m
software b
e
ILS products, Millennium from Innovative Interfaces r/
D
and Symphony from SirsiDynix, were initially developed e
c
data using proprietary databases. In both cases, the company em
stores b
offers its system with an option to use Oracle or another e
major RDBMS. For libraries that do not require Oracle for r 20
0
other reasons, many sites choose to use the proprietary 9
Figure 1
proprietary programming without Api. database. This option avoids additional licensing fees
9
Opening Up Library Systems through Web Services and SOA: Hype, or Reality? Marshall Breeding