There have been talks about how CXO’s from American companies see India producing a la Google or Microsoft. The huge IT capabilities lead them to believe that a world class product company is just around the corner. But, in my opinion, a product company in the league of Google/Microsoft/Apple is a long way to go and my reasons for the same

Lack of Local Market – the biggest problem is lack of big enough local market in India. Any product company cannot become big unless they have a large enough local market to prove and refine themselves. Look at Google, Microsoft, Facebook, Twitter and one big reason for their early success is the large enough local market for them to grab. They ventured out of US only after they have established themselves in their local market. In India, barring a few domains like online gaming, no other domain provides a big enough market for any product company.

SOA has become an important middleware component for any Enterprise application. All enterprise applications need to connect variety of systems and SOA has become the ubiquitous middle ware glue.

It is in this context, I am reviewing the book “Application Development for IBM WebSphere Process Server 7 and Enterprise Service Bus 7”. I was requested to review the book by the publishers-Packt Publishing but the review is all mine.

My first impression when I looked at the contents table was, the book seemed to be covering the topics all the relevant topic’s. The use of a fictitious web application JungleSea is a nice way to explaining all the concepts. The book is meant to be read from Developer to Architect. The initial sections are all about SOA, ESB and WS concepts and the coverage is more from a revision perspective. So, for a complete newbie to the subject, it will not be very helpful.

The installation of WID and writing your first HelloProcess is covered in details. It would have been useful, to point additional comprehensive resources from IBM red book sites.
The word of wisdom section at the end of each chapter is very useful. It is very handy at times, when you are struggling to debug the problem.

The book covers the orchestration and mediation of Business Processes and Service Objects very well. But it does not dwell into some of the fundamental design philosophies when creating Service Objects or Business Processes.

Overall, the book is for all who are using or planning to use IBM WPS 7 and ESB products. If you are looking for knowledge on the SOA/ESB concepts, the book is not very helpful.
In recent times, most of the Tier 1 companies in the Indian IT industry have creating verticals (based on domain) and horizontals (based on technology). The whole idea of vertical is create enough domain expertise to service the clients and move up the value chain. The idea behind horizontals was to create specialized groups based on technology (J2EE, .Net, Security etc), function (e.g. Testing, Database etc) or even Software Provider (e.g. IBM, Oracle etc) and these professionals can be staffed to any domain project where the software, function or technology is being used.

Companies hire in big numbers from campus and then send this army of engineers to learn the techniques of warfare (namely – Java, .Net or even COBOL). Once the army is trained, the engineers are staffed to various technology horizontals.

Now, assume an engineer gets staffed to the Testing horizontal, S/He is put in as Test engineer in a project. They start working on test scripts or manual testing of the application. Question is, do these engineers mature enough to understand the importance of their role? Meaning, if I am testing web services, do I understand their usage, what role they play in overall application? What is the relationship between web services etc?

One view point can be, well they need to do one thing and they are supposed to be specialist in the same. Do they have the bigger picture in mind? Are they laying bricks or building a Cathedral?

My question, can a software professional be a complete professional if S/He has not gone the rigors or experiences of all the SDLC phases. Can you appreciate the value of testing, if you have not done coding yourself? Or can you appreciate the value of design, if you have not gone through the refactoring of an application? Will you not be a better developer if you have done testing yourself?

  • How can we build architects, if the person has not been exposed to the software lifecycle?
  • Can these individual architects perform, if they are pulled them out of the system and asked to architect an application with 4-5 freshers?
  • Can these Architect(s) guide the team for various roles (Build & Release, DBA, Requirement Gathering, Design, Testing, Deployment, Tuning, Environment Setup etc) if S/He himself has not gone through the rigors of the same?

I believe, for any software professional, it should be mandatory to work on all phases of SDLC and perform various roles before S/he should start looking at specialization. The person should perform the role every role twice. First time is to learn the requirements of role and second time to apply the learning’s.

The current trend of training people and putting them in a narrow role will leave the individual without adequate skills to perform the architect role. This cycle will soon skill the Software Profession.
How many times when we run the application under load, it becomes so difficult to figure out where the performance bottlenecks are?

Developers add lines of debugging code to measure the performance to pin point the problem. But you have no freaking clue where the bottleneck is.

One of the non-intrusive way of measuring and profiling code has been the use of Aspects. I had talked about aspects in my earlier post The wonderful world of Aspects.

Last month, Spring announced the release of Spring Insight 1.0.0.M3

Spring Insight has been developed as a lean framework that allows developers to deploy the module to their existing native application to an Spring Insight-enabled tc Server instance and immediately start seeing diagnostics. There is no requirement of additional DB to be setup or need to write any additional code.

Spring Insight captures application events known as traces. A trace represents a thread of execution. It is usually started by an HTTP request but can also be started by a background job. A trace contains operations. Each operation represents a significant point in the execution of the trace, for example, a JDBC query or transaction commit. Using this data, Spring Insight calculates summary information to lead you to the specifics of why your application is not performing.

Spring Insight uses AspectJ, which is based on bytecode weaving, dynamically instruments the applications at runtime. The current version of Spring Insight currently keeps its data in memory. It does not use an external database or write any data to disk. This means, any server restart wipes the slate clean. The Spring Insight uses sophisticated algorithms tries to keep the memory footprint low but still expects more memory (-Xmx) than a standard server.

The reporting is integrated with the Google Speed Tracer. Speed Tracer is available as a Chrome extension. Speed Tracer provides developers a full view into all the work performed in a web request – from CSS styling and view rendering to JDBC queries and JSP render times. Check out the Speed Tracer tutorial here

If you are developing using Spring libraries, then you can not afford to give a miss to Spring Insight
The recent new technological changes have brought about a sea change how we go ahead designing applications. Some of the technologies that i believe will have a pro-found effect on how we design and create our applications are

  • OSGi - The OSGi framework is a module system and service platform for the Java programming language that implements a complete and dynamic component model, something that does not exist in standalone Java/VM environments. Applications or components (coming in the form of bundles for deployment) can be remotely installed, started, stopped, updated and uninstalled without requiring a reboot; management of Java packages/classes is specified in great detail. Life cycle management is done via APIs which allow for remote downloading of management policies. The service registry allows bundles to detect the addition of new services, or the removal of services, and adapt accordingly. - Wikipedia. Designing new applications as OSGi bundles will require a different design mindset. Adding new features to enterprise applications will become easy. Maintenance and support cost will come down drastically. 
  • Distributed data systems - Technologies that allow us to scale and distribute our data have become stable and are being used in large applications. Handling petabytes of data have become a norm and social networking sites are doing it on a regular basis. Some of the open source technologies in the space like Hadoop, Cassandra, HBase Hive are mainstream and are all ready for use by the enterprises. 
  • Cloud Computing - Infrastructure as a platform has come into its own. Amazon EC2, RackSpace, GoGrid and others have become mainstream. Hundreds of companies are running their business on the cloud today. All of the them have launched or in the process of launching private clouds initiatives for the enterprises. Ability to connect from cloud to the enterprise data servers will mean, enterprise need not maintain costly data centers for their applications.

    Second part of the cloud is the emergence of SaaS enabled applications to connect with. Enterprise applications do not create functionality or download/deploy boxes for application features. Functionality like CRM (, Analytics (Google Analytics, Omniture, Unica etc), Payment Gateways (PayPal), Authentication (Open ID, integration with facebook, twitter etc), Web 2.0 tools (like blogs, discussion forums, online chat, bookmarking etc), Database (Amazon RDS), Source Control, Defect tracking and score of others on cloud, will mean application design will be an integration with multiple SaaS vendors with easy to use and published API's (most likely as RESTful web services)

    Do let me know, what do you think? Share your thoughts on what else you see will change the application design and development landscape !
Reblog this post [with Zemanta]
As promised in my earlier post, I am posting the review of the book  IBM WebSphere eXtreme Scale 6 by Anthony Chaves.

IBM Websphere eXtreme Scale is an in-memory data grid which was formally known as ObjectGrid.

Chapter 1 talks about the basics of data grid. Why do we need data grids? Caching requirements in Single threaded vs multi threaded applications, failure of singleton pattern and how data grids address the issue. Good start for novice folks. Once the basics are over, getting and deploying the WebSphere eXtreme Scale is as easy as dropping a jar file in the classpath. The examples start with the basic of how to an equivalent of ‘Hello World’. The example used is very lucid and easy to understand. The example covers how to create a grid and add and retrieve data.

Chapter 2 talks about the different kinds of maps available – ObjectMap and BackupMap, how the application makes use of these and how are they configured. How does the data persistence work with Backup map and the different locking strategies available? The author has explained the locking and deadlocks very well. This topic is must read as these learning’s will be applicable when debugging and tuning the application data grid.

Chapter 3 talks about how to manage the classes with relationships between them. The Entity API allows the application developer to define the relationships so that ObjectGrid can understand the same. The author covers the Query API that provides an SQL-like view into an ObjectGrid

Chapter 4 talks about how to integrate the ObjectGrid with the database. The author demonstrates the usage of JPA API to showcase how the BackingMap is able to persist the data using the Loader. This chapter is a must read for all who want to introduce data grids in their existing applications.

Chapter 5 and 6 onwards the books starts turning advanced, with details on client/server object grid and how data grid might exist outside of your application JVMs and span across multiple computers or even data centers, Shard types , data partitioning and replication. The author details on the basic configuration required to start server instances, how to connect to a distributed object grid, managing the server/container load and tips on capacity planning. Must read for administrators, on how to tune data grids instances for effective performance and scalability.

Chapter 7 takes the reader into more advanced usage of DataGrid API on how to co-locate data and logic.  The chapters details on how to write agents that can send logic to the grid/shard.

Chapter 8 talks about the DataGrid patterns that can be deployed to build applications. The patterns are generic and are applicable for any in memory data grid (IMDG) application.

Chapter 9 talks about the WebSphere eXtreme Scale integration with Spring. How the ObjectGrid instance are injected into spring and how to write interfaces using Spring managed declarative transactions.

Chapter 10 takes the reader into the application, various problems encountered by the application developers and how to use the DataGrid to overcome the problems. We see how not only we can cache ORM objects but also non ORM objects like html fragments, xmls’ etc

Overall, the book is a must have on shelves of all, who are writing distributed applications and intends to make use of in memory data grid.