 |
|
|
|
| > developer |
|
| Virtual Resources |
|
|
|
|
Virtual Resources Standards are the lifeblood of information technology and innovation. Some technical standards require participants to register their use and implementation of the standard's virtual resources. Novell has introduced many standards for the Novell environment which include virtual resources.Types of Virtual Resources  Directory OID/Prefix
NMAS Method
Novell Audit Application Identifier
NLM Name Prefix
IPX/SAP Service Type (Bindery Object Types)
IPX Static Socket Numbers
NCP Extension
|
|
|
|
 |
Directory OID/Prefix |
|
|
|
|
|
Novell eDirectory™ is a name service derived from the X.500 standard and is an object oriented, hierarchical, distributed, and replicated database. One feature of the directory is the ability to extend the types of objects that can be stored in the directory schema. By default many types of objects are available in the pre-defined base schema. However, developers may also add class and attribute (data element) definitions to the base schema, called schema extensions. Each schema class or attribute must have a unique OID.
An OID is a hierarchical identifier with periods separating each level. OIDs are read from left to right with the first value being the root. The value that follows is a sub-authority of the root. In most schema extension scenarios, all OIDs have the same base value with the trailing value rendering it unique. Software developers, for example, obtain a base OID to which they append values, creating their own unique OIDs.
Names should comply with LDAP conventions which allow only alpha-numeric characters and a single - character. In addition, the first character must be an alphabetic character. Delimiter characters such as space, underscore and colon should not be used. LDAP also requires the use of a valid OID or ASN1 ID with each class or attribute definition. In order to allow developers to define as many schema extensions as they need through the development and production environments, and ensure that the schema names are unique, developers should visit one of the online schema registries which register name prefixes, and can assign a unique sub-arc ASN1 ID if needed. Name prefixes are used by developers after they are registered to uniquely identify schema extensions. Name prefixes may consist of up to 12 alpha or numeric characters and should begin each schema extension name.
Example: WidgetMakers, Inc. registers "awidget" as a schema name prefix. Should they define a new slidingWindow class, they would define the new class name as awidgetSlidingWindow, using mixed case to make the name more readable, and assign it an ASN1 ID which begins with the assigned sub-arc and is uniquely numbered after the sub-arc. If an additional attribute type of slider were defined it would need a unique name as well, and could be defined as awidgetSlider and also given a unique ANS1 ID. No attribute or class may have the same name or ASN1 ID, as they are stored in the same domain and indexed via their name and ASN1 ID.
Most directory servers will allow you to specify an alpha-numeric name for an OID number. If WidgetMakers, Inc. hadn't registered for an OID, they may have assigned the "awidgetSlidingWindow" attribute an OID of "awidgetSlidingWindow-oid". It's unique, and as such serves the purpose.
Even though you may not need to register your own OID, it's still a good idea. LDAP attributes, syntax definitions, and object classes all use OIDs. So do SNMP and other protocols that support the ANSI unified identification scheme.
Get more information on Directory OID/Prefix registration.
Advantages Your extensions won't be in conflict with other registered extensions. Also, you are assured of a valid and unique OID. Disadvantages Changes to the directory schema are not always easily removed. Attributes can only be removed if they are not used in a class definition. If you add attributes to Novell base classes, you will not be able to remove them. Classes can be removed as long as there are no objects instantiated of that class type. The Novell base schema cannot be removed. Registration Novell no longer maintains a vendor-accessible Directory OID/Prefix Registry to generate Class and an Attribute OIDs based on Novell’s address space. Vendors can obtain a base OID directly from any ISO Name Registration Authority. We encourage you to search the Internet for a complete list of selections. Some examples include:
|
|
|
|
|
NMAS Method |
|
|
|
|
|
Login Service Methods (LSMs) must be digitally signed to operate under the NMAS framework. In order to sign a method you must use the Novell-supplied signing tools to generate a csr.ber file.
Send the generated file csr.ber to the email address devsup@novell.com - the subject line of the email should include the following wording: "Register Virtual Resource". After submitting your csr.ber file to Novell, please complete the online registration form. Once you have completed the registration form and clicked on the Submit button, the information you entered will be emailed to Novell and the registration information matched with your submitted csr.ber file - Novell will then email you two files: cert.ber, which is your signed certificate, and mib.ber, your module identification block. You will use these two files during the module signing process described in the NMAS Login Method Developer Manual, section 3.3.2. Registration |
|
|
|
|
IPX Static Socket Numbers |
|
|
|
|
|
The IPX protocol addresses packets in a Network:Node:Socket format. The Network field of an IPX address contains value that represents a logical IPX network segment. This value is assigned to the IPX network segment by the network administrator and must be unique throughout the entire IPX internetwork. The Node field of an IPX address contains a value that represents a logical node on an IPX network segment. This value is generally a number that is 'burned' into the Network Interface Adaptor (NIC) at the factory. The Socket field of an IPX address contains a value that represents a logical process within the node. This value is generally obtained by an IPX application dynamically using the IPXOpenSocket() function. Novell also administers a list of IPX sockets that are "well-known" in all IPX network environments. "Well-known" or "Static" IPX sockets are a virtual resource which is assigned to qualified applications by Novell. Resource Description and Parameters An IPX Static Socket is a 2-byte value that is uniquely assigned to an IPX application. Resource applicants may choose to make their assigned socket public or private. The list of public IPX Static Sockets is published quarterly by Novell. (See NDEVSUP; Library 14 (LAN Protocols); DSOC1?.EXE) Resource applicants can apply for an IPX Static Socket by submitting the following information to Novell:
Advantages Some IPX server applications send identical information to multiple nodes. In such cases, it is more efficient to send one broadcast packet rather than sending multiple packets "point-to-point". Static sockets are used by such applications as broadcast sockets. Disadvantages IPX Broadcast packets will not cross and IPX router and are therefore limited to one logical IPX network segment. This limitation can be overcome by implementing "IPX directed broadcasts". The IPXOpenSocket() function will allow a given socket number to be opened by only one caller. The socket must be closed by the original caller before it may be re-opened by another IPXOpenSocket() caller. Therefore, applications which use static sockets limit themselves to one executable instance of the application per IPX node. Packets which implement static sockets can be filtered by IPX routers. Some IPX network administrators implement such filtering to limit the amount of IPX broadcasts on a logical IPX network segments. Alternatives Novell strongly encourages developers to implement dynamically assigned sockets where possible. [For more information on Static vs Dynamic Sockets, see BULLETS November 1994, Page 6 "Static vs. Dynamic IPX Sockets" --Mark Oberg] Registration |
|
|
|
