Posted on
November 9th, 2010
The Issue
Now-a-days every library that you use is Annotations based. Annotations offer a better readable approach over the traditional XML approach. But there is a problem while using annotations, you can not force a class to have some annotations in place. You can say it with XMLs by creating some abstractions but you can not force the same with annotations, it is up to the developer to use the required annotations. This problem orignates from the way annotations are implemented in JDK.
Annotations are basically class/method specific. With Annotations you can at best say that if some class implements some base-class then it can have some annotation that was used in base-class( using the @inherited meta-annotation)
Read more »
Posted on
August 13th, 2010
Often we have the requirement of reading different types of files e.g. CSV, PDF, XLS files and there can be many more types need to be read in an application.
One way, we try to implement such a requirement is by using separate readers for all of them and may use different frameworks for analyzing each of them e.g. if our application requires PDF, XML and XLS file parsing, we can create a FileReader interface. Then we can have different implementations of this interface for each of the types and use PDFBox for reading PDF files, Apache POI for XLS files and SAX for XML files. Read more »
Posted on
March 25th, 2010
Recently one of our clients asked to make a distributed application that can be scaled and managed easily and cost effectively. So we evaluated JavaSpaces, a Space Based Architecture concept, and one of its commercial implementation GigaSpaces for the purpose. In this post I will try to describe in brief what the Space based Architecture approach is all about.
Space Based Architecture(SBA) is a paradigm of co-located tiers. It combines the elements of SOA, event driven architecture and grid computing. In SBA we would create tiers but would co-locate them with the messaging and data in-memory, at one single box. Now there are no network hop-overs as the data required is available in memory rather on an ESB or Database, hence there is minimum latency and thus maximum throughput. The whole box will now be called a PROCESSING UNIT, that will have an in memory bus known as the SPACE. For fail-over strategy we would eventually create backups of this Processing Unit, with their own space having synchronous replication with primary space.
In order to create a highly scalable application we would like to employ the concept of PARTITIONING of space rather clustering. In partitioning we would have one single view of a space that is eventually distributed across different processing units( it utilizes the shared dynamic memory of networked JVMs). When ever some object is written to the space it will determine its location first and then will be routed to that Space partition. This eventually calls for the concept of DATA-AFFINITY. It says that you should keep all the data that is attached to your primary object should be available in one single partitioned space. This would enable you not to query over other spaces and thus reduce the network calls.
Now for scalable,high throughput applications we create SLAs using partitioning that would instantiate new partitions or destroy old ones depending on the current load i.e. Scale-on-Demand. These SLAs are deployed along-with the application in an SLA-Driven container.
Applications also require persistent storage, since applications in SBA have in memory data grid(the SPACE) so they must persist data to DB. But DB writes are quite slow, so we would not like to interact with DB directly, here we have another new entity called MIRROR SERVICE. Mirror service is usually a single space connected to an external storage(Files,DB etc). Your application space would write the data asynchronously to the Mirror, which would eventually persist the data. In SBA you do not read much data from persistent storage as most of the time data is available in the in memory grid, but at times there can be some data that is required to be read from the DB. In such cases a read-at-start-up strategy is employed where the space will load the entire data from the DB at start-up and will keep it in its in-memory grid.
Here are some of the implications of using SBA:
- Scalability becomes predictable and linear
- Offers quite low latency thus a high throughput
- Lower Total Cost of Ownership
- Developers write code as if it was for a single server so eliminate efforts required to integrate tiers
- Simplistic API(read/write/take/update) with POJO based model
- Developers need to take consideration of Partitioning their data.
- Data in th DB that is being modified by some other application can not detected by the space application and thus can not be loaded.
- SLAs are often written in XML files with the application code(system administrators may not like that)
