Sponsored by the Alliance for Telecommunications Industry Solutions. CORBA Implementation Profile for Electronic Communications

Sponsored by the Alliance for Telecommunications Industry Solutions CORBA Implementation Profile for Electronic Communications TCIF-98-014 Issue 1 09/16/1999

Copyright Page TCIF Guideline CORBA Implementation Profile for Electronic Communications Prepared for TCIF by the Electronic Communications Implementation Committee. For more information about TCIF, go to http://www.atis.org/atis/tcif/index.htm. To order this document, please contact TCIF at (202) 434-8844, FAX (202) 393-5453. If you have questions or comments about this document, please contact: Shaun Chung, (303) 796-8646, shaun.a.chung@cpmx.saic.com Don Stewart, (404) 529-6959, donald.e.stewart@bellsouth.com Copyright 1999 ATIS. This document is printed and distributed by the Alliance for Telecommunications Industry Solutions ("ATIS") on behalf of the Telecommunications Industry Forum ("TCIF"). Participants in TCIF are hereby authorized to reproduce this document and distribute it within their own business organizations and to others for TCIF-related business provided that this notice continues to appear in the reproduced documentation. Reproduction and distribution for resale is prohibited. Trademark Acknowledgments CORBA and Object Management Group (OMG) are registered trademarks of Object Management Group, Inc. Object Request Broker (ORB), OMG Interface Definition Language (IDL), CORBAservices and IIOP are trademarks of Object Management Group, Inc. IONA is a registered trademark of IONA Technologies TCIF-98-014 Issue 1 Page 2 09/16/1999

TCIF Guideline Contents Contents 1 INTRODUCTION... 5 2 OBJECTIVES... 6 3 ARCHITECTURE... 6 4 DATA FLOWS... 7 SYNCHRONOUS MODEL... 7 ASYNCHRONOUS MODEL... 9 5 SECURITY... 10 5.1 AUTHENTICATION... 11 5.2 ACCESS CONTROL... 11 5.3 MESSAGE INTEGRITY... 11 5.4 MESSAGE PRIVACY... 11 5.5 NON-REPUDIATION... 11 6 CONNECTION GUIDELINES... 11 6.1 BINDING... 12 6.2 NUMBER OF CLIENTS PER SERVER... 12 6.3 CONNECTION ATTEMPTS... 13 6.4 FIREWALLS... 13 7 NAMING GUIDELINES... 14 7.1 NAMING SERVICE INTERFACE... 14 7.2 NAMING FORMAT... 15 7.3 ASYNCHRONOUS RESPONSE OBJECT... 15 8 OBJECT REFERENCE EXCHANGE GUIDELINES... 15 8.1 CUSTOMER SIDE SYSTEM INITIALIZATION... 15 8.2 DYNAMIC IOR DISCOVERY... 16 8.2.1 Loss of Object Implementation... 16 8.2.2 Client Side Impacts... 16 8.2.3 Server Side Impacts... 17 8.2.4 Persistent IORs... 17 9 PERFORMANCE CONSIDERATIONS... 18 9.1 LOAD BALANCING... 18 9.2 BUFFERING... 18 9.3 TIMEOUTS... 18 9.3.1 Client Gateway Timeouts... 18 9.3.2 Client OSS Timeouts... 19 9.4 THREAD POOLING... 19 10 ERROR GUIDELINES... 19 10.1 OPERATIONAL ERRORS... 19 10.1.1 Customer OSS Errors (A)... 20 10.1.2 Customer Gateway Errors (B)... 20 Issue 1 TCIF-98-014 09/16/1999 Page 3

Contents TCIF Guideline 10.1.3 Customer/Provider Connection Errors (C)... 20 10.1.4 Provider Gateway Errors (D)... 21 10.1.5 Provider OSS Errors (E)... 21 10.2 STANDARDIZING EXCEPTIONS AND ERROR CODES... 22 11 REFERENCES... 23 11.1 ACRONYMS... 23 11.2 DOCUMENTS... 23 List of Figures Figure 3-1 CORBA Architecture...7 Figure 4-1 Synchronous Model...7 Figure 4-2 Asynchronous Model...9 Figure 6-1 Connections...12 Figure 10-1 Error Scenarios...20 List of Tables Table 1.1 Client/Server Roles...6 Table 6.1 Firewall Filters...13 Table 10.1 Standard Error Codes...22 TCIF-98-014 Issue 1 Page 4 09/16/1999

TCIF Guideline Introduction 1 Introduction This document profiles the use of the Common Object Request Broker Architecture (CORBA) as a framework technology for Telecommunications Management Network (TMN) X-interface application. The TMN X-interface is used to communicate information between telecommunication carriers. This implementation profile does not standardize any new protocols, interfaces or services. Alternatively, this implementation profile utilizes OMG based standards and provides implementation usage rules for the explicit purpose of TMN X-interface Applications. CORBA s ORB interoperability architecture should be used to ensure interoperability of platforms between trading partner companies. CORBA-based applications interfaces will be defined using CORBA Interface Definition Language (IDL). In addition CORBA Common Object Services (COS) may be used to some extent between carriers. The implementation profile works in conjunction with the IDL design guidelines in the T1 Technical Report T1M1.5/1998. This document addresses design and implementation considerations that must be accounted for when implementing interoperable solutions between two trading partners using CORBA products that may be provided by multiple vendors. The terms client/server, customer/provider and initiator/responder are used throughout this document. Although similar, these terms are used in different contexts: Client/Server: Customer/Provider: Initiator/Responder: Application system architecture. A server is also called an object implementation. Entities across a TMN X-interface Entities responsible for initiating or responding to a transaction. A transaction may consist of more than 2 messages. When used within a particular context, the roles of initiator/responder and client/server are not fixed and can vary depending on the type of transaction and the mode of operation synchronous or asynchronous. For a customer request (e.g. address validation), the customer is the initiator and the provider is the responder. The roles of client and server are summarized in the following table: Issue 1 TCIF-98-014 09/16/1999 Page 5

Objectives TCIF Guideline Table 1.1 Client/Server Roles Entity (Operation) Synchronous Asynchronous Initiator (Request) Client Client Responder (Request) Server Server Initiator (Response) Client Server Responder (Response) Server Client For an unsolicited provider response, the initiator is the provider and the responder is the customer. The asynchronous mode of operation is not supported in this scenario. 2 Objectives The primary objective of this document is to provide technical guidelines for the implementation of TMN X-interfaces that utilize CORBA objects. Specifically the document should: Provide technical details for implementing interfaces based on applications specific Generic Implementation Guidelines when used with the T1M1 IDL specifications Profile the use of Object Management Group (OMG) standards (e.g. naming service) as required to meet the needs of other ECIC committees Provide design and implementation considerations for CORBA IDL based applications. 3 Architecture The architecture of an electronic communications application using CORBA consists of two application entities, CORBA clients and CORBA object implementations (servers). CORBA clients and servers can exist as part of either the initiator or the responder application. These two entities communicate using the logical communications architecture shown in Figure 3-1. CORBA General Inter-ORB Protocol (GIOP) messages are exchanged using Internet Inter-ORB Protocol (IIOP) with the security referenced in Section 5. IIOP, TLS, and SSL use the TCP transport. CORBA GIOP messages and how they are exchanged using IIOP are specified in the OMG CORBA specification. In addition, the exchange of GIOP messages using SSL is specified in OMG Document ORBOS/97-02-04. Specific implementation guidelines for SSL and TLS can be found in Section 5 of this document. If non-repudiation is required by the application, details for application-based non-repudiation can be found in the TCIF Guideline 99-008.Telecom Non-Repudiation Inter-ORB Protocol. The following diagram shows a typical high-level CORBA gateway architecture. TCIF-98-014 Issue 1 Page 6 09/16/1999

TCIF Guideline Data Flows CORBA Client Application Non- Repudiation Service Non- Repudiation Service CORBA Server Application GIOP GIOP SSL/3 or TLS SSL/3 or TLS TCP/IP TCP/IP Figure 3-1 CORBA Architecture 4 Data Flows This section illustrates the flow of data between the customer and provider. The communications implementation approach decision should be documented in the Joint Implementation Agreement/Arrangement (JIA). The choices are synchronous communication or a combination of synchronous and asynchronous communication. 4.1 Synchronous Model Figure 4-1 Synchronous Model In the synchronous method, the initiator invokes a method on a responder s request object. The initiator waits until the responder services the request and sends the reply data back. Issue 1 TCIF-98-014 09/16/1999 Page 7

Data Flows TCIF Guideline IDL example: interface AppointmentScheduling { LocalPOINQPTypes::Status_t CancelReservationOrSelection( inout LocalPOINQPTypes::CompanyCode_t companycode, in LocalPOINQPTypes::CustomerCarrierNameAbbreviation_t customercarriernameabbreviation, inout TimeTypes::DateTime_t dateandtimesent, Request Response Initiator Respond inout Base::InquiryId_t inquirynumber, in LocalPOINQPTypes::InquiryResponseNumber_t inquiryresponsenumber) raises(base::invaliddata,base::missingdata, Base::ProcessingFailureError, Base::AccessDenied); }; TCIF-98-014 Issue 1 Page 8 09/16/1999

TCIF Guideline Data Flows 4.2 Asynchronous Model Request Confirm Response Confirm Initiator Respond Figure 4-2 Asynchronous Model In the asynchronous method, the initiator invokes a method on a responder s object passing the request data and optionally, the Interoperable Object Reference (IOR) of the initiator s response object. The responder will immediately respond with an acknowledgement of receipt of the message. This will prevent the initiator from being blocked while waiting on the reply. When the responder completes the request, it invokes a method on the initiator's response object using the initiator's response object s IOR and passes the response data. The initiator processes the response and sends a confirmation back to the responder. The asynchronous method inherits from the synchronous method thereby allowing synchronous or asynchronous communication. IDL example: interface AppointmentSchedulingWithCallBack : AppointmentScheduling { void cancelreservationorselectionbycb( in LocalPOINQPTypes::CompanyCode_t companycode, in LocalPOINQPTypes::CustomerCarrierNameAbbreviation_t customercarriernameabbrviation, in TimeTypes::DateTime_t dateandtimesent, in Base::InquiryId_t inquirynumber, in LocalPOINQPTypes::InquiryResponseNumber_t inquiryresponsenumber) Issue 1 TCIF-98-014 09/16/1999 Page 9

Security TCIF Guideline 5 Security raises( Base::ProcessingFailureError ); }; This section of the CORBA Implementation Profile provides guidelines for the use of various security mechanisms to meet the security needs associated with implementation of application interfaces as defined by other ECIC sub-committees. The security requirements addressed include authentication, access control, message integrity, nonrepudiation, and message privacy. The security specified in these guidelines is based on the Transport Layer Security (TLS) standard developed by the Internet Engineering Task Force (IETF). Secure Socket Layer version 3 (SSL3) can provide equivalent security. The selection of TLS is based, in part, on the following considerations: CORBA IIOP transactions can be carried directly over TCP/IP. Inclusion of TLS between IIOP and TCP (Transport Control Protocol) does not impact IIOP (with the possible exception of a different port number). In the course of a session, IIOP messages are handed over to TLS. These messages may be fragmented or combined by TLS, subjected to security transformations, and delivered to the receiver. At the receiver, the security transformations are reversed and the original IIOP messages are reconstructed. The following guidelines should be to secure IIOP transactions: strong peer entity authentication, based on public key encryption shall be provided for all associations (this precludes interoperability with SSL2) session secret shall be encrypted with receiver s public key message encryption is optional SHA1 shall be used for integrity. Non-repudiation or message integrity can be provided, optionally, by higher layers. if privacy protection by TLS is chosen, then DES (Data Encryption Standard) in the CBC (Cipher Block Chaining) mode shall be used for symmetric key encryption every participant is required to obtain a public key certificate from a CA acceptable to the communicating parties message integrity and non-repudiation should be computed on clear text (unencrypted) messages, entity public key size shall be at least 768 bits CA s public key size shall be at least 1024 bits Certificates shall be X.509 version 3. TCIF-98-014 Issue 1 Page 10 09/16/1999

TCIF Guideline Connection Guidelines The ciphersuites to be used must be decided upon during design and specified to each trading partner. Recommended cyphersuites include:! RSA, NULL, SHA1 (if no privacy protection is desired)! RSA, DES - CBC, SHA1 (if privacy protection is desired) Current vendor implementations of SSL/3 have interoperability problems. These problems should be taken into consideration. The following sections detail the security guidelines that should be followed for various security areas. 5.1 Authentication Authentication should be provided as described in OMG Document ORBOS/97-02-04, Secure Socket Layer/CORBA Security. 5.2 Access Control Access Control is an application layer function that is implemented on the server side. A combination of the X.509 certificate information contained in the CORBA message as defined in the IDL should contain the information necessary for Access Control. 5.3 Message Integrity Message Integrity should be provided as described in OMG Document ORBOS/97-02- 04, Secure Socket Layer/CORBA Security. 5.4 Message Privacy Message Privacy should be provided as described in OMG Document ORBOS/97-02- 04, Secure Socket Layer/CORBA Security. 5.5 Non-Repudiation Non- Repudiation should be provided as specified in TCIF Guideline 99-008, Telecom Non-Repudiation Inter-ORB Protocol. 6 Connection Guidelines Connection management is the process of managing the TCP connections that are maintained between communicating host systems. For the TMN X-interface implementation guidelines specified in ECIC, a customer implementation may utilize one or more host systems requiring connections to be established with provider implementations. Similarly, a provider implementation may be distributed across 1 or more hosts, requiring multiple connections to be established between provider and customer implementations. For example (see Figure 6-1), client implementation on host A needs to communicate with three different objects on host B. In the first scenario, on the first invocation to host B, client A requests a connection to be established. For each subsequent invocation made on host B, client A reuses the existing connection. In the Issue 1 TCIF-98-014 09/16/1999 Page 11

Connection Guidelines TCIF Guideline second scenario, client C is programmed to establish new connections for each object that is being invoked. This leads to the establishment of three different connections. These connection concerns should be transparent to an application. However, ORB vendor implementations make different assumptions concerning connection management, subsequently resulting in the specification of different APIs available to client applications. While some vendor specific API calls do not impact interoperability, if customer-provider implementations are developed with little cooperation, interoperability of implementations may suffer. Host A Host B Client A Port Processes Host C Host D Client C Figure 6-2 Connections Most of these connection management concerns should not be specified in a generic guideline. It is the responsibility of trading partners to agree on certain connection parameters concerning connection management. This section identifies some of the key parameters that should be agreed upon within a JIA. 6.1 Binding To ensure interoperability, CORBA based Interoperable Object References (IORs) and Internet Inter-ORB Protocol (IIOP) should be used between trading partners. 6.2 Number of Clients per Server The maximum number of connections made to a server or from a client may be configured. To achieve expected behavior, the number of clients per server allowed should be decided within a JIA. The JIA should also specify whether and when are connections gracefully aborted (client aborted connection) and when are connections refused by a server. TCIF-98-014 Issue 1 Page 12 09/16/1999

TCIF Guideline Connection Guidelines Reasons for multiple connections between customer and provider include: clients wishing to have fine grained control over different operations or a client distributing its application across multiple hosts. In theory, a server may allow an infinite number of connections to be established. Realistically, there is some maximum number of connections that will allow the server to maintain certain performance characteristics. Providers may need to specify in JIAs, the maximum number of connections that a customer may initiate. If customers begin to exceed provider expectations on the number of connections that are being established, undesired effects may occur. ORB implementations handle these connection management concerns in different manners. For example, some ORBs will time out least recently used connections to allow newer connections to be established. Other ORBs may reject new connections if the maximum number of connections is already reached. 6.3 Connection Attempts A JIA should clearly identify the conditions under which different exceptions regarding connection attempts will be triggered. The explicit exception must also be identified. These assumptions are critical to how a client application is implemented. When establishing connections between hosts, the TCP layer of the stack may reject the connection. ORB implementations offer different mechanisms for retrying the connection attempts. Some ORBs have default mechanisms that retry connection attempts periodically removing the burden of establishing connections from the application developer. Other ORBs may require the application developer to re-attempt connection establishment. These connection attempt mechanisms are implemented on the client side only. The server application does not care if the reconnection attempts are made from system level or application level code. However, under certain circumstances, the server side may know that it can not reestablish connections for a finite time period. It would therefore waste resources if a client application reconnects too frequently. 6.4 Firewalls CORBA supports both synchronous and asynchronous communication as described in this document Section 4. In using either method, a screening router or any router that performs filtering should be used. The Customer and Provider may enable filtering by protocol type, local address, local port, remote address, and remote port, (See Table 6-1 for filtering details). Table 6.1 Firewall Filters Filter by: Protocol type Local Address Description TCP/IP Down to the third octet Issue 1 TCIF-98-014 09/16/1999 Page 13

Naming Guidelines TCIF Guideline Local TCP port number Remote IP address Remote TCP port number Asynchronous: Min. 1 port per Customer/Provider pair application And/Or Synchronous: Min. 1 ports per Customer/Provider pair application Down to the third octet Asynchronous: Min. 1 ports per Customer/Provider pair application And/Or Synchronous: Min. 1 ports per Customer/Provider pair application Protocol type refers to a specific protocol, such as TCP. Local and remote addresses should be configured down to the third octet to prevent unwanted or unknown systems from accessing restricted areas. Local and remote TCP port numbers should be under 32,768 1. A sufficient number of ports should be configured when using the synchronous or asynchronous method of communication to accommodate future growth. Additional implementation techniques may be needed to support various network configurations. For example, in firewall environments that require address translation, application code can be used to manipulate addresses and ports embedded in the IORs. This is because the originating ORB will be sending to an IP address that differs from the actual destination EC gateway s IP address. The translation code will translate the CORBA gateway IP and port to the firewall IP and port. Problems with interoperability of current implementations of IIOP over SSL may limit the choices available for users of some firewall arrangements. 7 Naming Guidelines 7.1 Naming Service Interface The CORBA COS Naming Service should be used to resolve object references. This naming service supports operations for building and querying a naming hierarchy. To support the inter-company TMN X-interface, only the resolve operation on the COS Naming interface needs to be utilized. The resolve operation takes a name as input and provides a return value of type "object". Each particular application may support many different interfaces (e.g., pre-order supports address_validation, tn_inquiry). To ensure the proper object reference is returned, the local implementation should narrow the reference to the appropriate type. 1 Some implementations of TCP/IP do not recognize the signed bit. TCIF-98-014 Issue 1 Page 14 09/16/1999

TCIF Guideline Object Reference Exchange Guidelines Object resolve (in Name n) raises (NotFound, CannotProceed, InvalidName) The resolve operation is invoked on a NamingContext interface. To simplify implementation, a hierarchical naming scheme is not utilized unless necessary. These initial implementations will maintain a single object reference to the root-naming context. The client may resolve names directly on this interface. 7.2 Naming Format The CORBA COS Naming Service supports names by a specific naming structure composed of two strings: ID and KIND. At present, the simplicity of the naming structure does not require the KIND field to be used. To conform to the naming service standard, this field should be set to NULL. The ID should be used to uniquely identify an object within a particular naming context. The ID string should take a value which is human readable and indicates the particular interface being queried (e.g., address_validation). 7.3 Asynchronous Response Object For asynchronous interfaces, the responder must be able to identify initiator side response objects. Rather than using names and the Naming Service, the responder can determine response objects by having the initiator pass object references in their requests. A response is always preceded by a request. 8 Object Reference Exchange Guidelines There are two points in a TMN X-interface where object references need to be resolved. These points occur during: Customer side system initialization Dynamic IOR Discovery These two points are discussed in this section. 8.1 Customer Side System Initialization When a new customer wishes to utilize a provider's CORBA gateway, the provider's objects supporting the gateway interface must be identified by static names (e.g., similar to X.500 names). These names and their related object references are maintained within a COS Naming Service Naming Context interface. This interface defines several standard operations. For this gateway interface, only the resolve operation is of importance (defined in Section 7.1). A method for exchange of IORs must be specified for the names of all objects for which the customers will invoke operations. Issue 1 TCIF-98-014 09/16/1999 Page 15

Object Reference Exchange Guidelines TCIF Guideline 8.2 Dynamic IOR Discovery While the name of an object will remain constant throughout the lifetime of an implementation, server side IORs may change. There are two instances where it may be necessary to dynamically discovery new IORs: Server shutdown Load Distribution This section identifies how a client learns that an object implementation no longer exists at its prior location, the impacts on the client side implementation and the impacts on the server side implementation. 8.2.1 Loss of Object Implementation After a server shutdown occurs, where an object implementation resides, that object implementation s IOR is no longer valid. A client invocation on that object implementation will result in a CORBA exception called OBJECT_NOT_EXIST This exception is defined by CORBA as ". an exception raised whenever an invocation on a deleted object was performed. It is an authoritative hard fault report. Anyone receiving it is allowed (even expected) to delete all copies of this object reference and to perform other appropriate final recovery style procedures." Upon reception of this exception, the client side implementation must take corrective action. 8.2.2 Client Side Impacts The Client Side is unaware of why an object implementation is no longer available (i.e., server shutdown, load distribution). Based on the unavailability of the object implementation, the client side will invoke the naming service to resolve the new IOR of the object. Depending on how quickly the provider updates the naming service with a new IOR (binding the new IOR to the object name), the client may inadvertently make a new request before the server has updated the object. To avoid having the client make requests before the server has updated the IOR, a JIA should indicate a minimum time before the client retries a resolve operation on the naming service after reception of an OBJECT_NOT_EXIST exception. Even if the minimum time expires prior to the client s retry on resolve, there is no guarantee the name service has been updated by the server side. In this case, the client may get into a loop with OBJECT_NOT_EXIST and retries on resolve. A JIA should state the maximum number of client retries before alternative means of recovery are attempted. TCIF-98-014 Issue 1 Page 16 09/16/1999

TCIF Guideline Object Reference Exchange Guidelines Note that, to ensure high availability of the name service, it may be beneficial to have redundant name servers. Both name servers IORs should be provided. This is an issue to be defined within the JIA. 8.2.3 Server Side Impacts When a provider server shutdown occurs, an implementation may utilize a replicated or migrated object to allow the object implementation to be highly available. The provider implementation may also try to reboot the server process. In the replicated object approach, the object s IOR will change. As soon as the object is instantiated or activated on a different host, the naming service should be updated with the new IOR. In the case where the provider implementation reboots a shutdown server, the object implementation (and therefore its IOR) may not be available for some finite period of time. To avoid having the client side making new requests on the lost object implementation prior to having the server rebooted, the JIA should set the client retries on the name server to nothing less than the minimum time to reboot the object implementation. When the server reboots, the objects IOR will be immediately updated on the name server. Another issue that needs to be addressed is the issue of persistent vs. transient object references. 8.2.4 Persistent IORs An object reference is persistent if its IOR continues to be valid even if the server is stopped and restarted. Transient object references have a different IOR whenever their server is stopped and restarted or created. With persistent object references, a client can store an IOR and use it for later invocations. With persistent IORs, the client side will actually invoke operations on the same IOR as it used prior to the OBJECT_NOT_EXIST. This does not preclude the client implementation from resolving the new IOR from the name server. To ensure common behavior as a result of OBJECT_NOT_EXIST exceptions, the client should always invoke the name server. All server gateway object references should be persistent. This would allow clients to use the same IORs even if the servers are restarted. Transient object references can be used for the asynchronous callback objects since the IOR can be passed in each initial invocation. Issue 1 TCIF-98-014 09/16/1999 Page 17

Performance Considerations TCIF Guideline 9 Performance Considerations 9.1 Load Balancing As the number of client invocations increases, the provider may wish to implement server-replication 2 capability for better performance and load balancing (i.e. the server addresses the load balancing problem through replication of objects). This is implementation specific and is company dependent. 9.2 Buffering Buffering of transactions at the application level is application and implementation specific. Buffering at the TCP/IP level is addressed in Section 9.3. 9.3 Timeouts A client can timeout waiting on a response from the server. This timeout value should be established in the JIA. The timeout can occur either in the client gateway or it s OSS. In either case, the client is responsible for re-sending the request whenever it can. When the server receives the resent request, it can: 1. Process the same request again or 2. Throw an exception: AccessDenied with an error code indicating duplicated request (see Section 10.1.4). 9.3.1 Client Gateway Timeouts There are various reasons why the client gateway could timeout waiting on response (CORBA::NO_RESPONSE): Server OSS is slow to process the request Server OSS is not available Undetected loss of physical connection Server gateway has problem after the message has received (asynchronous interface) The client gateway will need to invoke the method again and increase the timeout interval at each retry. Increasing the timeout interval allows a slow server to have more time to process the request. Other timeout values should be considered when setting this timeout value. 2 For instance, IONA Naming Service extends the CORBA Naming model to allow a name to map to an object group. An object group is a collection of replicated objects that can increase or decrease in size dynamically. TCIF-98-014 Issue 1 Page 18 09/16/1999

TCIF Guideline Error Guidelines If the gateway encounters N (configurable) number of errors in sequence, it must log the appropriate error messages and try a backup server if applicable. This is to prevent an infinite loop while attempting to deliver a message that cannot be delivered. 9.3.2 Client OSS Timeouts This document does not address the communications and error handling between the OSS and its gateway. 9.4 Thread Pooling Some ORB implementations allow an implementation to either create a new thread for each request or use an existing thread from a thread-pool. The decision to use one method over the other is a design decision that is a performance/resource usage trade off. Using a thread pool can improve the performance of an implementation since a new thread does not have to be created for each request. On the other hand, using a threadpool may require that the implementation handle the case where all threads in the pool are exhausted (although some ORBs handle this by simply adding new threads to the pool). 10 Error Guidelines 10.1 Operational Errors For both the synchronous and asynchronous methods of operation, errors can occur in 5 general areas customer OSS, customer gateway, customer/provider connection, provider gateway and provider OSS. Error types can be divided into two main areas - application and system. These can then be subdivided into bind errors, invocation errors and response errors. In both the synchronous and asynchronous modes, timeout situations can lead to infinite loops. Recovery from this situation is dependent on the approach as described in Section 9.3.1. Issue 1 TCIF-98-014 09/16/1999 Page 19

Error Guidelines TCIF Guideline Customer OSS Customer Gateway Provider Gateway Provider OSS A B C D E Figure 10-1 Error Scenarios 10.1.1 Customer OSS Errors (A) Invocations Not addressed in this document. Responses If the OSS is unavailable, the customer gateway should accept and store as many responses as possible until it becomes available. This is company dependent. Customer OSS application error handling is not addressed in this document since the provider will be unaware of the customer OSS errors. 10.1.2 Customer Gateway Errors (B) Invocations No invocations will be made. Responses In the synchronous mode, if the customer gateway is unavailable, the provider gateway may not know that the customer did not receive the reply. The customer may time out (CORBA::NO_RESPONSE) waiting on the response. It will then need to invoke the method again whenever it can. This can lead to the provider processing the same request more than once. In the asynchronous mode, if the provider gateway receives an error when sending a response it should not try to resend it. The customer will timeout waiting on the response. If the customer gateway encounters application level errors with the response data, it will need to record the error since there is no way to notify the provider. This document will not address these types of errors. 10.1.3 Customer/Provider Connection Errors (C) Binds The customer would be unable to bind to the provider object. Similarly, in the asynchronous mode the provider will be unable to bind to the customer. Recovery from this error is implementation specific. Invocations The customer would receive a CORBA system exception (CORBA::NO_IMPLEMENT) and would be unable to invoke any method. The customer will need to queue the invocations as described in the Timeouts section (Section 9.3). Responses Both the synchronous and asynchronous modes are similar to the Customer Gateway Errors scenario (Section 10.1.2), the provider gateway may not know that the customer did not receive the reply. The customer may time out waiting on TCIF-98-014 Issue 1 Page 20 09/16/1999

TCIF Guideline Error Guidelines the response. It will then need to invoke the method again whenever it can. This can lead to the provider processing the same request more than once. 10.1.4 Provider Gateway Errors (D) Binds The customer would be unable to bind to the provider object. Invocations If the provider gateway is unavailable or unable to respond the customer would receive a CORBA system exception. The customer could then try an alternative server or retry at regular intervals. If the provider encounters system level errors, it should raise a CORBA system exception (see the CORBA standard). Application level errors that are not application specific should raise a standard CORBA user exception. Some standard CORBA user exceptions have been defined in the Base module of the draft T1.256 Annex C standard. The exceptions defined in that document are: MissingData Data that is optional in the IDL but mandatory in the JIA is missing. Contains the list of missing IDL field names. InvalidData One or more data element is invalid. Contains the list of invalid IDL field names and the reason why they are invalid. ProcessingFailureError A general processing failure error occurred. Contains a standard code and an optional description of the problem that occurred. AccesDenied The caller did not have access to the requested resource. Contains an optional description of the problem. NotFound The requested resource was not found. Contains an optional description of the problem. Application errors that are application specific should throw CORBA user exceptions defined in the application information model. Responses If the provider encounters errors while formulating the response, it should raise a CORBA exception. This can be a system exception, a standard user exception or a ProcessingFailureError exception with the appropriate code (Section 10.2). If the provider is unable to raise an exception, the customer may time out (CORBA::NO_RESPONSE) waiting on the response. It will then need to invoke the method again. In the asynchronous mode, the application s IDL model needs to support the communication of an error condition. 10.1.5 Provider OSS Errors (E) Invocations If the provider OSS is unavailable, the provider gateway should store the invocation data for a period of time or until the OSS can accept the data. This behavior is application specific depending on the time criticality of the application. Issue 1 TCIF-98-014 09/16/1999 Page 21

Error Guidelines TCIF Guideline In the synchronous mode, after a time out interval, the provider should raise a ProcessingFailureError exception with the appropriate code (see Section10.2). Based on the code contained in the exception, the customer could throttle its invocations until it receives a completed invocation. In the asynchronous mode, after a time out interval, the provider should send an error message to the customer. Responses If the provider s OSS is unavailable, the provider gateway should time out waiting on the response from the OSS and raise a ProcessingFailureError exception with the appropriate code. If the OSS encounters application errors, it should notify the provider which in turn would raise a standard user exception or a ProcessingFailureError exception with the appropriate code. For both types of errors, the customer will need to invoke the method again. In the asynchronous mode, after a time out interval, the provider should send an error message to the customer. 10.2 Standardizing Exceptions and Error Codes The standard exception ProcessingFailureError defined in the Base module of T1.256 contains an error code and an optional description. The error code is in the format AAA-NNNN where AAA is a three-letter code representing the type of error and NNNN is a four-digit error number. Each error code corresponds to a condition described in Table 10.1. The description field in the exception could contain specific error information defined in the JIA. The following codes should be used for generic processing failure errors (this list can be expanded in the future): Table 10.1 Standard Error Codes ERROR CODE SYS-0001 SYS-0002 CONDITION An OSS unavailable Processing delayed. This is applicable only for the asynchronous mode of operation. Application specific processing failure error codes should use a unique letter code e.g. Access inquiry would use EAO. These codes need to be defined by each application. These error codes are also to be used in other exceptions and error fields where additional information can be sent. In these cases, since there is only one field, the following format should be used: AAA-NNNN:xxxxxxxxxx where xxxxxxxxxx is the optional description text. TCIF-98-014 Issue 1 Page 22 09/16/1999

TCIF Guideline References 10.3 Interoperability Concerns Trading partners should should perform extensive interoperability testing especially between ORBs of different vendors or between ORBs of different versions. For example, initialization errors on unions have been noted that may lead to abnormal termination conditions. These kind of situations should be addressed in pair-wise JIAs. 11 References 11.1 Acronyms ANSI American National Standards Institute API Application Programmers Interface ATIS Alliance for Telecommunications Industry Solutions CA Certification Authority CBC Cipher Block Chaining CORBA Common Object Request Broker Architecture COS Common Object Services (CORBAservices) DES Digital Encryption Standard ECIC Electronic Communications Implementation Committee (a committee of TCIF) GIG Generic Implementation Guidelines GIOP General Inter-ORB Protocol IDL Interface Definition Language IETF Internet Engineering Task Force IIOP Internet Inter-ORB Protocol IOR Interoperable Object Reference IP Internet Protocol JIA Joint Implementation Agreement/Arrangement MD Message Digest OMG Object Management Group ORB Object Request Broker RSA Rivest Shamir Adelman SHA Secure Hash Algorithm SSL3 Secure Socket Layer version 3 TCIF Telecommunications Industry Forum (a committee of ATIS) TCP Transmission Connection Protocol TLS Transport Layer Security TMN Telecommunications Management Network 11.2 Documents formal/98-07-01 CORBA/IIOP 2.2 Specification orbos/97-02-04 CORBA Security/Secure Socket Layer Interoperability T1M1.5/1998-024 T1M1.5 Technical Report IDL Design Guidelines TCIF-99-008 - Telecom Non-Repudiation Inter-ORB Protocol (TeNoRIOP) TCIF-98-011 - Lower Layer Protocol Specifications for Electronic Communications Over TCP/IP Issue 1 TCIF-98-014 09/16/1999 Page 23

References TCIF Guideline TCIF-98-014 Issue 1 Page 24 09/16/1999