11 Using xNAL to exchange information between

xNAL has two main applications:

• name and address data exchange - discussed in this section
• persistent storage - discussed in Section 12, Using xNAL for persistent (database) data storage.

11.1 Scenarios

Name and address are probably some of the most common entities used across all enterprises. Name and address may be used alone, or what is more likely, as part of other more complex structures—this means endless variation in possible application scenarios. The scenarios can, however, be grouped into three areas ("use cases") as illustrated in Figure 21.

The three use cases are:

• API call - covers all possible APIs, whether platform dependent ( COM, .NET) or interoperable (such as web-services). xNAL can be used when data is being passed as a parameter or returned as a value after a function call.
• Flat file exchange - comes into play for example when there is a batch update of information, but it is not a desirable option for real-time or near-real-time solutions. It is not easy to achieve interoperability with real-time processing, due to different media formats. For example, a batch file with xNAL data compiled under a mainframe operating system may not easily be read on a Microsoft server.
• Database import/export - may occur for example between xNAL-compliant databases where the data models are identical or very similar. Data export may occur between non-xNAL-complaint databases if the data models are highly normalised, but there is no guarantee on the success of the exchange, and it is likely to require extensive XSL transformations.

Each of the above use cases support information-exchange policies as detailed in the E-government Interoperability Framework (e-GIF). (See http://www.e.govt.nz/interoperability/index.html.)

11.2 Elements for exchange

Not every element of xNAL may be exchanged on its own. It would require very complex implementations to account for all possible exchange options—this is considered impractical.

NOTE

The xNAL data exchange is limited to elements listed in Figure 22.

This constraint means that, for example, the xNLb:FirstName element should not be passed as a parameter of a cross-application API call. Instead, the applications should pass an xNLb:PersonName element with a child xNLb:FirstName element.

The elements listed in Figure 22 may be passed across application boundaries (see Figure 23 for an example of application boundaries) with all of their descendant nodes.

They may be passed on their own or wrapped in other elements from any namespace, (these are shown as ).

This constraint does not apply to the exchange within application boundaries where there is no requirement for interoperability at that level (shown as ).

VALID and INVALID examples of xAL infosets

The following two examples of xAL infosets are VALID for an interoperable exchange:

The following example is INVALID for interoperable exchange:

The above example is invalid because the FormerName element is not allowed to be on its own. It should come as a descendant of the PersonName element.

The following example provides a correct solution:

11.3 Compliance

An application that is fully or partially compliant with xNAL should be able to exchange (interoperate) with another application of the same level of compliancy at the data-exchange level.

11.4 Compliance requirements

11.4.1 Full compliance

An application is fully compliant with the NZ xNAL standard if the application can accept as input and return as output name and address data in XML form according to the NZ xNAL schemas and these guidelines.

11.4.2 Partial compliance

An application is partially compliant with one the namespaces of the NZ xNAL standard if the application can accept as input and return as output name or address data in XML form according to the schemas for that namespace and these guidelines.

11.5 Compliance testing

Compliance testing should be completed against the xNAL Compliance Testing Suite, which comprises a set of XML documents that should be used in the payload of the tested application. The application should successfully process all the documents from a particular namespace to claim conformance with that namespace. The application should successfully process all the documents from the suite to claim the full conformance. An application that successfully processes the data from the suite may claim the appropriate level of xNAL compliance.

NOTE

The xNAL Compliance Testing Suite is not yet available. This is expected to form part of the remit for future Working Group activity.

11.6 Information exchange through web-services

11.6.1 Software platforms for application of services with xNAL

xNAL is platform neutral. xNAL is used within the payload only.

xNAL may be applied in a vendor-specific environment such as MS Windows (COM, .NET) or mainframes, vendor-neutral environment such as Java, or web-based environment such as ebXML, GXA, or a loose combination of open standards for web services.

The scenario outlined in the following section may be equally applied to any of the environments as long as the payload is in the XML form.

11.6.2 Sample scenarios

A sample scenario for use of web-services with xNAL payload may be a trivial change-of-address service. This example is fully fictitious and implies no analogies with real-life solutions.

For example: Company A provides this type of service for citizens and also distributes the change of address information to other companies and government agencies. Company A provides only a Simple Object Access Protocol (SOAP) interface for this service, and a number of other companies resell this service to the end users through their custom web pages or over the counter.

The service requires a mixed payload, including name and address information as well as some other types of information that are outside the scope of xNAL.

11.6.3 Sample solution showing payload, schema, and instance

This section provides a high-level solution for the scenario outlined above.

A sample schema for the payload is illustrated below in Figure 24. It includes elements from xNL-basic and xAL namespaces as well as the special elements (e.g. Sevice Requested) from non-xNAL namespaces.

A sample payload instance would be:

This payload can be rendered in plain English as:

John Bloggs, Ellen Bloggs and Bloggs Dry Cleaning, Sewing and Ironing changed their address from 39 Amapur Dr, Khandallah, Wellington, PO Box 1234 to 12 Holly Gr, Maungaraki, Lower Hutt, PO Box 7890

11.6.4 Parsing the payload

This sample scenario presumes that the content is being processed and submitted to other Companies and Government Agencies in various forms. The processing activity includes all interactions with other recipients where the payload is being submitted.

A sample parsing and processing sequence is illustrated in Figure 25.

Figure 26 illustrates the interactions between the service, the user and other parties.

[ Previous | Next ]