-FAQ

 

General Questions

What is iBus™?

iBus™ is an industrial-strength publish/subscribe and point-to-point enterprise middleware written entirely in Java. It is fully compliant to the Java Message Service (JMS) standard (see http://java.sun.com/products /jms/). It allows application developers to quickly build robust, scalable distributed applications that can share data atop of any transport protocol, such as reliable IP multicast, TCP, HTTP, SSL or various wireless media. The iBus™ is available in either a serverless or server version depending on your specific needs.

Why should I use iBus™?

Application developers will benefit from:

• Greatly reduced development time and cost
• Reduced complexity in their projects
• Being able to focus on the application logic, instead of on the communication infrastructure
• Being able to work on a system in operation: upgrading, adding and fixing components at runtime
• Exchange messages between heterogeneous platforms

System managers will benefit from:

• Greatly reduced downtime during maintenance phases
• Reduced network load through efficient use of IP multicast
• Low latency, high throughput message distribution
• No downtime while adding, upgrading or fixing components and processes in their distributed system
• Huge savings in time through using iBus™

How much does it cost?

Current pricing information is available from
info@softwired-inc.com

Is a trial version available?

There are free-of-charge LE (Light Edition) versions of both iBus//MessageServer and iBus//Mobile available for download from this site. Both allow you to develop fully-functional applications with no time restrictions. The only limitations built into these free products are in the number of concurrent connections supported by each.

Is training available?

Yes. Training is available through partner companies. Please send an e-mail to
info@softwired-inc.com for more information.

What kind of applications can I develop using iBus™?

The Softwired iBus™ product line is used to build highly scalable, fault-tolerant distributed applications.

iBus//MessageBus™is the ONLY fully distributed, serverless JMS product available on the market. It is uniquely designed for local applications requiring a zero downtime, zero administration operation with the highest possible message delivery rate and group coordination features. Examples include fault-tolerant Web portals, distributed application servers or in-house business logic with a fault-tolerant design.

iBus//MessageServer™ is our server-centric iBus™ product with guaranteed message delivery. It is designed for applications requiring a highly scalable Java Message Service (JMS), working over various transport protocols, or require a highly customizable Quality of Service (QoS). Examples include Enterprise Application Integration (EAI) projects, Customer Relationship Management (CRM) systems, Workflow Applications or Enterprise Information Portals (EIP).

iBus//Mobile™ is industry's only 100% Wireless JMS solution. It provides a versatile gateway between mobile devices and Java applications running in the J2EE environment. iBus//Mobile runs on various platforms (Palm, Android, Symbian, Windows CE, Windows Mobile, Windows 98 | ME | NT | 2000 | XP | Server 2003 | Vista | Server 2008, Linux, Solaris, etc.) and also supports various communication bearers (SMS, WAP, GRPS, UMTS, TCP, HTTP, e-mail, etc.). It is designed for connecting a variety of mobile devices, programmable as well as non-programmable, to server-side Java applications. The server applications can be either standalone Java applications or Enterprise Java Beans (EJB) components running under the control of an application server. iBus//Mobile is a pure software solution based on the Java Message Service (JMS) and on the XML standards. The standards-based approach adopted by iBus//Mobile ensures that the development and implementation of wireless solutions is simplified and accelerated.

Click here for the iBus//Mobile FAQ

Back to top

Is iBus™ easy to use?

Yes, the messaging paradigm is very easy to understand and use by application developers. In fact, most application developers have their first iBus application running within an hour. The iBus™ is specifically designed to shield the application developer from any network specifics, such as error recovery, non-delivery failures, temporary network downtime and so on.

Is iBus™ easy to install?

Yes, the iBus™ product line is installed through a user-friendly install shield, on any Unix, Windows and Linux platforms.

Does iBus™ require any special hardware?

No, the iBus™ product line is written entirely in the Java language from Sun Microsystems. Thus, it runs on any hardware that features a Java Virtual Machine. Specifically, this includes Linux, Sun Solaris, other Unix flavors, Windows 9x, NT and 2000.

Concepts and Architecture

How does the iBus™ messaging model differ from the traditional client/server model?

The iBus™ product line features publish/subscribe and point-to-point (queue) messaging, as well as traditional request-reply client/server computing. An article explaining the key differences between messaging and traditional client/server models is available on: http://www.softwired-inc.com /pdf/technology/momdad-final.pdf.

What is publish/subscribe?

Publish/subscribe is a programming model where producers and consumers of messages agree on a common topic. Producers then broadcast messages anonymously to the topic, while the consumers, subscribed to the topic, receive the messages instantly.

What is point-to-point?

In the point-to-point programming model, a virtual queue is set up between producers and consumers. A producer publishes its message anonymously into the queue. At the other end of the queue, consumers remove the messages one after the other.

What is location transparency?

Distributed components can interoperate without knowledge of each other's physical location, network address, network protocol, socket number, name or any other location information. The only shared knowledge is the name of a topic or queue.

What is time transparency?

Distributed components can interoperate even if they are not online at the same time. Queues hold messages until they can be consumed; persistent topics hold a backlog of published messages for later retrieval.

Back to top

What is transport protocol transparency?

Distributed components can inter operate without knowledge of each others physical location, network address, network protocol, socket number, name or any other location information. The only shared knowledge is the name of a topic or queue.

What are self-describing messages?

Any message published can be analyzed and fully understood by any consumer due to the Java reflection mechanism. There is no need of an external format description server or any other means of format conventions.

Does iBus™ support true multicast?

Yes. The Softwired iBus™//MessageBus fully exploits IP Multicast. The reliable IP Multicast implementation is adaptable from comparatively small IP Multicast groups of e.g. 100 stock traders up to communities on virtual private networks with members in excess of several 10'000.

Does iBus™ support synchronous request/reply?

Yes. In compliance with the JMS standard, synchronous request/reply is supported. In addition, the iBus™ supports synchronous request/reply with multiple replies and selective time out values.

Is there a limit on message size?

No. Other than operating system and/or hardware limitations (such as available memory), there is no limitation on message size.

Does iBus provide failure detection and fault tolerance features?

Yes. The iBus//MessageBus features a group coordination API. Members (i.e. producers or consumers) on topics are detected and reported to user space. The list of members is ordered alphabetically. Members leaving (regardless of whether they leave controlled or due to a crash) are detected and reported as well. This feature allows to build powerful fault-tolerant distributed systems, such as distributed application server logic or web portals.

Is iBus™ extensible?

Yes. Unlike other middleware, the iBus features a "gray box" approach. While the top level API is fixed (i.e. the JMS API), the interface to the underlying transport protocol is extensible via a published "protocol composition framework". This allows the development of new Qualities of Service not available in any other middleware product. Examples include:

• Bandwidth management, such as limiting bandwidth to achieve a fair setup for all topic members.
• Support of one-way transport channels, such as a radio broadcast signal to cars.
• Support of asymmetrical transport channels, such as broadband, broadcast satellite downlink with a telephone-based point-to-point uplink for failure management.

Is iBus™ really "plug and play"?

Absolutely! The messaging paradigm allows "plug and play" software components. Since all communication between components is anonymous and mediated by the middleware, components can join and leave a running system at any time, without interrupting service of the full system. It is common practice in a messaging based distributed system to perform maintenance without stopping the system: A new, upgraded component is inserted in the environment, while later the old, outdated version is disconnected. Other participants never detect the change, thus an application developer can focus of the business logic, instead of on the management on network and component failures.

Back to top

Is XML supported?

Yes, iBus provides an XML message type. This allows you to send and receive XML expressions or DOM trees. For that purpose, any JAXP compatible XML parser can be used along with iBus. The sending or receiving application can ask iBus to validate the XML message against its DTD. XML support enables application developers to create widely distributed and losely coupled systems, as required by many e-commerce or m-commerce solutions.

Is there support for SSL?

Yes, SSL is bundled with iBus, and is available to customers in the US as well as in most other countries (contact us for a list). JMS applications can access SSL certificates to identify and authenticate their peer applications.

Are there access control lists?

iBus//MessageServer provides a very sophisticated access control mechanism to allow you to build robust and secure applications. Plugins can replace or enhance the default iBus//MessageServer access control facilities. Furthermore, plugins allow you to integrate iBus into existing user management and directory services.

Is there support for HTTP tunneling?

Yes, tunneling over HTTP is available and allows JMS applications running "behind firewalls" to connect to a JMS server. All JMS traffic is encapsulated into standard HTTP 1.0 requests to ensure best possible interoperability with firewalls and HTTP proxies. Full support for any HTTP proxy server is available as well. iBus//MessageServer can share port 80 with a web server, by forwarding regular HTTP requests to a web server running on another port or host.

What administration facilities are available?

For iBus//MessageServer a powerful graphical user interface is available which allows the configuration and monitoring of any number of servers. An administration API is also available to integrate management of iBus services into a larger application, or to administer a iBus//MessageServer installation programatically. The API offers full access to all configuration and management options of iBus//MessageServer.

Support

What kind of support is available?

Technical support questions are answered via an e-mail alias. To submit problem reports, please use http://www.softwired-inc.com/products/support.html. If you require but have not yet purchased developer support, please contact info@softwired-inc.com for pricing details.

 

Back to top

How is licensing handled?

Technically, licensing is managed by adding a license file to the Java classpath (e.g. by adding it to the iBus™ jar file). While the license file contains the number of purchased licenses, this number is currently not enforced.

For pricing and licensing information, please contact
info@softwired-inc.com

Which platforms are supported?

Formally tested platforms are:

• Linux on Intel Platforms
• Windows 9x, NT and 2000
• Sun Solaris (Sparc)

The Softwired iBus™ client library requires a Java Virtual Machine 1.1.6 or newer. Java 2 is fully supported but only required for iBus//MessageServer server components. Customers use iBus on AIX, AS/400, HP UX or IRIX, and there are no known problems with any platform.

Are performance numbers available?

We don't publish performance figures for several reasons:

• Performance is dependent on your exact hardware.
• Performance is dependent on the version of the Java Virtual Machine.
• Performance is dependent on the skilled use of IP Multicast.

Especially the iBus//MessageBus has outstanding performance characteristics (compared to other advertised claims of 'performance') if you use publish/subscribe to a large number of consumers, for which iBus//MessageBus is simply unbeatable. No matter how many subscribers receive messages, the message is transmitted not more than 1.0 to 1.2 times over the network. There is very little overhead imposed by iBus, except to provide reliability on top of the unreliable raw IP Multicast network protocol.

Java Development

How are typical iBus™ applications structured?

A typical iBus™ application uses one of the asynchronous communication models (publish/subscriber or point-to-point). The distributed application is driven by the producer(s) generating messages, very much like modern graphical user interface based local applications. An older legacy code that is being retro-fitted into a more decoupled environment may benefit from using the blocking, synchronous interaction model provided by iBus™ as well.

Is a tutorial available?

Yes, the iBus™ programmer's manual contains a comprehensive tutorial which covers all of the major JMS usages (publish/subscribe, point-to-point and synchronous request/reply).

 

Back to top

Can I get an application-level guarantee that a message has been delivered?

Transactional messages to a persistent topic or to a queue will be delivered: The iBus™//MessageServer guarantees this! What does not make sense in a messaging environment is a "return-receipt" equivalent of e-mail systems. After all, communication in a messaging environment is anonymous, time-independent and often addressed to an unknown number of recipients. If a message is acknowledged by the consumer (on the application level), this acknowledgement is used by the message server to guarantee an "exactly once" delivery guarantee, i.e. even after a failure of the consumer and a later reconnection, acknowledged messages will not be transmitted again.

Can I use iBus™ in multi-threaded applications?

Yes, if carefully done: The JMS standard does not require that the JMS implementation classes are thread-safe. Thus, multi threaded applications must ensure to use as many Sessions, Publishers etc. as required to guarantee that only one thread uses a particular component. Even if most of the iBus JMS implementations are thread-safe, utilizing this feature results in non-portable code.

What can I do to speed up a pub/sub topic?

Please consult the iBus™ Programmer's Manual, chapter "iBus™ Performance Tuning".

How does iBus™ deal with firewalls?

iBus//MessageServer transcends firewalls by using the HTTP protocol to communicate.

Can iBus™ talk to CORBA objects?

Yes. In fact, it is not "iBus" that does need to talk to CORBA objects, it is your application (client or server side) that may need to access CORBA objects. This is accomplished by using any Java CORBA ORB, such as JavaIDL from JDK 1.2 or higher.

Technical Issues

Why am I getting a class not found error?

Most probably your CLASSPATH is not set correctly for iBus™. Make sure you follow the installation instructions carefully. Entering javap javax.jms.Message should dump the interface of the JMS Message class. If you are getting an error message instead, then you haven't set up your CLASSPATH correctly.

Why am I getting an error about a corrupted license file?

Most probably the license file was modified while you saved it to a file. If the license file was sent to you by e-mail, use "Shift-Click" or "Save As" to copy the attachment to a file. Do not try to load the license file into an editor as this might corrupt it.

Why am I getting an error saying "the license cannot be found"?

Either your CLASSPATH is not set correctly or you did not install any license file. Make sure you follow the installation instructions carefully.

iBus//MessageBus: Why am I'm getting a joinSocket: joinGroup: exception?

Under the Windows operating system, you either need a network card installed or to establish a dial up TCP connection. Otherwise Windows will not load the TCP/IP stack. If you are getting this error message, the TCP/IP stack is not present or misconfigured.

iBus//MessageBus: The demo applications don't work, no messages are received.

If you are using Windows NT Service Pack 6, you should upgrade to Service Pack 6A. Service Pack 6 has severe bugs in the TCP/IP library, preventing iBus™ and other applications from functioning correctly.

Why is the deliverymode for temporary topics NON_PERSISTENT?

The JMS specification says about temporary topics that "it does not make sense to create a durable subscription to a temporary topic". PERSISTENT messages again are only used by durable subscribers. That's why temporary topics only allow NON_PERSISTENT messages to be sent.

My MessageServer, Admin Console or Topic got stalled. What could be the reason?

There are different reasons for symptoms like these, though they do have a common source: There is mostly a TopicSubscriber in the system which does not (or not fast enough) process messages. This will block the distribution process on the Topic and therefore look like a blocking of the MessageServer.
Popular reasons for this include:
* deadlock in the application code
* 100% CPU load on the client maschine (mostly a problem under Windows
only)
* processing of message takes a long time
* network problems (either real connection loss - i.e. modem/ISP problems - or other IP related problems - e.g. DHCP problems)
How can I solve these problems? First the real source of the problem needs to be found. To help finding it, version 4.5 of the MessageServer is equiped with Connection Loss Detection, a feature based on heartbeats which allows the server to detect such situations and cleanly remove the affected client (after which the server continues normal processing). Furthermore, version 4.5 is equiped with Slow Subscriber Detection, a feature which detects TopicSubscribers that prevent normal processing on a Topic by consuming too slow.
Both features should help you finding and solving the problem.

Can I improve the safety of the embedded database?

Yes, the server can be configured to take additional safety measures in the embedded database which greatly increases its reliability. Adjust the configuration parameter "explicitSync" in all Store-Subsystems (PersQueueFileStore, TopicFileStore and IDFileStore). You can do this change via the Administration Console.

Back to top