Message brokering across different systems, with transactionality and the ability to have fine tuned control over what happens using Java (or other languages), instead of a heavy, proprietary languages. One situation that it doesn't fit very well (as far as I have experienced) is when your workflow requires significant data mapping. While possible when using Java tooling, some other visual data mapping tools in other integration frameworks are easier to work with.
TIBCO ActiveSpaces is useful for storing in memory data which enables fetching data quickly and efficiently. We can make use of TIBCO ActiveSpaces APIs for storing and retrieving data. In our organization, we store user session details in TIBCO ActiveSpaces and this session detail is used for authentication and authorizing user. We have integration TIBCO ActiveSpaces with React UI and TIBCO Business Works.
Camel has an easy learning curve. It is fairly well documented and there are about 5-6 books on Camel.
There is a large user group and blogs devoted to all things Camel and the developers of Camel provide quick answers and have also been very quick to patch Camel, when bugs are reported.
Camel integrates well with well known frameworks like Spring, and other middleware products like Apache Karaf and Servicemix.
There are over 150 components for the Camel framework that help integrate with diverse software platforms.
Like all other IMDG solutions, Tibco ActiveSpaces provides a scalable and distributed cache solution, which is supposed to have high throughput and high availability.
As it is under the Tibco umbrella, it is seamlessly integrated with other Tibco products.
It breaks the traditional "local cache" boundary and limitation, instead unifies many "local physical memory" to create one huge "In-Memory Data Grid", and serves the data provider/consumer application logically as one "Memory Cloud."
A lot of non-frequently updated data can be cached in this IMDG, to allow fast access, which saves the I/O latency caused by many traditional file system-backed storage solutions.
ActiveSpaces 3.2 is not compatible with the latest version of TIBCO Business Event 5.x. And ActiveSpaces 2.x is not compatible with ActiveSpaces 3.x hence there is a big difference in the BusinessEvents supported version of AS and the latest.
ActiveSpaces takes more disc space and TIBCO does not offer data compression logic out of the box. Developers need to do extra coding to use java snippets to compress and decompress the payload. Although the data compression gives must better performance and speed to the system.
The compression and decompression API are not offered by TIBCO out of the box, which is a shame. These are so easy and simple to implement, still TIBCOdoes not provide them as an option out of the box.
TIBCO ActiveSpaces is easy to install and integrate with other product suites. It is easy to understand and implement as well. TIBCO ActiveSpaces supports multiple databases for storing the data(we are using Oracle Database). All the master data related to the users is being stored using TIBCO ActiveSpaces which keeps the data in memory and help to retrieve it quickly. It has helped to prevent concurrent login sessions by the same user as session details are stored in TIBCO ActiveSpaces and we override the existing user session with the new session details.
If you are looking for a Java-based open source low cost equivalent to webMethods or Azure Logic Apps, Apache Camel is an excellent choice as it is mature and widely deployed, and included in many vendored Java application servers too such as Redhat JBoss EAP. Apache Camel is lacking on the GUI tooling side compared to commercial products such as webMethods or Azure Logic Apps.
Actually, we are gradually replacing the Tibco ActiveSpaces with Redis (for caching purpose only) or Hazelcast (for embedded mode and also for in-memory distributed computation purpose + in-memory distributed IPC purpose).
Very fast time to market in that so many components are available to use immediately.
Error handling mechanisms and patterns of practice are robust and easy to use which in turn has made our application more robust from the start, so fewer bugs.
However, testing and debugging routes is more challenging than working is standard Java so that takes more time (less time than writing the components from scratch).
Most people don't know Camel coming in and many junior developers find it overwhelming and are not enthusiastic to learn it. So finding people that want to develop/maintain it is a challenge.
Developers with basic knowledge of TIBCO and general data knowledge can easily design and develop an ActiveSpaces based cached solution. As the ActiveSpaces concepts are very simple and easy to understand.
Some business areas can predict the high influx of a service usage during a certain period. Business will be highly rewarded if they can identify these business areas and provide a cached solution using TIBCO AS.
Again, this is not a TIBCO ActiveSpaces only advantage and this is true for any/all caching products.
Some examples for the previous points are
a. telecom company pre-loading (eager load) customer's usage for the last month, right before releasing/issuing the bills to the customers.
b. Airline industry loading the customer's itinerary a week before his travel start date. Hence the last minute scrambling to fetch the customer's itinerary travel plans can be avoided.
