EIE Web Services Messaging Specification - prod.eie.net.au Commercial in Confidence EIE Messaging Specification.doc 07Nov03 11:55 2003 Paradigm.One Pty Ltd Page 2 CONTENTS 1.INTRODUCTION

2003 Paradigm.One Pty Ltd Page 1

v1.0

Commercial in Confidence EIE Messaging Specification.doc 07Nov03 11:55


CONTENTS

1. INTRODUCTION............................................................................................ 51.1 Contents .................................................................................................................5

1.2 LDAP is optional.......................................................................................................5

2. MAPPING SYMBOLIC NAME TO URL ................................................................... 52.1 Several Ways to Map................................................................................................6

2.2 From LDAP ..............................................................................................................6

2.3 From UDDI Registry .................................................................................................6

2.4 Cache From UDDI Registry .......................................................................................7

3. DETERMINING NODE LIST MEMBERS.................................................................. 8

4. SIGNING MESSAGES AND VERIFYING SIGNATURES................................................... 84.1 Signing a Message ...................................................................................................8

4.2 Verifying a Signature ................................................................................................8

4.3 Finding Trusted Certificates.......................................................................................8

5. WSDL...................................................................................................... 95.1 In the UDDI Registry ................................................................................................9

5.2 Access Point Location ...............................................................................................9

6. CORE TMODELS ........................................................................................... 96.1 urn:eie:types:Environment......................................................................................10

6.2 urn:eie:types:Application ........................................................................................10

6.3 urn:eie:types:SymbolicName...................................................................................11

7. COMPOSING AND VALIDATING XML MESSAGES.....................................................117.1 Document/Literal Messaging Style ...........................................................................12

7.2 Composing XML Messages ......................................................................................12

7.3 Validating XML Messages ........................................................................................12

7.4 Locating an XML Schema ........................................................................................12

8. RECOMMENDATIONS.....................................................................................138.1 Parallel Conversations to Increase Throughput .........................................................13

8.2 No Undue Processing Dependencies ........................................................................13

8.3 Recommended Throttling Mechanism.......................................................................13

8.4 Logging.................................................................................................................14

8.5 Time synchronization..............................................................................................14

8.6 Maximize Interoperability........................................................................................14

9. LDAP DIRECTORY STRUCTURE .......................................................................149.1 LDAP Schema ........................................................................................................15

9.2 Symbolic Names.....................................................................................................15

9.2.1 Schema Design.............................................................................................15



9.2.2 Directory Information Tree ............................................................................17

9.2.3 Data Access .................................................................................................17

9.3 Node Lists .............................................................................................................17

9.3.1 Schema Design.............................................................................................17


9.3.3 Data Access .................................................................................................19

9.4 Digital Certificates ..................................................................................................19

9.4.1 Schema Design.............................................................................................20


9.4.3 Data Access .................................................................................................22

9.5 XML Schemas ........................................................................................................22

9.5.1 Schema Design.............................................................................................22


9.5.3 Data Access .................................................................................................24

10.REFERENCES..............................................................................................24



DOCUMENT CONTROL

Version Date Nature of Amendment AmendmentAuthor

1.0 30/09/03 Initial Paradigm.One



1. INTRODUCTION

This document is intended for subscriber application developers responsible for implementing amessage node/gateway to EIE using Web Services technology.

There exists a separate “EIE Messaging Specification” document that deals with messaging usingebXML. Some concepts in that document are the same as in this document. However, it was feltthe material presented would be clearer if the two were separated.

Everything in this specification has been implemented in Node-in-a-Box, which is distributedincluding the source code. This document is intended to aid in understanding the Node-in-a-Boximplementation.

It is recommended to read the EIE Overview & Concepts document first, as that will give you agood understanding of where this specification fits in the scheme of things.

It is assumed the reader is familiar with [SOAP], [SOAP-A], [WSDL], and [UDDI]. From thisfoundation certain messaging components require further specification as well as additionalmessaging components that have been added specifically for EIE.

1.1 ContentsThe following notions are described:

• Mapping Symbolic Names to URLs for message delivery

• Determining Node List membership for broadcast type messages

• Signing messages and verifying signatures

• Composing and validating XML messages

• Use of WSDL

• Core tModels

• Recommended use of parallel conversations to achieve higher throughput

• Recommended use of separate processing threads for each peer node to ensure any delay inmessage processing for one peer does not affect the message processing for other peers

• Recommended throttling mechanism, i.e. ability to control throughput

• Logging

• Time synchronization

1.2 LDAP is optionalTo facilitate reliable, fast and secure messaging certain information from the Administration Noderepository can be made available locally at each participant’s node, i.e. managed centrally at theAdministration Node and available locally via replication. LDAP was chosen as the mechanism fordisseminating this information and making it available at each participant’s node. It is a wellunderstood and industry standard approach for this type of requirement.

The use of LDAP is only required when messages are digitally signed, because of the need tovalidate the signatures against registered (valid) certificates. The registered certificates aredistributed through LDAP.

Along with certificates other data is also replicated, for example symbolic names. It is up to thesubscriber whether to use this replicated information, or rely on other sources such as the UDDIregistry.

The Administration Node LDAP server(s) are only accessible (except replication) via the WebPortal, i.e. no direct LDAP protocol access.

2. MAPPING SYMBOLIC NAME TO URLThis section describes, given a Symbolic Name, to look up its corresponding URL.



Applications can refer to another node on the EIE network via its Symbolic Name. But in order tosend a message, the messaging node needs to map the Symbolic Name to an URL.

For example, consider sending a message to a node identified by the Symbolic Nameurn:eie:PROD:App1:TCO0001. In order to send the message, this is mapped to the correspondingURL, e.g. http://eie.telco.com.au/App1.

A Symbolic Name is a URI of the format:

urn:eie:<environment>:<application>:<node>

The <environment> is either PROD or TEST, <application> is the name of the application, and<node> is the Symbolic Name of the node.

2.1 Several Ways to MapThere are several ways to look up the URL associated with the Symbolic Name: they can belooked up from LDAP, or from the UDDI registry in two ways. The LDAP method is the same as isused for ebXML messaging. The alternative is to look up the name in the UDDI registry. Twovariations of this are presented.

The benefit of using LDAP is that there is less dependency on the central Administration Node,because the LDAP resides locally with the messaging node. The benefit of using the UDDIregistry is that it’s more in line with standard Web Service practices.

2.2 From LDAPThis is the same method that is used for ebXML messaging. To look up the Symbolic Name inLDAP, do the following:

1. Construct an LDAP Distinguished Name (DN) with the following format

node=<node>,app=<application>,env=<environment>,system=EIE

For the above example, the constructed DN would be:

node=TCO0001,app=App1,env=PROD,system=EIE

2. Retrieve the LDAP entry identified by the resulting DN

3. Extract the value of the attribute named labeledURI. This is the required URL.

2.3 From UDDI RegistryEach Symbolic Name is stored in the UDDI registry as a tModel

1. In turn, the tModel is associated

with a Binding Template through a tModel Instance Info. The Binding Template holds the URLassociated with the Symbolic Name. Schematically this can be shown as follows:

1 For a description of tModels, Binding Templates, Access Points, etc please refer to [UDDI DATA].

http://eie.telco.com.au/App1



Business Entity

Telco

tModel

urn:eie:PROD:App1:TCO0001

tModel Instance Info

Business Service

Portability

Binding Template (with Access Point)


In this example, an organisation called “Telco” offers a web service called “Portability”. The webservice is accessed through a Binding Template that defines the URL ashttp://eie.telco.com.au/App1. Via a tModel Instance Info the Binding Template is associatedwith a tModel called urn:eie:PROD:App1:TCO0001, representing the Symbolic Name.

Using the UDDI Registry API ([UDDI API]) the algorithm to resolve a Symbolic Name to an URL isas follows:

1. Retrieve the tModel key of the tModel representing the Symbolic Name as follows:

<find_tModel generic=”2.0 ” xmlns= ”ur n:uddi-org:api_v2”>

<name>urn:eie:PROD:App1:TCO0001</name>

<categoryBag>

<keyedReference keyName="eie:types" keyValue="node"

tModelKey="uuid:DF29272E-7A92-4A10-A6BC-ACFDB04B75AC"/>

</categoryBag>

</find_tModel>

This call will return at most 1 tModel.

Note that uuid:DF29272E-7A92-4A10-A6BC-ACFDB04B75AC is a fixed value. It’s the key ofthe tModel that represents the Symbolic Name category.

2. Retrieve the service that references the tModel just retrieved:

<find_service generic=”2.0 ” xmlns= ”urn:u ddi-org:api_v2”>

<tModelBag>

<tModelKey>[tModel Key just retrieved]</tModelKey>

</tModelBag>

</find_service>

3. From the service returned, extract the binding template.

4. From the binding template, extract the access point. This holds the required URL.

2.4 Cache From UDDI RegistrySection 4.1.1.3 of the UDDI API Specification ([UDDI API]) describes an invocation patternwhereby the URL is obtained from the binding template, and then cached. The cached URL isused until a call fails. At that point, the binding template is re-queried from the UDDI Registry tosee if the URL has changed. If it has, and the call succeeds, then the new URL is cached andused from that point onwards.

To implement this, at development time retrieve the binding template key as in section 2.3above, following steps 1 to 3 but not 4.

At runtime, do the following:

1. Retrieve the binding template given the binding template key:





<get_bindingDetail generic=”2.0 ” xmlns= ”urn:uddi-org:api_v2”>

<bindingKey>[Binding Template Key]</bindingKey>

</get_bindingDetail>

This will return at most 1 binding template structure.

2. From the binding template, extract the access point. If the URL is different from the cachedURL, then retry the call and replace the cached URL if the call succeeds. If the URL is notdifferent, then the call fails.

3. DETERMINING NODE LIST MEMBERS

In some situations, depending on the application, a node will need to determine which othernodes are members of a particular node list.

To determine which nodes are members of a given list, do the following:

1. Construct an LDAP Distinguished Name (DN) with the following format

cn=<list name>,app=<application>,env=<environment>,system=EIE

For the above example, the constructed DN would be:

cn=LASD Broadcasts,app=App1,env=PROD,system=EIE

2. Retrieve the LDAP entry identified by the resulting DN

3. Extract the values of the attribute named uniqueMember. These are the members of the listas DNs. Note that the attribute uniqueMember is a multi-valued attribute.

3.1 The member DNs can be mapped to URLs as described insection 1.2 LDAP is optionalTo facilitate reliable, fast and secure messaging certain information from the Administration Noderepository can be made available locally at each participant’s node, i.e. managed centrally at theAdministration Node and available locally via replication. LDAP was chosen as the mechanism fordisseminating this information and making it available at each participant’s node. It is a wellunderstood and industry standard approach for this type of requirement.

The use of LDAP is only required when messages are digitally signed, because of the need tovalidate the signatures against registered (valid) certificates. The registered certificates aredistributed through LDAP.

Along with certificates other data is also replicated, for example symbolic names. It is up to thesubscriber whether to use this replicated information, or rely on other sources such as the UDDIregistry.

The Administration Node LDAP server(s) are only accessible (except replication) via the WebPortal, i.e. no direct LDAP protocol access.Mapping Symbolic Name to URL above.

4. SIGNING MESSAGES AND VERIFYING SIGNATURES

Some messages are signed before being sent. Which messages are signed (if any) is governed byapplication requirements. This section describes how to sign messages, and how to verify signedmessages that you receive.

4.1 Signing a MessageThe steps involved in signing a message are described in [SOAP Dsig].

The certificate used in signing the message must be present in the LDAP directory for the nodeidentified by its Symbolic Name. In other words, a node must sign messages using a certificatethat is present in the LDAP directory. This ensures that the recipient will be able to verify thesignature.



4.2 Verifying a SignatureVerifying a message is a two step process:

• Resigning the message, at each step comparing with the signature being verified. Thisensures the integrity of the signature.

• Verifying the signature was made with a trusted certificate

A certificate is trusted if it can be found in the local LDAP directory.

4.3 Finding Trusted CertificatesTo determine if a certificate is trusted do the following:

1. From the Symbolic Name, construct the DN, resulting in for example:

node=TCO0001,app=App1,env=PROD,system=EIE

2. Retrieve from LDAP all sub entries of that DN where the object class is equal toeieCertificate

3. Iterate over the resulting entries, for each entry:

1. Extract the entry certificate from the userCertificate attribute. The certificate is DERencoded, with X.509 v3 format.

2. Verify that the current date is between the Valid From and Valid To timestamps. If not,then continue with the next certificate

3. Attempt to match the entry certificate with the signature certificate

4. Stop if a match is found, the certificate is trusted

5. If no certificate is matched, then the signature certificate is not trusted, and a SOAP Faultmust be reported to the sender with a faultcode of soap:Client and a faultstringaccurately describing the problem.

Two certificates match if their fingerprint is identical.

5. WSDLWeb services are generally formally described using WSDL (Web Services Description Language[WSDL]). Many development tools exist to generate code automatically from WSDL. Referencesto the WSDL are stored in the UDDI Registry, providing a central place for subscribers’developers to access them.

5.1 In the UDDI RegistryAn approach of using WSDL in a UDDI Registry is described in [WSDL-UDDI]. This is theapproach that EIE takes. It describes how the data elements are set up in the UDDI Registry sothey can be found easily by tools.

In a nutshell, the approach is the following:

For each WSDL document a UDDI tModel is created that refers to the location of the WSDL.The tModel is categorized as a WSDL document.

An organisation wishing to provide the service described by the WSDL registers a UDDIBusiness Service structure referring to the tModel. The structure includes a UDDI BindingTemplate structure, which in turn includes a tModel Instance Info structure referring to thetModel.

For more details please refer to [WSDL-UDDI].

5.2 Access Point LocationThere are two places where the URL of an access point of a web service can be specified:



In a UDDI Binding Template

In a WSDL document

In EIE, the preferred mechanism is in a UDDI Binding Template. This allows a seamless changeof location of a service, for example when outsourcing a service to a third party, or when theprimary service fails and needs to be transferred to a secondary server. If the location URL werehard-coded in a WSDL document, then this scenario would be much more difficult (andexpensive) to accomplish.

When maintained through the Web Portal, the URL of a Symbolic Name is automaticallysynchronized with the URL in a UDDI Binding Template.

6. CORE TMODELS

In UDDI, tModels are used to establish the existence of a variety of concepts. Some of the EIEconcepts are captured as tModels.

6.1 urn:eie:types:EnvironmentThis tModel is used to define a managed namespace for Applications, Symbolic Names, NodeLists, XML Schemas, and digital certificates.

tModel UUID: uuid:5B020A3B-37D7-4825-95AD-454ADC75C097

tModel Structure:

<tModel tModelKey="uuid:5B020A3B-37D7-4825-95AD-454ADC75C097">

<name>urn:eie:types:Environment</name>

<description xml:lang="en">

An environment is a managed namespace for things like applications, symbolic names,

etc. EIE currently has two distinct environments: TEST and PROD.

</description>

<overviewDoc>


The EIE Overview & Concepts document available from the Web Portal

describes this concept further.

</description>

<overviewURL>

https://prod.eie.net.au

</overviewURL>

</overviewDoc>

<categoryBag>

<keyedReference tModelKey="uuid:C1ACF26D-9672-4404-9D70-39B756E62AB4"

keyName="types"

keyValue="categorization"/>


keyName="types"

keyValue="checked"/>

</categoryBag>

</tModel>

6.2 urn:eie:types:ApplicationThis tModel is used to define an application in the EIE context.

tModel UUID: uuid:03C0CFF1-735F-4172-9E12-E493FD8EFB8E



tModel Structure:

<tModel tModelKey="uuid:03C0CFF1-735F-4172-9E12-E493FD8EFB8E">

<name>urn:eie:types:Application</name>


An EIE application.

</description>

<overviewDoc>




</description>

<overviewURL>


</overviewURL>

</overviewDoc>

<categoryBag>


keyName="types"



keyName="types"


</categoryBag>

</tModel>

6.3 urn:eie:types:SymbolicNameThis tModel is used to define a Symbolic Name for a messaging node in the context of EIE.

tModel UUID: uuid:DF29272E-7A92-4A10-A6BC-ACFDB04B75AC

tModel Structure:

<tModel tModelKey=" uuid:DF29272E-7A92-4A10-A6BC-ACFDB04B75AC">

<name>urn:eie:types:SymbolicName</name>


An EIE symbolic name.

</description>

<overviewDoc>




</description>

<overviewURL>


</overviewURL>

</overviewDoc>

<categoryBag>


keyName="types"



keyName="types"


</categoryBag>

</tModel>

7. COMPOSING AND VALIDATING XML MESSAGES

A message is composed of multiple parts: the first part contains the SOAP envelope, which isfollowed by one or more attachments.



The SOAP envelope is a XML document, which can be validated against the SOAP Envelope XMLschema ([SOAP-ENV]), in combination with an application specific XML schema for the SOAPbody.

The attachments are usually also XML documents. If they are, you should be able to validatethem against the XML schemas as present in the local LDAP directory.

7.1 Document/Literal Messaging StyleThe SOAP specification was originally intended for remote procedure calls, and so naturallyfocussed heavily on method naming conventions and encoding of parameters. This style ofmessaging is often referred to as rpc/encoded.

The rpc/encoded messaging style is good for remote procedure calls, but less suitable for passingarbitrary documents. When passing arbitrary documents, naming conventions and encoding ofparameters is not necessary. This style of messaging is called document/literal.

The document/literal style of messaging is becoming dominant, because it is a superset ofrpc/encoded, and is so more flexible.

An additional benefit of document/literal is that it allows the SOAP body to be validated againstan XML schema as a whole. With rpc/encoded some “magic” is applied that is not captured in anXML schema, as it assumes an element in the SOAP body identifies a method to be called.

In conclusion, it is recommended that document/literal style be used for all messaging.

7.2 Composing XML MessagesThe SOAP envelope must be constructed in accordance with the SOAP Envelope XML schema([SOAP-ENV]).

If a payload is a XML document, then the XML schemas to validate it against are located throughthe namespace identifier. EIE namespace identifiers are URNs that have the following format:

urn:eie:<environment>:<application>:<schema name>

where <environment> is either PROD or TEST, <application> is the name of the application,and <schema name> is the name of the schema. Example of a namespace identifier:

urn:eie:TEST:App1:QueryNumberRequest.xsd

For example, consider the following payload example:

<?xml version="1.0"?>

<qnr:QueryNumberRequest xmlns:qnr="urn:eie:PROD:INMS:QueryNumberRequest.xsd">

<qnr:ServiceNumber>1800123456</qnr:ServiceNumber>

</qnr:QueryNumberRequest>

All XML elements are namespace qualified, with an EIE URN namespace identifier. See section7.4 for information on how to locate a XML schema identified by URN from the local LDAP server.

7.3 Validating XML MessagesIn SOAP with attachments ([SOAP-A]), there are two places the payload of a message can betransported: in the SOAP body and/or in the attachments. Normally, if the payload is XML it istransported in the SOAP body.

Validate the payloads by the following steps:

1. Iterate over the payloads

2. Validate the payload using a validating parser. The XML schemas are located as described insection 7.4

Note that not all payloads are XML documents.

7.4 Locating an XML SchemaTo retrieve the XML schema definition given a URN, do the following:



1. Construct a DN with the following format:

xmlSchema=<schema name>,app=<application>,env=<environment>,system=EIE

For the above example the result is:

xmlSchema=QueryNumberRequest.xsd,app=App1,env=TEST,system=EIE

2. From LDAP, retrieve the entry identified by the resulting DN

3. From the entry, extract the attribute xmlSchemaDefinition. This is the required XMLschema.

The xmlSchemaDefinition attribute is a text attribute.

8. RECOMMENDATIONS

This section describes a number of recommendations that will improve the behavior of themessaging nodes in the EIE network by making them more robust and making it easier to faultfind.

However, these aspects of messaging nodes are not subject to Compliance Checking.

8.1 Parallel Conversations to Increase ThroughputIn messaging applications, a huge increase in throughput can be achieved if multiple messagesare sent simultaneously. To maximize this effect, a messaging node should be capable of bothsending messages to multiple nodes at the same time, and send multiple messages to each nodesimultaneously.

To avoid a situation where a receiving node is inundated, the number of messages that is sentconcurrently should be controllable (see section 8.3 Recommended Throttling Mechanism below).

8.2 No Undue Processing DependenciesA messaging node should operate such that message exchange with one node doesn’t undulyinfluence message exchange with another node.

If a message can’t be delivered to a given destination node, then that shouldn’t stop messagesfrom being delivered to (or accepted from) another node. The same applies to acceptingmessages.

NodeA

NodeB

EIEnet

NodeC

NodeD

For example, in the above diagram, even though messages can’t be sent to Node B for somereason, node A continues to send messages to Node C and D.

8.3 Recommended Throttling MechanismEven if there are no undue processing dependencies between message exchange with differentnodes, there will always be some influence. For example, if a high volume of messages isreceived from node A, then due to CPU or network constraints the sending of messages tonode B might be slower that it would otherwise be.



To limit this effect, a messaging node should provide the ability to limit the number of messagesconcurrently sent per destination node. This should be configurable per destination node.

NodeA

NodeB

EIEnet

NodeC

NodeD

< 5

< 10

< 5

In the above diagram, the number of concurrent messages is limited to 10 for Node B, and 5 forNode C and D.

8.4 LoggingIt’s recommended that messaging nodes keep comprehensive logging of all messages and theircontent for problem tracking purposes.

For some applications keeping the content of messages will not be practical because of their size.In that case, the message attachments are excluded from logging, but the rest of the messageshould still be logged.

8.5 Time synchronizationWhen tracking problems in a distributed environment such as EIE, it’s important that the differentnodes keep the same time reasonably accurately.

It’s recommended that each node automatically synchronize its time with a trusted time sourceusing the Network Time Protocol (NTP). Implementations of this protocol are widely available formost hardware platforms. NTP will synchronize time to within low tens of milliseconds on WANsand sub milliseconds on LANs.

Many NTP servers are publicly accessible on the Internet, and it’s generally easy to set up an NTPclient to be a server for your own network (and so on).

8.6 Maximize InteroperabilityIt is recommended to comply with the “Basic Profile Version 1.0a” specification ([WSBP], alsoknown as the Basic Profile) wherever possible. This specification was written by the Web ServicesInteroperability Organization (http://www.ws-i.org) to clarify and amends various specifications([SOAP], [WSDL], and [UDDI] among others), with an aim to promote interoperability.

Different groups and organisations wrote the specifications the Basic Profile is based on. This hasresulted in specifications that are not always perfectly matched. Also, some features of thespecifications have over time turned out to be detrimental to interoperability. The Basic Profileattempts to address these issues and maximize interoperability by clarifying the underlyingspecifications and making amends wherever necessary.

Given that the underlying specifications are also used in EIE, the Basic Profile specification isrelevant to EIE, and its adoption is recommended.

9. LDAP DIRECTORY STRUCTURE

This section describes the LDAP directory design used for the EIE Administration Node. Itdescribes the data components held within the LDAP server, their object classes and attributedetails.

The following data components are covered:

http://www.ws-i.org



• Symbolic Names

• Node Lists

• Digital Certificates

• XML Schemas

Wherever possible, standard object classes and attribute types have been used with theapplicable RFC reference shown. Wherever new object classes are defined, standard attributetypes are used to ensure compatibility among the various available LDAP implementations.

9.1 LDAP SchemaEIE defines a number of specialized object classes and attributes. The definitions are available fordownload via the web portal in a file named eie.schema. Your LDAP server must be configuredto accept these definitions.

The eie.schema file references some object classes and attributes defined in core.schema, alsoavailable for download from the web portal.

9.2 Symbolic NamesThe purpose of using Symbolic Names is to isolate the URL address of subscriber nodes from anygiven application, i.e. a level of flexibility.

EIE applications refer to a Symbolic Name (for examplenode=0014,app=App1,env=PROD,system=EIE) to send messages to a given participant. At thepoint the message is actually sent this DN is queried in the participants local LDAP server yieldinga URL e.g. https://app1node.b.com.au/servlet/MessageReceiver).

The obvious benefit is that URLs can change on demand without impacting applications.

9.2.1 Schema Design

9.2.1.1 Object Classes

The EIE schema uses the following object classes for Symbolic Names.

9.2.1.1.1 top

This object class is defined in [RFC 2256].

9.2.1.1.2 eieSystem

This object class is used to represent the software system. Typically, this is the suffix (startingpoint in DIT) for a client implementation.

OID 1.3.6.1.4.1.12438.3.1.1 NAME ‘eieSystem’ SUP top STRUCTURAL MUST ( system ) MAY (description )

9.2.1.1.3 eieEnvironment

This object class is used to store the environment (e.g. PROD, TEST) under which the applicationis running.

OID 1.3.6.1.4.1.12438.3.1.2 NAME ‘eieEnvironment’ SUP top STRUCTURAL MUST ( env ) MAY (description )

9.2.1.1.4 eieApplication

This object class is used to store the name of the EIE application, e.g. App1, App2, etc. There isan existing object class applicationProcess that could have been used; however the name isnon-intuitive for EIE purposes. The definition is as follows:

OID 1.3.6.1.4.1.12438.3.1.3 NAME ‘eieApplication’ SUP top STRUCTURAL MUST ( app ) MAY (description )

9.2.1.1.5 eieNode

This object class is used to store the details about the nodes that are connected to the PIPN. Thenodes may be identified differently in different applications. For example, in App1 application the



nodes are identified by their CSP Id (0014, 0093, etc.), whereas in App2 application they areidentified by 3-character acronyms (‘TEL, ‘OPT’, etc.). The definition is as follows:

OID 1.3.6.1.4.1.12438.3.1.4 NAME ‘eieNode’ SUP top STRUCTURAL MUST ( node $ labeledURI $ o)

9.2.1.1.6 labeledURIObject


This object class is used to store the value for URL’s in the directory. It is an existing object classthe description of which is reproduced here for reference.

Name: labeledURIObject

Description: object that contains the URI attribute type

OID: umichObjectClass.15 (1.3.6.1.4.1.250.3.15)

SubclassOf: top

MustContain:

MayContain: labeledURI

9.2.1.2 Attribute Types

The EIE schema uses the following attribute types for the implementation of Symbolic Names.

9.2.1.2.1 system

This attribute contains the software system, always set to EIE.

OID 1.3.6.1.4.1.12438.3.2.1 NAME 'system' SUP name

9.2.1.2.2 env

This attribute contains the environment under which the application is running, for example PROD.

OID 1.3.6.1.4.1.12438.3.2.2 NAME 'env' SUP name

9.2.1.2.3 app

This attribute contains the name of EIE application, e.g. App1.

OID 1.3.6.1.4.1.12438.3.2.3 NAME 'app' SUP name

9.2.1.2.4 node

This attribute contains the identification of the participating node to the application,e.g. 0014, TEL.

OID 1.3.6.1.4.1.12438.3.2.4 NAME 'node' SUP name

9.2.1.2.5 name

[RFC 2256]

The name attribute type is the attribute super type from which string attribute types typicallyused for naming may be formed. It is unlikely that values of this type itself will occur in an entry.LDAP server implementations that do not support attribute sub typing need not recognize thisattribute in requests. Client implementations MUST NOT assume that LDAP servers are capable ofperforming attribute sub typing.

OID 2.5.4.41 NAME 'name' EQUALITY caseIgnoreMatch

SUBSTR caseIgnoreSubstringsMatch

SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{32768}

9.2.1.2.6 description

[RFC 2256]

This attribute contains a human-readable description of the object.

OID 2.5.4.13 NAME 'description' EQUALITY caseIgnoreMatch


SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{1024} )

9.2.1.2.7 o

This attribute contains the name of an organization (organizationName).



OID 2.5.4.10 NAME 'o' SUP name

9.2.1.2.8 labeledURI

This attribute is defined in [RFC 2079].

Name: labeledURI

ShortName: None

Description: Uniform Resource Identifier with optional label

OID: umichAttributeType.57 (1.3.6.1.4.1.250.1.57)

Syntax: caseExactString

SizeRestriction: None

SingleValued: False

9.2.2 Directory Information Tree

The structure of DIT is designed to find the URL of a particular node in an efficient manner basedon the information available to a given application. Specifically, the program will know theenvironment in which the application is running (the value of attribute env), the name of the EIEapplication (the value of attribute app), and the node it is sending the message to (the value ofattribute node). By supplying this information the DN of the required entry in DIT can be easilyconstructed, e.g. node=0014,app=App1,env=PROD,system=EIE to retrieve the URL.

system: EIEobjectClass: eieSystem

system=EIE

env: PRODobjectClass: eieEnvironment

env=PROD,system=EIE

env: TESTobjectClass: eieEnvironment

env=TEST,system=EIE

app: App1description: Application no 1objectClass: eieApplication

app=App1,env=PROD,system=EIE



node: 0014o: Telco1labeledURI: https://...objectClass: eieNode

node=0014,app=App1,env=PROD,system=EIE



node: TELo: Telco3labeledURI: https://...objectClass: eieNode

node=TEL,app=App2,env=PROD,system=EIE

9.2.3 Data Access

View - EIE subscribers can view all Symbolic Names via the web portal or own LDAP server

Change - EIE subscribers can only update their own Symbolic Name(s) URL via the web portal

Delete - EIE subscribers can only delete their own Symbolic Name(s) URL via the web portal

9.3 Node ListsNode Lists are used to nominate the node membership for a particular purpose, e.g. for App1 anode list called Network Providers identifies all the nodes to which particular messages arebroadcasted.

9.3.1 Schema Design


The EIE schema uses the following object classes for Node Lists.



9.3.1.1.1 top

[RFC 2256]

9.3.1.1.2 eieSystem









9.3.1.1.5 groupOfUniqueNames


The description is reproduced here for easy reference:

OID 2.5.6.17 NAME 'groupOfUniqueNames' SUP top STRUCTURAL MUST ( uniqueMember $ cn ) MAY (businessCategory $ owner $ ou $ o $ description )

9.3.1.1.6 Attribute Types

The EIE schema uses the following attribute types for the implementation of Node Lists:

9.3.1.1.7 system

This attribute contains the software system, currently always EIE.


9.3.1.1.8 env

This attribute contains the environment under which the application is running, e.g. PROD.


9.3.1.1.9 app



9.3.1.1.10 cn

This is the X.500 commonName attribute, which contains a name of an object. If the objectcorresponds to a person, it is typically the person's full name.

OID 2.5.4.3 NAME 'cn' SUP name

9.3.1.1.11 name







SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{32768} )


This attribute is defined in [RFC 2256]. This attribute contains a human-readable description ofthe object.



SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{1024}

9.3.1.1.13 uniqueMember

This attribute is defined in [RFC 2256]. The description is reproduced here for ease of reference.

OID 2.5.4.50 NAME 'uniqueMember' EQUALITY uniqueMemberMatch SYNTAX1.3.6.1.4.1.1466.115.121.1.34 )


The structure of DIT is designed to find the members of a particular Node List in an efficientmanner based on the information available to the application. Specifically, the program will knowthe environment in which the application is running (the value of attribute env), the name of theEIE application (the value of attribute app), and the name of the list to which the message isgoing to be broadcasted (the value of attribute cn) based on the message type. By supplying thisinformation the DN of the required entry in DIT can be easily constructed, for example,cn=Network Providers,app=App2,env=PROD,system=EIE to retrieve the members of the list.


system=EIE


env=PROD,system=EIE


env=TEST,system=EIE





cn: Mirror SubscribersuniqueMember: node=0014,...uniqueMember: node=0001,...objectClass: groupOfUniqueNames

cn=Mirror Subscribers,app=App1,env=PROD,system=EIE

cn: LASD SubscribersuniqueMember: node=0014,...objectClass: groupOfUniqueNames

cn=LASD Subscribers,app=App1,env=PROD,system=EIE

cn: Network ProvidersuniqueMember: node=TEL,...objectClass: groupOfUniqueNames

cn=Network Providers,app=App2,env=PROD, system=EIE

9.3.3 Data Access

All the EIE participants have view access to all the entries for Node Lists DIT.

No change or delete access is provided to any participants, the ANOC operators perform theseoperations.

9.4 Digital CertificatesThe EIE system uses digital certificates to enable applications to digitally sign and unsignmessages, thus providing a framework for secure messaging.



9.4.1 Schema Design


The EIE schema uses the following object classes for digital certificates.

9.4.1.1.1 top


9.4.1.1.2 eieSystem









9.4.1.1.5 eieNode

This object class is used to store the details about the nodes that are connected to the PIPN. Thenodes may be identified differently in different applications. For example, in App1 application thenodes are identified by their CSP Id (0014, 0093, etc.), whereas in App2 application they areidentified by 3-character acronyms (‘TEL, ‘OPT’, etc.). The definition is as follows:

OID 1.3.6.1.4.1.12438.3.1.4 NAME ‘eieNode’ SUP top STRUCTURAL MUST ( node $ labeledURI $ o)

9.4.1.1.6 eieCertificate

This object class is used to store the certificate serial number and details of the digital certificate.

The definition is as follows:

OID 1.3.6.1.4.1.12438.3.1.8 NAME 'eieCertificate' SUP top STRUCTURAL MUST (certSerialNumber $ userCertificate ) )


The EIE schema uses the following attribute types for the implementation of Digital Certificates.

9.4.1.2.1 system



9.4.1.2.2 env



9.4.1.2.3 app





9.4.1.2.4 node

This attribute contains the identification of the participating node to the application,e.g. 0014, TEL.

OID 1.3.6.1.4.1.12438.3.2.4 NAME 'node' SUP name

9.4.1.2.5 certSerialNumber

This attribute contains the unique serial number for the certificate.

OID 1.3.6.1.4.1.12438.3.2.5 NAME 'certSerialNumber' SYNTAX 1.3.6.1.4.1.1466.115.121.1.27DESC 'INTEGER'

9.4.1.2.6 userCertificate


This attribute is to be stored and requested in the binary form, as 'userCertificate;binary'.

OID 2.5.4.36 NAME 'userCertificate' SYNTAX 1.3.6.1.4.1.1466.115.121.1.8

9.4.1.2.7 cn

This is the X.500 commonName attribute, which contains a name of an object. If the objectcorresponds to a person, it is typically the person's full name.

OID 2.5.4.3 NAME 'cn' SUP name



This attribute contains a human-readable description of the object.



SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{1024}


The structure of DIT is designed to find the digital certificate in an efficient manner.




system=EIE


env=PROD,system=EIE


env=TEST,system=EIE









certSerialNumber: 123456userCertificate: <binary data>objectClass: eieCertificate

certSerialNumber=123456,node=0014,app=App1,env=PROD,system=EIE

certSerialNumber: 222222userCertificate: <binary data>objectClass: eieCertificate

certSerialNumber=222222,node=0014,app=App1,env=PROD,system=EIE

9.4.3 Data Access

View - EIE subscribers can view all certificates via the web portal or own LDAP server

Upload - EIE subscribers can only upload their own certificates via the web portal

Delete - EIE subscribers can only delete their own certificates via the web portal

9.5 XML SchemasAll messages exchanged between participants are in the form of XML documents, transported asSOAP messages. The XML documents must conform to defined XML schemas as stored in therepository.

XML schemas are used by the participants back-end systems to parse and create valid XMLdocuments. Replicating XML schemas ensures that every participant has the correct version, andchanges are distributed automatically.

9.5.1 Schema Design


The EIE schema uses the following object classes for XML Schemas.

9.5.1.1.1 top


9.5.1.1.2 eieSystem







OID 1.3.6.1.4.1.12438.3.1.2 NAME ‘eieEnvironment’ SUP top STRUCTURAL MUST ( env ) MAY (description ) )




9.5.1.1.5 eieXMLSchema

This object class is used to store the XML schema details.

OID 1.3.6.1.4.1.12438.3.1.7 NAME 'eieXMLSchema' SUP top STRUCTURAL

MUST (xmlSchema $ xmlSchemaDefinition )


The EIE schema uses the following attribute types for the implementation of XML Schemas.

9.5.1.2.1 system



9.5.1.2.2 env



9.5.1.2.3 app



9.5.1.2.4 name





SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{32768}

9.5.1.2.5 xmlSchema

This attribute contains the name of the XML schema e.g. App1.

OID 1.3.6.1.4.1.12438.3.2.6 NAME 'xmlSchema' SUP name

9.5.1.2.6 xmlSchemaDefinition

This attribute contains the actual definition of the XML schema. Since XML schemas are casesensitive, the matching rule and syntax reflects that.



OID 1.3.6.1.4.1.12438.3.2.7 NAME 'xmlSchemaDefinition' EQUALITY caseExactIA5Match

SYNTAX 1.3.6.1.4.1.1466.115.121.1.26


The structure of DIT is designed to find the details of a particular XML Schema in an efficientmanner based on the information available to the application. Specifically, the program will knowthe environment in which the application is running (the value of attribute env), the name of theEIE application (the value of attribute app), and the name of the XML schema that is being usedto parse or compose a message (the value of attribute xmlSchema). By supplying this informationthe DN of the required entry in DIT can be easily constructed, e.g.xmlSchema=PortMessage.xsd,app=App2,env=PROD,system=EIE to retrieve the information.


system=EIE


env=PROD,system=EIE


env=TEST,system=EIE





xmlSchema: PortRequest.xsdxmlSchemaDefinition: <text>objectClass: eieXMLSchema

xmlSchema=PortRequest.xsd,app=App1,env=PROD,system=EIE

xmlSchema: MirrorDBAdvice.xsdxmlSchemaDefinition: <text>objectClass: eieXMLSchema

xmlSchema=MirrorDBAdvice.xsd,app=App1,env=PROD,system=EIE

xmlSchema: PortMessage.xsdxmlSchemaDefinition: <text>objectClass: eieXMLSchema

xmlSchema=PortMessage.xsd,app=App2,env=PROD, system=EIE

9.5.3 Data Access

All the EIE participants have view access to all the entries for XML Schemas DIT.

No change or delete access is provided to any participants, the ANOC operators perform theseoperations.

10. REFERENCES

[SOAP] Simple Object Access Protocol (SOAP) 1.1 available fromhttp://www.w3.org/TR/2000/NOTE-SOAP-20000508

[SOAP-A] SOAP Messages with Attachments available fromhttp://www.w3.org/TR/2000/NOTE-SOAP-attachments-20001211

[WSDL] Web Services Description Language (WSDL) 1.1 available fromhttp://www.w3.org/TR/2001/NOTE-wsdl-20010315

[UDDI] UDDI Version 2 Specifications available from http://www.oasis-open.org/committees/uddi-spec/doc/tcspecs.htm#uddiv2

[UDDI DATA] UDDI Version 2.03 Data Structure Reference available fromhttp://uddi.org/pubs/DataStructure-V2.03-Published-20020719.htm

[UDDI API] UDDI Version 2.04 API Specification available fromhttp://uddi.org/pubs/ProgrammersAPI-V2.04-Published-20020719.htm

[WSBP] Basic Profile Version 1.0a available from http://www.ws-i.org/Profiles/Basic/2003-08/BasicProfile-1.0a.htm

http://www.w3.org/TR/2000/NOTE-SOAP-20000508

http://www.w3.org/TR/2000/NOTE-SOAP-attachments-20001211

http://www.w3.org/TR/2001/NOTE-wsdl-20010315

http://www.oasis-

http://uddi.org/pubs/DataStructure-V2.03-Published-20020719.htm

http://uddi.org/pubs/ProgrammersAPI-V2.04-Published-20020719.htm

http://www.ws-



[WSDL-UDDI] Using WSDL in a UDDI Registry, Version 1.08 available fromhttp://www.oasis-open.org/committees/uddi-spec/doc/bp/uddi-spec-tc-bp-using-wsdl-v108-20021110.htm

[SOAP-ENV] Schema for the SOAP/1.1 envelope available fromhttp://schemas.xmlsoap.org/soap/envelope/

[DSIG] XML-Signature Syntax and Processing available fromhttp://www.w3.org/TR/2002/REC-xmldsig-core-20020212/

[SOAP Dsig] SOAP Security Extensions: Digital Signature available fromhttp://www.w3.org/TR/2001/NOTE-SOAP-dsig-20010206/

http://www.oasis-open.org/committees/uddi-spec/doc/bp/uddi-spec-tc-bp-using-

http://schemas.xmlsoap.org/soap/envelope/

http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/

http://www.w3.org/TR/2001/NOTE-SOAP-dsig-20010206/

EIE Web Services Messaging Specification - prod.eie.net.au Commercial in Confidence EIE Messaging Specification.doc 07Nov03 11:55 2003 Paradigm.One Pty Ltd Page 2 CONTENTS 1.INTRODUCTION

Documents