Service Location Working Group James Kempf INTERNET DRAFT Jonathan Wood Sun Microsystems, Inc 24 June 1998 The jndi-drivers Abstract Service Type draft-ietf-srvloc-jndi-drivers-00.txt Status of This Memo This document is a submission by the Service Location Working Group of the Internet Engineering Task Force (IETF). Comments should be submitted to the srvloc@corp.home.net mailing list. Distribution of this memo is unlimited. This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as ``work in progress.'' To view the entire list of current Internet-Drafts, please check the ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). Distribution of this memo is unlimited. Abstract This document describes the jndi-drivers abstract type. The jndi-drivers service provides access to drivers (also known as service provider classes) for the Java Naming and Directory Interface (JNDI). This type can be used in conjunction with the Service Location Protocol. 1. Introduction The Service Location Protocol is defined in [1]. Service templates and abstract types are defined in [2]. JNDI is defined in [3]. The Kempf, Wood expires December 1998 [Page 1] INTERNET DRAFT June 1998 jndi-drivers abstract type is intended to organize information pertaining to the location and access method needed to obtain dynamically JNDI drivers. Java class files can be obtained off the local file system or from the network. Hence drivers for JNDI need not be bundled with an application which uses JNDI; they can be downloaded from the network and dynamically instantiated (for instance, by a Java class-loader). The jndi-drivers type contains all information necessary to complete this process. The concrete type should be the access protocol used to retrieve the driver. The URL should also specify the host which provides access to the driver, and a path relative to the server host which names the location of the driver's class file archive. 2. Example Scenario This example demonstrates how to use this service type in conjunction with SLP and JNDI to dynamically instantiate a service provider for LDAP. LDAP is defined in [4]. An application running JNDI has only the core JNDI classes available to it locally. The application knows that it wishes to talk to an LDAP server, and has the information it needs to talk to that LDAP server: the server's name is "andromeda", serving the base suffix "o=sun,c=us", and it listens on port 389. (The application need not be preconfigured with the location of the LDAP service in order to make use of the dynamic loading of a JNDI driver for LDAP. The application could use SLP [1] to discover the LDAP server, though further discussion of this is beyond the scope of this document.) The application does not have the LDAP service provider classes, nor does it know where to obtain the classes. It does have the ability to use SLP, and can retrieve class files using the http protocol. In order to discover the location of the LDAP service provider classes, the application issues a SLP service request for the service type "service:jndi-drivers" with the predicate string "(&(service-type=ldap)(access-protocol=http))". The LDAP service provider classes are offered by the http server "jserver.sun.com", which is also advertising this offering via SLP. "jserver" thus sends a SLP service reply to the requesting application with the following URL: Kempf, Wood expires December 1998 [Page 2] INTERNET DRAFT June 1998 service:jndi-drivers:http://jserver.sun.com/java/drivers/ldap.jar;\ class=com.sun.jndi.LdapCtx;\ factory=com.sun.jndi.LdapCtxFactory The application now has enough information to retrieve the class files it needs. It will use the JNDI NamingManager to create an LDAP service provider context; to do so, it must first decompose the service: URL into a JNDI Reference. The following Java code fragment shows how this is done. Note that the ServiceURL object is defined in [5], which also defines an API for using SLP through which ServiceURLs can be obtained. Error handling is omitted for brevity. ServiceURL surl = // result from service request // Compose a JNDI Reference from the service: URL // Get the class name String urlPart = surl.getURLPath(); String className = urlPart.substring(urlPart.indexOf("class=")); className = className.substring(className.indexOf("=") + 1, className.indexOf(";")); // Get the factory class name String fact = urlPart.substring(urlPart.indexOf("factory=")); fact = fact.substring(fact.indexOf("=") + 1); // Reconstruct the URL for the class files String type = surl.getServiceType(); String proto = type.getConcreteTypeName(); String host = surl.getHost(); String factLoc = proto + "://" + host + urlPart.substring(0, urlPart.indexOf(";")); // Compose a JNDI RefAddr which will bootstrap the driver StringRefAddr refAddr = new StringRefAddr("URL", "ldap://andromeda:389/o=sun,c=us"); // Compose a JNDI Reference with all information needed to // instantiate and bootstrap the provider Reference ref = new Reference(className, refAddr, fact, factLoc); // Install a permissive security manager here ... System.setSecurityManager(new PermissiveSecurityManager()); // Retrieve, instantiate, and bootstrap the provider DirContext ctx = (DirContext) NamingManager.getObjectInstance(ref, null, null, null); Kempf, Wood expires December 1998 [Page 3] INTERNET DRAFT June 1998 The application now has a working LDAP DirContext object. 2. The "jndi-drivers" Abstract Service -------------------------template begins here----------------------- type = jndi-drivers version = 0.1 language = en scheme-description = The jndi-drivers service provides the following information: 1) The name of a service class, 2) The name of a factory object to create the service class, 3) A URL locating the factory object and service object Java code. This is an abstract type. The concrete type should be the access protocol used to retrieve the driver. This template takes advantage of the abstract types introduced with SLP V2 [1]. url-syntax = url-part = url ";class=" class name ";factory=" factory-class-name url = an URL as defined in [6] class-name = ;Fully qualified Java name of service class factory-class-name = ;Fully qualified Java name of the factory object's class service-type = STRING L #The SLP service type name for the driver. jndi-driver-version = STRING L #The driver's version number. access-protocol = string # The protocol used to access this driver. This attribute # is useful for SLP UAs which wish to query for a set of preferred # access protocols. This attribute should match the access protocol # given in the concrete type. --------------------------template ends here------------------------ contacts = "James Kempf" "Jonathan Wood" security-considerations = Drivers obtained from these service: URLs will ultimately be executed within process space of the instantiating application. As such, the application should take Kempf, Wood expires December 1998 [Page 4] INTERNET DRAFT June 1998 care to ensure that the driver is valid, and not malicious. Two possible means of ensuring a driver's validity are the use of SLP protected scopes, or by utilizing signed Java Archives (JAR files) provided by Sun's Java Development Kit (JDK) [7] References: [1] E. Guttman, C. Perkins, J. Veizades, M. Day, Service Location Protocol. draft-ietf-svrloc-protocol-v2-06.txt, May 1998 (work in progress) [2] E. Guttman, C. Perkins, J. Kempf, Service Templates and service: Schemes. draft-ietf-svrloc-service-scheme-10.txt March, 1998 (work in progress) [3] The Java Naming and Directory Interface (TM) Specification, Sun Microsystems, Inc. Feb 1998. http://java.sun.com/jndi/. [4] M. Wahl, T. Howes, S. Kille, The Lightweight Directory Access Protocol (v3). RFC 2251 [5] J. Kempf, E. Guttman, An API for Service Location draft-ietf-svrloc-api-05.txt, May 1998 (work in progress) [6] T. Berners-Lee, R. Fielding, and L. Masinter. Uniform Resource Locators (URL): Generic Syntax and Semantics. RFC1738 as amended by RFC1808 [7] The Java Development Kit Sun Microsystems, Inc. http://java.sun.com/products/jdk Authors' Addresses James Kempf Sun Microsystems 901 San Antonio Avenue Palo Alto, CA 94043 USA Phone: +1 650 786-5890 email: James.Kempf@Eng.Sun.COM Jonathan Wood Sun Microsystems 901 San Antonio Avenue Palo Alto, CA 94043 USA Phone: +1 650 786-4815 email: Jonathan.Wood@Eng.Sun.COM Kempf, Wood expires December 1998 [Page 5]