Installation FAQ

1. What are the system requirements for PlatformX?
2. What third party software do I have to purchase to use PlatformX?
3. Do I need a separate JNDI server, even if my JMS vendor provides it?
4. Do I need federated JMS servers?

Configuration FAQ

1. Do I need to specify a PlatformX XML configuration file for every process?
2. Is there a default PlatformX configuration file used by all PlatformX applications?
3. What are the minimum mandatory properties that I have to specify in the configuration file?
4. Can multiple PlatformX applications share configuration properties through a common configuration file?
5. How do I override the values for the default and system worker pools?
6. What is the relation between the destination attribute of the ptp_channel element and the name of the destination PlatformX application?
7. Do I have to specify the fault_tolerance properties for every PlatformX application?
8. Can I map multiple message classes to a single message handler class?

Programming and Development FAQ

1. Do I have to always initialize PlatformCore class?
2. What happens in PlatformCore initialization?
3. Does every message have to be mapped to a message handler?
4. Can a request be mapped to be processed by a message handler?
5. Can a message be mapped to be processed by a request handler?

Answers to the General FAQ

Q1. What is PlatformX?
A1. PlatformX is a Java package that provides a framework for developing distributed, multi-threaded, fault-tolerant applications. The framework provides APIs to send asynchronous as well as synchronous messages to other processes, provides mechanisms to simplify message-oriented programming like automatic correlation of request and response messages, provides multi-threaded execution contexts for parallel execution of message-processing business logic code and finally, it provides a base for development of fault tolerant applications that performs core functions like detecting process failures and switchovers.
[Back to Index]

Q2. How is PlatformX different from other IPC middleware like JMS and CORBA Notification service?
A2. PlatformX is primarily designed to facilitate asynchronous message-oriented programming while products based on technologies like EJB and CORBA are primarily tuned for synchronous method-oriented IPC. It is not uncommon for the implementations based on synchronous IPC to suffer resource and performance problems. For example, a client process may have many threads blocked on synchronous calls waiting for responses that could be delayed due to conditions such as a busy server, or communications problems. All operations in the PlatformX are executed asynchronously, thus maintaining high throughput even under such demanding conditions resulting in better thread resource management.
[Back to Index]

Q3. How is PlatformX different from EJB and CORBA application servers and middleware products?
A3. Though PlatformX messaging API is built on top of JMS, PlatformX is much more than just a messaging middleware. It provides extensive framework to handle the overwhelming details involved in using messages to code complex business logic and thus assist in developing a message-based application. It provides a framework for multi-threaded execution of business logic code as well efficient thread management services, and a base for development of other enterprise features such as fault tolerance.
[Back to Index]

Q4. What kind of users is PlatformX targeted for?
A4. The PlatformX is a development framework, intended to be used by application developers and programmers. The users are expected to be familiar with Java programming language and the basic concept of distributed programming.
[Back to Index]

Q5. What sort of applications can be developed with PlatformX?
A5. An application of any size that needs to communicate across processes is a candidate for PlatformX. The processes could be on the same machine or distributed across the network. Applications that require multi-threaded execution of code, ability to handle large number of requests or demand high availability and fault tolerant behaviors make a stronger case for PlatformX.
[Back to Index]

Q6. How is PlatformX licensed?
A6. PlatformX is free only for development use or for non-commercial use. You need to purchase a license from NEC, America to be able to use this product commercially. The source code is available for free on request.
[Back to Index]

Answers to the Installation FAQ

Q1. What are the system requirements for PlatformX?
A1. PlatformX can run on any system that has JDK 1.3 installed. PlatformX additionally requires a JMS compliant messaging middleware, a JNDI complaint directory server in some cases (see FAQ 3 below), the log4j package from Apache and JDOM Xml parser. PlatformX does not have any significant hardware requirements. The hardware requirement is more a function of the application being developed with PlatformX.
[Back to Index]

Q2. What third party software do I have to purchase to use PlatformX?
A2. Most of the third party software used by PlatformX is downloadable for free. PlatformX has been tested to work with various commercial and freeware JMS and JNDI products. So PlatformX can be used without having to purchase any other products.
[Back to Index]

Q3. Do I need a separate JNDI server, even if my JMS vendor provides it?
A3. Depends on the JNDI interface and capability of the JMS product. Some JMS vendors place restrictions on the type of objects that can be registered in their directory such as allowing only temporary topic objects to be registered. In such cases, a separate JNDI server maybe necessary to register the entry point object of an PlatformX application.
[Back to Index]

Q4. Do I need federated JMS servers?
A4. Depends on the application deployment architecture and the amount of reliability expected of the JMS server. If the JMS server is configured to run on a single host and host failure is not an issue, a simple JMS server will suffice. On the other hand, if the architecture entails multiple JMS servers distributed across geographic locations, multiple routes, load balancing, etc then federated JMS server may be an option.
[Back to Index]

Answers to the Configuration FAQ

Q1. Do I need to specify a PlatformX XML configuration file for every process?
A1. Yes. Every application process that intends to use PlatformX has to define some process specific configuration information for use by PlatformX.
[Back to Index]

Q2. Is there a default PlatformX configuration file used by all PlatformX applications?
A2. No. There is no default configuration file. All PlatformX application processes have to supply a configuration file while initializing PlatformX.
[Back to Index]

Q3. What are the minimum mandatory properties that I have to specify in the configuration file?
A3. The following minimal configuration information is required:

1. The name and homedir attributes of the platform element
2. The jndi_properties, topic_connection_factory and default_topic attributes of the jms_server element.
3. jndi_properties attribute of the gw_channels_registry element.

Answers to Programming and Development FAQ

Q1. Do I have to always initialize PlatformCore class?
A1. Yes. If an application process intends to use PlatformX framework, the PlatformCore initialization should be among the first tasks of the process. This needs to be done only once during the process lifetime.
[Back to Index]

Q2. What happens in PlatformCore initialization?
A2. The PlatformX performs the following initialization sequence:

1. Parse the Xml configuration file
2. Set up important variables and shutdown hook.
3. Create and initialize all worker pools.
4. Initialize all managers like pending request manager, message-map store, channel-list manager and fault-tolerance core.
5. Create and initialize channels specified in the configuration file.
6. Instantiate all message handlers and load the message maps specified in the configuration file.
7. Start the JMS connection and all the channels (with auto start).
8. Return the main thread back to the calling method.