It fits perfectly for SOA and EAI architecture with large numbers of services that required to be wired to each other, the binding virtualization is quite good to simply this part. For the simple scenario of orchestration and /or ESB architecture could be a better use traditional stack.
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.
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.
TIBCO service grid has been chosen as a natural selection of the TIBCO product evolution. The high flexibility and the binding virtualization fits very well with client needs for its EAI applications due to the huge number of services and applications, the management of application dependencies during deployment, the advantage of perfect integration with EMS for logging
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).
The integration of old BW with BWSE and its interface quite similar to design time has reduced the cost of training for developers
The TIBCO support for this product is no the best and clients complains too much about this. This required to find a workaround or force the client to move to new/or different product. Huge impact on ROI
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.
