X-Git-Url: http://git.indexdata.com/?a=blobdiff_plain;f=doc%2Fintroduction.xml;h=4d2b25b79f19e644b5b447c2a67a66c3bbf5fe8e;hb=3dff993190eac9ccb1e9e8f681312493bdaf2fb9;hp=6710302fa11cb203453feafa2d193e463faaef63;hpb=0718fd63660899964512631d1e246ded8e3d18d6;p=yaz-moved-to-github.git diff --git a/doc/introduction.xml b/doc/introduction.xml index 6710302..4d2b25b 100644 --- a/doc/introduction.xml +++ b/doc/introduction.xml @@ -1,4 +1,4 @@ - + Introduction @@ -10,14 +10,10 @@ Properties of &yaz;: - Fast operation. The C based BER encoders/decoders as well - as the server component of &yaz; is very fast. - - Complete Z39.50 - version 3 support. All newer extensions - including Z39.50-2000 have been incorporated. + version 3 support. Amendments and Z39.50-2002 revision is + supported. Supports @@ -59,6 +55,10 @@ on Windows using Microsoft Visual C++. + Fast operation. The C based BER encoders/decoders as well + as the server component of &yaz; is very fast. + + Liberal license that allows for commercial use of &yaz;. @@ -91,7 +91,7 @@ - describes the generic frontend server + describes the generic frontend server and explains how to develop server Z39.50/SRW applications for &yaz;. Obviously worth reading if you're to develop a server. @@ -110,11 +110,15 @@ documents the most commonly used Z39.50 C data structures offered by the &yaz; API. Client - developers using ZOOM you do not need reading this. - For the remaining client developers (not using ZOOM), - reading this chapter is a must. - Z39.50 server implementors should read this, unless you're - developing a simple server (or SRW only). + developers using ZOOM and non-Z39.50 implementors may skip this. + + + + + + describes how SRW and SOAP is used + in &yaz;. Only if you're developing SOAP/SRW applications + this section is a must. @@ -157,12 +161,13 @@ toolkit offers several different levels of access to the ISO23950/Z39.50, ILL and - SRW protocols. + SRW + protocols. The level that you need to use depends on your requirements, and the role (server or client) that you want to implement. If you're developing a client application you should consider the ZOOM API. - It is, by far, the easiest way to develop clients in C. + It is, by far, the easiest way to develop clients in C. Server implementers should consider the generic frontend server. None of those high-level APIs support the whole protocol, but @@ -175,22 +180,54 @@ you're going to develop an ILL application you'll have to learn the lower level APIs of &yaz;. - - The basic low level modules, which are independent of the role - (client or server), consist of three primary interfaces: - + + + + The YAZ toolkit modules is shown in figure . + +
+ YAZ layers + + + + + + + + +
+ + There are four layers. - &asn;, which provides a C representation of the Z39.50 - protocol packages (PDUs). - - &odr;, which encodes and decodes the packages according - to the BER specification. - - &comstack;, which exchanges the encoded packages with - a peer process over a network. - + + A client or server application (or both). + This layer includes ZOOM and the generic frontend server. + + + + + The second layer provides a C represenation of the + protocol units (packages) for Z39.50 ASN.1, ILL ASN.1, + SRW SOAP. + + + + + The third layer encodes and decodes protocol data units to + simple packages (buffer with certain length). The &odr; module + encodes and decodes BER whereas the HTTP modules encodes and + decodes HTTP ruquests/responses. + + + + + The lowest layer is &comstack; which exchanges the encoded packages + with a peer process over a network. + + - + + The &asn; module represents the ASN.1 definition of the Z39.50 protocol. It establishes a set of type and structure definitions, with one structure for each of the top-level @@ -244,7 +281,7 @@ create a connection endpoint, you need to specify what transport to use (TCP/IP, SSL or UNIX sockets). For the remainder of the connection's lifetime, you don't have - to worry about the underlying transport protocol at all - the &comstack; + to worry about the underlying transport protocol at all - the &comstack; will ensure that the correct mechanism is used. @@ -255,7 +292,7 @@ The reason that the &yaz; service-level API is a conglomerate of the - APIs from three different submodules is twofold. First, we wanted to allow + APIs from three different submodules is twofold. First, we wanted to allow the user a choice of different options for each major task. For instance, if you don't like the protocol API provided by &odr;/&asn;, you can use SNACC or BERUtils instead, and still have the benefits of the