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 only suited in the company where Tibco suites have been already used, the license cost is not a concern, it is only required for data caching purposes and only works in the client/server mode for middle-sizes of data. If the expectation is data cache + distributed computation or embedded IMDG is also one requirement or the data cluster needs span multiple data centers, other light-weight OpenSource IMDG solutions should be considered
TIBCO ActiveSpaces Tuple-based data structure is not flexible enough to support customized native data objects.
There is no secondary index option.
Doesn't provide "predicate based In-Grid distributed search and result aggregation."
only can be used as data cache, the node's only contribute memory but can not use the data partition owner node's computation power to apply the distributed computation customized by the user.
Cross data center replication (geographically) is a pain.
Encounter the performance issue when the data volume is huge, even according to the architecture design, linear scaling up should not have that issue.
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
Before using TIBCO ActiveSpaces, we were storing all the data in Oracle Database and due to large volumes of data response time was more and overall performance had reduced. With the introduction of TIBCO ActiveSpaces, we moved the master data to TIBCO ActiveSpaces for storing data which needed frequent access in memory for faster retrieval. This improved the performance significantly and also made managing data easier.
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.
