XP and Soap are pretty equivalent, XP is a generalization of SOAP
Ray, Cotton, and Mark Needleman are all on the w3c XP committee
goal of xml protocol
allows peers to communicate in a distribute environment... in
a layered...
xp supports apps layered on top
supported by underlying protocols
apps over xp: P3P, circ., Dienst/OAI, z39.50
( P3P: privacy for personal preferences protocol)
lower layer protocols: xp over http, or directly over TCP/IP or over
smtp
xp alternatives: soap, xml-rpc, xmi, eb-xml
components of xp: envelope, provide serialization, rpc conventions, bindings
envelope - described by xml schema, with processing model
processing model applies to intermediaries and ultimate destinations
extensibility - reference to app specific payloads outside the xp envelope,
which extensions are optional/mandatory, etc.
rpc
convention for the content of the envelope when used for rpc applications
rpc is explicitly supported but arbitrary messaging patterns and scenarios
are implicitly supported
one supported common approach
messaging patterns
rpc, one way, publish-subscribe, multicast, permanently and intermittently
connected
serialization
mechanism for serializing data based on data models not directly representable
by xml schema types
subordinate relations known from attachments and manifests
http binding
xp is independent of underlying transports, but will provide explicit
http binding
intermediaries
proxies, caches, store and forward, gateways
this stuff is still in discussion
not supported: binary, compression, transport, application semantics, metadata
increased interest in supporting binary information, but not addressed
yet
above topics are currently out of scope
should provide facilities for common approach to authentication, encryption,
reliable delivery, transactions, etc.
example, based on soap
schedule
jan (2001): working draft
april: candidate recdomendation
sept: recommendation
questions
stuff within the soap wrapper must be in xml
so if z39 pdu is in soap, must be in xml
right now xp requires xml in the message
information could be sent outside the envelope, which could be binary
what problem does this solve?
do we want z39.50 to be a web-friendly protocol
if so, does xp do this?
Poul Henrik Jørgensen
overview of soap with z39.50 examples
background & objectives
z39.50 issues difficult to understand and debug
use human readable encoding
technology seems obscure to implementors
adopt emerging xml standards
ignored by mainstream development tools
use widespread xml tools
preserve full z39.50 functionality
implement unaltered asn.1 specifications
communicaton models
message passing with optional queueing
e.g. ISO ILL almost
applications must handle asynchronous messages from concurrent exteranl
processes
request/response
z39.50 almost
client intitiates request and waits for matching response from remote
process
resembles remOte procedure calls - rpc
rpc standards
rpc
sun rpc, e.g., nfs
dce rpc, e.g. windows nt
http
object rpc standards
corba iiop
ms com, dcom from microsoft
difficulte to use over WAN, work well locally
elements
request: objectid, interfaceid, methodid, extension headers, parameter
data
response: status code, extension headers, parameter data
issues of servialization/marshalling
soap overview
http supports most of the same functions as iiop and dcom - framing,
connection management, object references
xlm is well suited to represent parameter data
soap = http (transport) + xml (parm encoding)
soap elements
http header
reuest uri: soad classid and objectid
soap action: interfaceid and method
soap envelope (xml structure)
header - optional protocol
body - rpc parms, error reports
soap http request example
ez39.50 - z39.50 over soap
specification of e-z39.50 API
complete z39.50 protocol over soap
asn. encoded by XER
general IR API (GIR:API) features - not tied tightly to soap
async services excluded:
trigger resource control request
segment request
these break the rpc model, do not correspond to pure request/response
model
but soap could support these async services later
ez3950 Methods
init, search, present, deleteresultset, accesscontrol, etc.
examples: z3950 init request implemented and tested
normal init pdu encoded and included in a SOAP envelope
uses XER encoding
this example is a representative subset of the actual encoded pdu
what would be impact on XER if supported - no changes known so far
advantage is human readability, but is incredibly verbose
could you escape out and use rfc822 headers where possible
more concise for when you don't need structured information
would complicate processing - nested tools for different cases
possible in soap framework to use whatever convention is agreed
soap body must be xml, but could encapsulate glob of data, which is
non-xml encoded
e.g., use xml element, containg pdu encoded in rfc822
this example worked against a java soap gateway, which translated the
soap to a z39.50 server
why use XER then?
this makes an easy way to move Z39.50 intact over to soap without redefining
There are XER conversion tools available to convert to this form
advantage of this
newcomers will know how to work with xml and the newer higher level tools
lots of new tools don't expect you to write the xml by hand, it is generated
automatically using api
Init response
generated by a java object, which generated the encoded soap envelope
soap session handling
implmentation used cookies for session handling
microsoft tools use session ids instead of cookies
no notion of a soap session per se
from soap perspective, session ends after request/response
would need to manage session from the z39.50 level
use of XER
how critical is XER to this?
if you don't use XER, than need an equivalent to go from asn.1 to some
xml representation, i.e rewrite z39 pdus in xml, instead of asn.1. This
would be an enormous effort, and disruptive to the standard.
this is a trivial way to gateway to existing stuff, to retain interoperability
benefits of this solution
supports entire z39.50 protocol
XER standard with tools to encode asn.1
readable xml encoing of z39.50
object rpc model of z39.50 services
platform independent api for e-z39.50
tools from major vendors
acceptance among developers and executives - using XML and SOAP
puts z39.50 back in the mainstream
disadvange: larger XER encoding than ber - shouldn't really be an issue
gets away from Z39.50 firewall issues (port open for protocol)
Mark Needleman
topic: Circulation Protocol deliberations over SOAP
why NCIP did not use SOAP
circulation protocol from NISO
not an official standard at the time
uncertainty about support
lack of deployment
some ignorance about soap itself
didn't want to add one more level of complexity into the mix
no good sense of what it would do for us or what problems it might solve
was developing draft standard for trial use
will later bring back experience and apply what learned. could change to
use xp or soap later.
interchange of circulation information among systems NCIP
focused on application requirement/issues, rather than underlying technology
went with XML DTDs, but may move toward schema's later
for now, testing basic concepts of the protocol
xml protocol working group
working in a public mode, all technical discussions on public discussion
group
questions - what using instead of soap?
http, https, or directly over TCP/IP are choice of transport
3 appication areas supported
user self-service
expec web based clients to use http
servers will have to support both environments
D. Discussion
Want to consider using SOAP/XP?
can't really decide whether this will really work, based on limited experience
to date
there is another model: template approach, which makes the transport
somewhat more independent
try to make the IR definition independent of everything else: Note:
this has already been done, via ASN.1
Or recast Z39.50 in terms of the XML Query work
building a gateway to existing stuff would be more difficult
going with soap right now would not address being outdated. May
need a more drastic approach
going with soap would raise the issue of stateful session
Lennie: we are choosing from too many tools now. We are talking
about too many different things now.
Is there enough defined of the xml query language to base any thing on
this - will it meet our needs
Does this body endorse going with XER/SOAP?
Or an alternative approach, which could be addressed in parallel
Recasting the protocol is a separate issue from using a separate transport
mechanism
Ray: Cliff lynch's views
rewrite the z39.50 pdus in xml - be cautious about this, better also
decide whether to retain the semantics and functionality, or throw everything
open for discussion
what problems are we trying to solve?
if using z39.50 in the new environment
recast the functionality and semantics?
hard to address all of these questions at the same time
Ray: more concerned with addressing making Z a more web-friendly protocol,
not excited about redefining the protocol
Mark: just switching technology may not address all the resistance
Ralph: we need to address barriers to implementation. Dividing
it into parallel problems doesn't address this
Lenni: throw the whole thing out, look at barriers, not worry about existing
implementations
Kevin: incredibly difficult to promote Z39 if just reimplemented using
XER
Pat: Library perspective: percentage of info avail via z39.50 -
to increase this, in favor of not keeping everything we have now.
Matt Dovey: user feedback from UK: some mis perceptions about what users
really want in Z39.50
Elliot: if ZIG decides on new protocol, signal that library community
moving away from z39.50, support will drop quickly, and will lose interoperability;
possiblity of making z39 easily availbale for the new development environment,
possibly incluing a new-technology toolkit
something that works in the J2EE/EJB environment
a concrete API in Java, for example
Bob Waldstein:
searching external databases via broadcast searches to bibliographic
databases
there are issues with z39.50 other than tookits: But a ZIG reference
toolkit would have a bigger impact than individual toolkits
try to reduce the barriers to implementation
a well-defined api would push down the detailed issues of encoding
and transport, etc.
need combination of API and standard interface with supported underlying
technologies like XML and SOAP, etc.
Sebastian: oppose ZIG from making an official decision on which of these
options to pursue; would be harmful to existing implementations
does anyone have a problem with a bunch of implementors exploring the soap/xer
approach?
soap envelope could contain z39.50 stuff, plus missing stuff like session
id
Ray finds approach taken by elliot, matthew, etc. desirable, and
supports
they will pursue this, and keep the zig informed on how it goes
we will address other issues throughout the meeting