JAIN^TM: APIs for the Integrated Network

JAIN TCAP Technology Compatability Kit (TCK) Specification
Version 1.1

RESTRICTED RIGHTS LEGEND: Use, duplication, or disclosure by the United States Government is subject to the restrictions set forth in DFARS 252.227-7013 (c)(1)(ii) and FAR 52.227-19.

The product described in this manual may be protected by one or more U.S. patents, foreign patents, or pending applications.

TRADEMARKS

Sun, the Sun logo, Sun Microsystems, Java, Java Compatible, JavaBeans, Solaris,Write Once, Run Anywhere, JDK, Java Development Kit, and JavaStation are trademarks or registered trademarks of Sun Microsystems, Inc. in the U.S. and certain other countries. UNIX is a registered trademark in the United States and other countries, exclusively licensed through X/Open Company, Ltd. All other product names mentioned herein are the trademarks of their respective owners.

THIS PUBLICATION IS PROVIDED AS IS WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, OR NON-INFRINGEMENT.

THIS PUBLICATION COULD INCLUDE TECHNICAL INACCURACIES OR TYPOGRAPHICAL ERRORS. CHANGES ARE PERIODICALLY ADDED TO THE INFORMATION HEREIN; THESE CHANGES WILL BE INCORPORATED IN NEW EDITIONS OF THE PUBLICATION. SUN MICROSYSTEMS, INC. MAY MAKE IMPROVEMENTS AND/OR CHANGES IN THE PRODUCT(S) AND/OR THE PROGRAM(S) DESCRIBED IN THIS PUBLICATION AT ANY TIME.

 Contents 

• 1.0 Introduction
  
  
• 2.0 Objectives and scope
  
  
• 3.0 Initial setup for TCK
  
  
• 4.0 Sending Events and Receiving Events
  
  
• 5.0 Test Results
  
  
• 6.0 Test Cases
  
  
• 7.0 Test Cases for future JAIN TCAP API Releases
  
  
• 8.0 Abbreviations
  
  
• 9.0 Abstract
  
  
• 10.0 Control
  
  
• Appendix 1 - Example Trace of API Requirements to TCK Tests
  
  
• Appendix 2 - Running the TCK

1.0 Introduction

Java APIs for Intergrated Network (JAIN) Framework brings Service Portability and Network Convergence into the Telephony Network. JAIN encompasses a standard set of interfaces for service creation and a number of standard interfaces for service execution.

The purpose of this document is to detail the Test Cases for the TCK relevant to the JAIN TCAP API. A TCK tests an implementation of an API for conformance to that API. The purpose of the JAIN TCAP TCK is to verify that a JAIN TCAP implementation is conformant to the JAIN TCAP API Specification [See JAIN TCAP Requirements Specification v1.3]. The Test Cases outlined in this document are based on the JAIN TCAP Requirements Specification that are specific to the remit of the TCK.

An example of how a requirement taken from the JAIN TCAP Requirements Specification is mapped to a Test Case defined in this document can be found in Appendix 1 along with an example piece of code that illustrates how this Test Case could be tested. This document also details the initial architectural setup required for the TCK. Instructions for running the TCK, along with screenshots of the TCK Graphical User Interface (GUI) can be found in Appendix 2.

The JAIN TCAP TCK can be run against a particular implementation of the JAIN TCAP API including the JAIN TCAP Reference Implementation (RI). The JAIN TCAP RI will emulate the functions of an SS7 stack (but will not provide all the functionality of an SS7 stack) in order to verify the requirements of this specification. The intention of the JAIN TCAP RI is not to implement an SS7 stack or to replace vendor SS7 stacks. The purpose of the JAIN TCAP RI is to provide a means to verify that JAIN TCAP applications are compliant to the JAIN TCAP specification. A JAIN TCAP Application may run over the RI in order to verify that it will run successfully over any Vendor's implementation.  The requirements for the RI are outlined in the JAIN TCAP API Requirements Specification v1.3. 

3.0 Initial setup for TCK

In order to execute the tests in Section 6.0, the TCK will first obtain an instance of the JAIN SS7 Factory singleton in order to instantiate a proprietary JainTcapStack object. The path name entered from the initial TCK GUI will be used to identify the location of this JainTcapStack implementation.

A proprietary JainTcapProvider will then be instantiated and attached to the JainTcapStack. The TCK will then register as a JainTcapListener with the JainTcapProvider [see Figure 3.1] and will begin sending and receiving JainTcapEvents as described in Section 4.0 in order to execute the Test Cases outlined in Section 6.0

4.1 SCCP User Addresses
 

A Tc_User (TCAP USER) Address uniquely identifies a particular Listener, but a Listener may handle more than one User Address.  Messages are sent from the Listener and addressed to the Destination node.  The Destination node's  SC_User address is the same as the originating Listener's TC_User address.  Therefore any messages sent from the Listener will be expected to be routed through the SS7 stack and back to the same Listener. (i.e. the Destination node).

The messages will be passed from the Listener to the JAIN TCAP Provider Implementation and into the SS7 stack.  These messages are considered local to the SS7 stack because the destination node has the same Signaling Point Code (SPC) as the SS7 stack.  In effect the Signaling Connection Control Part (SCCP) layer of the SS7 stack will recognize that the messages are local and route the messages back up the stack to the Provider.   The messages are then routed back to the Listener [See Figure 4.1].

Consequently as messages  travel only as far as the SCCP layer before they are routed back up the SS7 stack, only one SS7 stack is required in order to run the TCK test cases.

Figure 4.1 - JAIN TCAP API TCK Message routing.

4. 2 Method invocations

• The TCK Listener creates Components and Dialogues.
• The TCK Listener invokes the Provider's sendComponentReqEvent and sendDialogueReqEvent in order to send the ComponentRequestEvent(s) and DialogueRequestEvent(s).
• The manner in which the Provider's implementation handles the received components and dialogue events in order to interface with the SS7 stack is the responsibility of the Vendor.
• To pass received ComponentIndication Events and DialogueIndication Events to the Destination node (which is set as the originating Listener), the Provider will be required to invoke the Listener's processComponentIndEvent and processDialogueIndEvent methods respectively.
• The Listener appropriately handles the received primitives according to the test case being run.  
  

As a result of running the TCK a Test Report is produced. The TCK report includes a success status for each test. In addition a detailed execution trace will be output. Some screenshots from the TCK GUI can be found in Appendix 2 .

Many of the Test Cases, which are based on the JAIN TCAP API specification requirements applicable to the scope of the TCK, will be effectively passed if the TCK setup architecture is adhered to and components and dialogues can be routed successfully from Listener to destination. However the test cases outlined will individually test all appropriate aspects of the TCK and a report will be generated.

The JAIN TCAP TCK will only test a 1:1 Provider / Listener relationship. A future release of the JAIN TCAP TCK will test a multiple Provider / Listener relationship. Details of proposed test cases to be included in future releases of the JAIN TCAP TCK are outlined in section 7.0.

The test cases in this section consist of a Test Case name, reference number, the JAIN TCAP API requirement being tested, Test purpose and a Test result required for a success.

There is a specific test case for each requirement applicable to the TCK based on the JAIN TCAP Requirement Specification. The TCK Test Report [see Section 5.0] will individually list results based on each test case.
 
 

Test Reference	Test Case	Requirement being tested : TCAP Requirement Specification Reference
6.1	TCK SetUp	The ability to correctly setup the TCK architecture as detailed in section 3.0
6.2	Sending Component and Dialogue primitives from Listener to destination.	To ensure that Component and Dialogue primitives are sent from the Listener to destination.
6.3	Indication Event sending verification	REQ-ER-03-01: Indication Events shall only be sent from the Provider to the Listener
6.4	Verification of passing Events with same Dialogue ID to the same Listener.	REQ-ER-05-01: Events with the same Dialogue Id shall be passed to the same Listener.
6.5	Verification of Event passing to specified User Address.	REQ-ER-06-01: Events shall only be passed to the Listener with the corresponding User Address
6.6	DEPRECATED: This is done implicitly in the methods createProvider and deleteProvider. Verification of attachment and detachment of Provider to TCAP layer	REQ-PR-01-01: One or more Providers shall have the capability to be attached or detached to a TCAP layer at any time.
6.7	Provider message routing.	REQ-PR-03-01: A Provider shall be able to route messages to all Listeners registered with it.
6.8	Listener Message Routing	REQ-PR-05-01: All Events associated with a Dialogue (identified by the Dialogue ID) shall be passed to that Dialogue's Provider.
6.9	Verification of Event passing of TCAP messages passed through Provider Peer to Listener	REQ-PR-06-01: All TCAP messages shall be passed through the Provider peer to the Listener as Events
6.10	Listener registration	REQ-LR-01-01: All JAIN TCAP Listeners shall be able to register with all JAIN TCAP Providers
6.11	Verification of passing TCAP messages using the Event Model.	REQ-LR-03-01: The TCAP Listener shall receive TCAP messages from a JAIN TCAP Provider by following the JavaBean Event model. [See Section 3.3.1.1 of the JAIN TCAP API Requirements Specification]
6.12	Verification of API ability to map JAIN Mandatory protocol information	All JAIN Mandatory Parameters of received Dialogues and Components should be set correctly.
6.13	Verification of API ability to map protocol variant information.	REQ-CD-01-01: The API shall incorporate a common set of primitives that will map to protocol variant information. [See Reference 2-5 of JAIN TCAP API Requirement Specification]
6.14	Message order verification.	REQ-PR-07-01: The Provider peer shall ensure that the order in which associated components encapsulated as Events are received by in the same order at, which they are passed to the TCAP layer
6.15	Performance Testing	REQ-PF-01-01: Assuming a quiet system and no extraneous processing, the message latency from the top of the protocol stack through the API implementation into the JAIN TCAP Application shall not exceed on average one second.
6.16	Sending Components and Dialogues between Provider and Listener as Events.	REQ-ER-01-01: The API implementation should send Component and Dialogue handling primitives between the Provider and the Listener as Events.
6.17	Sending Component and Dialogue primitives separately between Provider and Listener.	REQ-ER-02-01: Events representing Component and Dialogue handling primitives shall be sent separately between the Provider and Listener.

Table 6.2 - Test Case Index

6.1.1 Test purpose

The ability to correctly setup the TCK architecture as detailed in Section 3.0.

6.1.2 Test procedure

As detailed in section 3.0, the user executes the TestSuite class. This prompts the user for a Stack Class name and Protocol version. The TCK Listener is instantiated, followed by a Factory object, a JAIN TCAP stack object and JAIN TCAP Provider which is attached to the stack. Registration for Event listening then takes place. Many of the procedures required to setup the TCK architecture, for example Event Listener registration, are listed as requirements of the JAIN TCAP API specification. Consequently verification of a correct setup will result in several of the Test Cases in this section including this one being passed.  This Test Case is passed if 6.2 and 6.9 are passed.

6.1.3 Test result

The Test Report includes a detailed execution log. In addition the status of all relevant Test Cases effected by the setup are reported in the Test Report. After setup the TCK Listener is able to send and receive Events.
 

6.2.1 Test purpose

To ensure that Component and Dialogue primitives are sent from the Listener to destination.

6.2.2 Test procedure

The TCK setup procedure should be adhered to. As outlined in Section 4.0 the Listener creates dialogues and components, which are routed to the destination. As the TCK v1.1 architecture includes only one Listener the destination is the Listener which sent the original message. If the Listener can successfully send and receive messages using the architecture detailed in Section 3.0 many of the test cases (including this one) in Table 6.2 will be passed.

6.2.3 Test result

The Test Report includes a detailed execution log. The report will list the messages received with a breakdown of their content. In addition the status of all relevant Test Cases effected by the sending and receiving of messages are reported in the Test Report.
 

REQ-ER-03-01: Indication Events shall only be sent from the Provider to the Listener

6.3.1 Test purpose

This test checks if Events of type Indication are sent from the Provider to the Listener.

6.3.2 Test procedure

The process of sending events from Listener to Destination outlined in Section 4.0 will be adhered to. The implementation of the JAIN TCAP API Listener restricts the object to receive events of type Indication, it therefore follows that if Sections 3.0 and 4.0 are adhered to this test is passed. However in addition a flag will be set if the Listener successfully receives an Indication event from the Provider. A list of received events will be reported.

6.3.3 Test result

The corresponding flag for this test will be set as passed, if the Listener receives an Indication event.
 

Figure 6.1 - Passing Events between Provider and Listener.

REQ-ER-05-01: Events with the same Dialogue Id shall be passed to the same Listener.

6.4.1 Test purpose

Tests that all Events with the same Dialogue ID are successfully passed to the same Listener.

6.4.2 Test procedure

As the TCK V1.1 for JAIN TCAP API is restricted to a 1:1 Provider: Listener relationship this test does not test the multiple cardinality aspect of the original JAIN TCAP API Requirement [REQ-ER-05-01]. However the process of sending events from Listener to Destination outlined in Section 4.0 will be adhered to. A predetermined number of Events are sent from the Listener. The Listener shall examine the Events received by it to ensure it receives all the Events associated with the same DialogueId.

6.4.3 Test result

This test will be considered passed if the Listener receives all the Events associated with the same DialogueId that it originally sent. The TCK execution log outputs details of primitives received and if all events are received successfully the test case flag is set as passed.
 
 

REQ-ER-06-01: Events shall only be passed to the Listener with the corresponding User Address

6.5.1 Test purpose

Tests the ability of the Provider to pass Events to a Listener with a specified User Address.

6.5.2 Test procedure

The TCK will check the Destination Address of all received JainTcapComponentEvents and JainTcapDialogueEvents to ensure that all received Events were passed by the implementation to the JainTcapListener with the correct User Address.

6.5.3 Test result

The test will be passed if the User Address of all received JainTcapComponentEvent and JainTcapDialogueEvents matches the expected User Address.
 

REQ-PR-01-01: One or more Providers shall have the capability to be attached or detached to a TCAP layer at any time.

6.6.1 Test purpose

This case will ensure that it is possible to attach a Provider to the JAIN TCAP Stack Object. It will also test the ability to detach the Provider.

6.6.2 Test procedure

As the TCK for JAIN TCAP API is restricted to a one Provider to Listener relationship this test does not test the multiple cardinality aspect of the original JAIN TCAP API requirement [REQ-PR-01-01]. If the TCK setup [section 3.0] is adhered to and the sending of Events [see Section 4.0] is successfully applied then the Provider attachment part of this test will be considered to have been passed. The TCK will attempt to detach the Provider to satisfy the second part.

6.6.3 Test result

The Provider is shown to successfully attach and then detach.

REQ-PR-03-01: A Provider shall be able to route messages to all Listeners registered with it.

6.7.1 Test purpose

As the TCK for JAIN TCAP API is restricted to a one Provider to Listener relationship this test does not test the multiple cardinality aspect of the original JAIN TCAP API requirement [REQ-PR-03-01]. This test case tests the ability of a Provider to route messages to its registered Event Listener.

6.7.2 Test procedure

The process of sending events from Listener to Destination node outlined in Section 4.0 will be adhered to. In order to route Dialogue Requests it sends back to itself, the Listener sets the Destination address as the Originating Tc_User Address.

6.7.3 Test result

The Listener examaines the Destination Address of all Dialogues it receives. If the Destination address is the same as the Tc_User Address of the Listener then this test is considered passed.

REQ-PR-05-01: All Events associated with a Dialogue (identified by the Dialogue ID) shall be passed to that Dialogue's Provider.

6.8.1 Test purpose

This test case tests the ability of a Listener to route messages to the appropriate Provider. As the TCK for JAIN TCAP API is restricted to a one Provider to Listener relationship this test does not test the multiple cardinality aspect of the original JAIN TCAP API requirement [REQ-PR-05-01]. This Test Case does not require the Vendor's Provider implementation to notify that that it receives all Events. However as all messages are rerouted back to the Listener through the Provider, if the Events received by the Listener have corresponding settings as those passed by it then this test is considered passed.

6.8.2 Test procedure

The process of sending events from Listener to Destination node outlined in Section 4.0 will be adhered to.

6.8.3 Test result

The receipt by the Listener of Component and Dialogue Indications with the same settings as the original Component and Dialogue Requests sent by the Listener will be considered sufficient to pass this test.
 

REQ-PR-06-01: All TCAP messages shall be passed through the Provider peer to the Listener as Events

6.9.1 Test purpose

To ensure that TCAP messages are passed through the Provider peer as Events.

6.9.2 Test procedure

Without imposing restrictions on the Vendor's Provider implementation it is not possible for the TCK to verify at the Provider level if TCAP messages are passed as Events. Therefore the process of sending events from Listener to Destination node outlined in Section 4.0 will be adhered to.

6.9.3 Test result

The receipt by the Listener of Indication Components and Dialogues with the corresponding settings as the original Component and Dialogue Requests sent by the Listener will be considered sufficient to pass this test. This ensures that the Provider handles Requests and Indications as Events.
 

REQ-LR-01-01: All JAIN TCAP Listeners shall be able to register with all JAIN TCAP Providers

6.10.1 Test purpose

To ensure that the TCK Listener can register with the Vendor's Provider. As the TCK for JAIN TCAP API is restricted to a one Provider to Listener relationship, this test does not test the multiple cardinality aspect of the original JAIN TCAP API requirement

6.10.2 Test procedure

If the TCK setup [Section 3.0] is adhered to and the sending of Events [Section 4.0] is successfully applied then the Listener registration will be considered to have been passed. Verification of successful Listener registration will be part of the Test Report.

6.10.3 Test result

Test is passed if the TCK Listener successfully registers as an Event Listener with the Provider.

REQ-LR-03-01: The TCAP Listener shall receive TCAP messages from a JAIN TCAP Provider by following the JavaBean Event model. [See Section 3.3.1.1 of the JAIN TCAP API Requirements Specification]

6.11.1 Test purpose

To verify that the Java Event Model is used for the passing of messages between the Listener and Provider. The TCK implementation constrains the Listener to receive TCAP messages by using the Java Event Model. The Listener accepts messages from the Provider only via Java Events.

6.11.2 Test procedure

Due to the architectural constraints imposed on the TCK Listener for sending and receiving messages, if the TCK setup [see Section 3.0] is adhered to and the sending of Events [Section 4.0] is successfully applied then this test will be considered to have been passed. Verification of successful Message passing and receiving by the Listener will be part of the Test Report.

6.11.3 Test result

Successful receipt of sent message.

 
6.12.1 Test purpose

Tests that received Indication primitives have ALL appropriate JAIN Mandatory Parameters set.

6.12.2 Test procedure

All received primitives are checked to ensure that ALL JAIN Mandatory parameters are set corresponding to the values sent by the TCK Listener.

6.12.3 Test Result

The test should confirm that the JAIN Mandatory parameters are set correctly.
 

REQ-CD-01-01: The API shall incorporate a common set of primitives that will map to protocol variant information. [See Reference 2-5 of JAIN TCAP API Requirement Specification]

6.13.1 Test purpose

Tests the ability of the API to map protocol variants incorporated in a common set of primitives. This relates to ANSI and ITU primitives, [see Tables 3.1 and 3.2 in the JAIN TCAP Requirement Specification.]

6.13.2 Test procedure

The TCK Listener shall set a selected set of parameters corresponding to both ANSI and ITU variants within a component being sent. Upon receipt of the returned component the Listener will attempt to access all the parameters corresponding to both ANSI and ITU variants. An exception should be thrown when the Listener tries to access the alternative Vendor stack implementation being used.

6.13.3 Test result

Test is passed if the Listener is able to successfully set the selected protocol variant parameter and subsequently the appropriate exception thrown when the component is received.
 
 

REQ-PR-07-01: The Provider peer shall ensure that the order in which associated components encapsulated as Events are received by it, is the same order at, which they are passed to the TCAP layer.

6.14.1 Test purpose

To ensure that the order in which messages are sent are the order in which they are received. To construct a test case, which maps directly to the TCAP API Requirement specification [REQ-PR-07-01] would involve imposing on the Provider the necessity to generate a report on the order it sends a message. Subsequently the TCAP layer would be required to output an analysis of the messages received by it. It is recommended that the TCK does not impose any restrictions on Vendor's implementations apart from those detailed in Sections 3.0 and 4.0. Thereby in order to pass this test a message with known order will be sent from the TCK Listener to a Destination node [see Section 4.0]. The destination node will analyze the order in which the message is received.

6.14.2 Test procedure

A message will be set from TCK Listener to destination node.

6.14.3 Test result

Test will be passed if the order received is the same as the order sent.

Figure 6.3 - Component sending order.

REQ-PF-01-01: Assuming a quiet system and no extraneous processing, the message latency from the top of the protocol stack through the API implementation into the JAIN TCAP Application shall not exceed less than or greater than one second.

6.15.1 Test purpose

As it is recommended that the TCK does not impose any restrictions on Vendor's implementations apart from those detailed in Sections 3.0 and 4.0, this test does not map precisely to the TCAP API Requirement specification[REQ-PF-01-01]. To do so would necessitate the TCK imposing that a timing device is present at the top of the protocol stack. However it is expected that sending a message from the TCK Listener to a destination node, a process which includes the message traveling from the top of the protocol stack through the API implementation into the JAIN TCAP Application, would take less than the specified time in the requirement. Therefore to pass this test case a message should arrive at the Destination node within one second of being sent.

6.15.2 Test procedure

A timer will be started as a message is passed from the TCK Listener. The process outlined in Section 4.0 will be adhered to. When the destination receives the message the timer will be stopped.

6.15.3 Test result

If time taken is less than or equal to one second then the test case will be considered passed.
 
 
 

REQ-ER-01-01: The API implementation should send Component and Dialogue handling primitives between the Provider and the Listener as Events.

6.16.1 Test purpose

To ensure that Components and Dialogues that are sent between the Provider and Listener are in the form of Events.

6.16.2 Test procedure

After initial setup of the TCK see [Figure 3.1], the process of sending events from Listener to Destination node outlined in Section 4.0 will be adhered to.

6.16.3 Test result

The TCK Listener is restricted to sending and receiving Components and Dialogues as Events, therefore the receipt by the Listener of Indication Components and Dialogues with the corresponding settings as the original Component and Dialogue Requests sent by the Listener will be considered sufficient to pass this test.
 

REQ-ER-02-01: Events representing Component and Dialogue handling primitives shall be sent separately between the Provider and Listener.

6.17.1 Test purpose

To ensure that the Events that are sent between the Provider and Listener are sent separately.

6.17.2 Test procedure

The process of sending events from Listener to Destination node outlined in Section 4.0 will be adhered to. As the Listener receives events they are examined to ensure that they contain separate Components and Dialogues.

6.17.3 Test result

The Listener shall receive Components and Dialogues as separate Events. The received primitives are checked to ensure they have the corresponding settings as those sent.
 

7.0 Test Cases for future JAIN TCAP API Releases

Due to the restriction of a one Provider to one Listener relationship the following requirements are not tested in TCK 1.1. It is envisaged that they will form individual test cases for future releases of JAIN TCAP APIs.

REQ-PR-02-01: The Provider shall have the capability to pass one or more Events to one or more registered Listeners. However, a Provider shall be able to send a particular Event to only one of the registered Listeners.

REQ-LR-02-01: A Listener shall have the capability to pass one or more Events to one or more Providers. However, a Listener shall send a particular event to only one Provider.

REQ-PR-04-01: Only one Provider shall be used to handle a particular Dialogue.

REQ-LR-04-01: A Listener shall have the capability to register with one or more TCAP Providers using one or more unique User Addresses to receive Events.
 

This document details the Technology Compatibility Kit specification requirements for which an implementation of the JAIN TCAP API must pass in order to be considered conformant to the JAIN TCAP Specification. The purpose of the JAIN TCAP TCK is to verify that a JAIN TCAP implementation is conformant to the JAIN TCAP Specification. 

 

Document ID:	TCK-JAINTCAP-001
Version:	1.0
Location:	$JAIN_HOME/devilerables/documents/tcap/v1_0/tck/Tcap_TCK_Specv1_0.html
Originator	Aidan Mc Gowan
Approval Date:	20th August 1999
Status:	Approved

 

Document ID:	TCK-JAINTCAP-001-d
Version:	1.0d
Location:	$JAIN_HOME/devilerables/documents/tcap/v1_0d/tck/Tcap_TCK_Specv1_0d.html
Modified	Phelim O'Doherty
Approval Date:	17th June 2000
Status:	Approved

Document ID:	TCK-JAINTCAP-001
Version:	1.1
Location:	$JAIN_HOME/devilerables/requirements/tcap/v1_1/tck/Tcap_TCK_Specv1_1.html
Modified	Eugene Bell and Phelim O'Doherty
Approval Date:	05th Sept 2001
Status:	Approved

Appendix 1 - Example Trace of API Requirements to TCK Tests   

The requirements specified in the JAIN TCAP Requirements Specification represent requirements both of the API and of an implementation of the API. Consequently, not all of the requirements specified in the JAIN TCAP Requirements Specification can or should be tested by the JAIN TCAP TCK as some of the requirements relate to the architecture of the API only and not to an implementation of the API. This section aims to identify how a requirement taken from the JAIN TCAP Requirements Specification can be traced to a Test Case defined in this TCK Specification, and provides an example code segment that illustrates how that Test Case could be tested in the JAIN TCAP TCK.

A.1 The Initial Requirement

The requirement listed below [REQ-ER-06-01] has been taken from the JAIN TCAP Requirements Specification (Version 1.3). This requirement represents a requirement of an implementation of the JAIN TCAP API and therefore should be tested by the JAIN TCAP TCK.

REQ-ER-06-01: Events shall only be passed to the JAIN TCAP Listener(s) with the corresponding User Address.

Since a JAIN TCAP Listener (or set of Listeners in a loadshare configuration) can be identified within a particular node by a User Address, the Events (representing TCAP component and dialogue primitives) intended for the JAIN TCAP Listener(s) should only be passed to the JAIN TCAP Listener(s) with that User Address. 

A.2 The Test Case defined in this TCK Specification

The Test Case listed below [Test Case 5] tests whether or not an implementation of the JAIN TCAP API satisfies the requirement [REQ-ER-06-01] listed in Section A.1

 

6.5 Test Case 5 Verification of Event passing to specified User Address.

REQ-ER-06-01: Events shall only be passed to the Listener with the corresponding User Address

6.5.1 Test purpose

Tests the ability of the Provider to pass Events to a Listener with a specified User Address.

6.5.2 Test procedure

The TCK will check the Destination Address of all received JainTcapComponentEvents and JainTcapDialogueEvents that contain a Destination Address to ensure that they were passed by the implementation to the JainTcapListener with the correct User Address.

6.5.3 Test result

The test will be passed if the Destination Address of all received JainTcapComponentEvent and JainTcapDialogueEvents containing a Destination Address matches the expected User Address. 

A.3 Example code segment illustrating how to test the Test Case

The following segment of example code illustrates how Test Case 5 could be tested by the JAIN TCAP TCK. In order to verify that all Events are passed to the JainTcapListener with the corresponding User Address, the TCK must register as a JainTcapListener of the implementation under test with a particular User Address. The TCK should then trigger the sending and receiving of Events and inspect all received Events that contain a Destination Address to ensure that the User Address of the received Events matches that of the TCK. Note that this test case, like many other test cases should be tested many times during the execution of the TCK. At any point during the execution of the TCK, if the User Address of the received Event does not match the User Address of the JainTcapListener then the test should fail.

The code segment below illustrates part of the code that would be required to perform this test. For clarity, no Exception handling is shown in the example.

 

     public class EventTester implements JainTcapListener {
	
	/**
	 * Constructs a new Event Tester.
	 * @param implUnderTest - the JainTcapProvider implementation to be tested
	 * @param ownAddress - the SccpUserAddress of this JainTcapListener
	 */
	public EventTester(JainTcapProvider implUnderTest, SccpUserAddress ownAddress) {
	
	    // register as a JainTcapListener with the application 
	    // for the specified user address

            implUnderTest.addJainTcapListener(this.ownAddress);
            this.address = ownAddress; 
	}



	/**
	 * This method is invoked by the provider whenever a Dialogue Indication primitive is received.
	 * For TEST_CASE_5, this method will check the user address of all primitives that contain a
	 * destination User Address (BeginIndEvent, UnidirectionalIndEvent and NoticeIndEvent)
	 * @param event - the dialogue indication event received from the Provider
	 */
	public void processDialogueIndEvent(DialogueIndEvent event){

	    switch(event.getPrimitiveType()) {

		case TcapConstants.PRIMITIVE_UNIDIRECTIONAL : {
		   
		   UnidirectionalIndEvent uni = (UnidirectionalIndEvent)event;
		   checkDestinationAddress(uni.getDestinationAddress);
		}

		case TcapConstants.PRIMITIVE_BEGIN : {
		   
		   BeginIndEvent begin = (BeginIndEvent)event;
		   checkDestinationAddress(begin.getDestinationAddress);
		}

		case TcapConstants.PRIMITIVE_NOTICE : {
		   
		   NoticeIndEvent notice = (NoticeIndEvent)event;
		   checkDestinationAddress(notice.getDestinationAddress);
		}
	    }
	}

	
	/**
 	 * Checks the supplied destination address to see if it matches the User Address
	 * of this JainTcapListener. If it does not match, then TEST_CASE_5 will fail.
	 * @param destAddress - the user address to be checked against this application's address
	 */
	private void checkDestinationAddress(SccpUserAddress destAddress) {

	    boolean pointCodeMatches;
	    boolean subsystemNumberMatches;

	     /**	
	      * Check to see if the signalling point code of the address matches
  	      * the signalling point code of this listener application.
	      * NOTE: A compare method is used to compare the two byte arrays for equality
	      */

	    if (CommonTools.compare(
			destAddress.getSignalingPointCode(),
			this.address.getSignalingPointCode())) {

		pointCodeMatches = true;
                TckOutput.print("The point code of the received DialogueIndEvent mathces the expected [" +
                                this.address.getSignalingPointCode() +"]");
            
            } else {

		pointCodeMatches = false;               
                TckOutput.print("The point code of the received DialogueIndEvent [" +
                                destAddress.getSignalingPointCode() + "] did not match the expected [" +
                                this.address.getSignalingPointCode() + "]");
            }

	     /**
	      * Now check to see if the received substem number matches
	      * the subsystem number of this listener application boolean 
	      */
	    
	    if (destAddress.getSubSystemNumber() == this.address.getSubSystemNumber()){

		subsystemNumberMatches = true;          
                TckOutput.print("The subsytem number of the received DialogueIndEvent mathces the expected [" +
                                this.address.getSubSystemNumber() +"]");

            } else {

		subsystemNumberMatches = false;	
                TckOutput.print("The subsystem number of the received DialogueIndEvent [" +
                                destAddress.getSubSystemNumber() + "] did not match the expected [" +
                                this.address.getSubSystemNumber() + "]");
            }

             /**   
              * If, in any of the received dialogue events, either the signallingPointCode 
              * or the subsystemNumber does not match, then TEST_CASE_5 will fail
              * NOTE: TckSuite.results[TEST_CASE_5] will have been initialised to true, and should
              * be set to false at the point where the test fails
	  */	

           if (!signallingPointCodeMatches || !subsystemNumberMatches) {

		TckSuite.results[TEST_CASE_5] = false; 
                TckOutput.print("The destination address of the received Dialogue Event was incorrect");
                TckOutput.print("TEST CASE 5: Verification of Event passing to specified User Address: FAILED");

        }

    }

     // the User Address of this JainTcapListener application
     private SccpUserAddress ownAddress = null;

}

Appendix 2 - Running the TCK  

The following section outlines the steps that are required to run the TCK:

JAIN TCAP TCK Main Screen

• Once all of the required details have been entered correctly the TCK can be started by selecting "Start TCK". This will bring up the 'JAIN TCAP TCK Output screen'.
  
• A trace of the execution of the TCK will be displayed in the 'JAIN TCAP TCK Output screen'. Once the TCK has completed executing all of the tests (this can be determined from the progress bar) the execution log can be printed by selecting 'Print'.
  
  
  

JAIN TCAP TCK Output screen

• Selecting 'Report' will display the 'TCK Test Case Results screen' . This summarises the Test Cases indicating which Test Cases have been succesfully passed or failed. This report can then be printed by selecting 'Print'.
  
   

TCK Test Case Results screen 

 05th Sept 2001
Copyright - 2001 Sun Microsystems
If you have any comments or queries, please mail them to [email protected]