J2ME, Symbian C++, QT or Android :: Why & Where?

"Once upon a time there was a language called J2ME", you will not be surprise if you hear this few years later. But it should not be forgotten that each of these languages have its own context or domain which can vary according to the needs of the customer.

Why & Where...

A well known truth about J2ME is that it is a sandbox language. I.e. It always needs to stand on top of a another language stack (OS) & hence J2ME is always restricted to access some kernel level functionalities of limited devices because of this 3rd party behavior. For instances one can not write an app which can be auto-started in device boot up without using some other party interaction like push registry. Of course by using push registry one can write an app which will auto-start but via a timer, sms or http like interaction signaled by an outsider. Therefore without any interaction auto-start in boot up is impossible in J2ME. Another scenario is accessing device key pad for locking and unlocking purposes is also impossible as J2ME is not allowed to access locking API of the device. Actually J2ME does not even has such an API for locking. One more thing to notice is that every mobile device has a settings programme which is responsible for managing installed applications. In J2ME context you can never write an app to get the control of this settings app which is silently handled as a device kernel level programme.

As mentioned the primery reason for this is J2ME is a third party language pre-configured and installed on top of another core language stack of the device. For example simply consider Nokia mobile phone which claims to support for J2ME. But the fact is Nokia has its own language stack as the core of the device called Symbian.  Symbian OS has its own rich APIs to directly interact with hardware level and other core functionalities of the device. Symbians S40, S60, Symbain 3 are examples for such Symbian OS APIs equipped with SDKs to leverage developers for developing apps. Both the carbide.C++ and the later added framework called QT C++ can be used for writing applications for Symbian OS. Above mentioned impossible scenarios in J2ME can be achieved via these two implementation frameworks.

But as J2ME hides internal complexities from developer, for developing some typical enterprise level apps, J2ME is apparently efficient and easier than using Carbide or QT. Hence language depends on requirements as always. Focusing on Android here is irrelevant because it is that big buzz word everybody talks about these days. To be it as this much of huge buzz, its complete OS stack has played an incredible role. Because of this perfect organization from ground level APIs to higher level APIs in its OS stack, developers have been able to develop apps without considering dependencies, hardware abstractions, library couplings etc. But there is an one little problem with Android. I.e. its fast growing development life cycle. Not like any other OS versions of other devices, Android does not provide long term service for once released version. They tend to grow fast and if earlier version can not tolerate with the later version, bad luck for the users those who have that earlier version of device. But generally people rarely open their mouths up on this.

Therefore Why and Where is a decision made by developers.

Checking out and setting up QJSON for QT symbian

Generally JSON is simple data exchange format like xml but more simple and flexible than it. Specially when transferring data in XML format, it adds more weight to the actual information we want to transmit as information is overwhelmed by opening and closing tags. This can sometime be useful and sometime be an overhead. To avoid or reduce that overhead we can use JSON. It stands for Java Script Object Notations which can be used to transmit data over http as JSON object. There are many JSON related online references are availble in internet. Therefore What we are focusing is QJSON which is QT based library that maps JSON data to QVariant/QMap objects.

We will consider making qt lib and setting up the path properly via QT creator IDE.  qjson library is not implicitly available with default libraries comes with QT. Therefore you have to checkout qjson project source separately and then build it and generate a qjson lib file. One thing to notice is do not try to download qjson source from source forge because due to some reasons it is not the complete project for one to develop lib file they need easily. That source hides some essential files like .pro file etc which are useful to generate lib file directly by using QT Creator IDE.

For checking out the latest version of qjson, first you shoul have a git client installed in your machine. Git is a FOS distributed version management system that can be downloaded from official git site. qjson repository is hosted here. For checking out this as online from downloaded git client, usegit clone git://gitorious.org/qjson/qjson.git command and import complete latest qjson version to your local disk space.

Then open this qjson project via QT Creator and build it. It will create qjson.dll.a lib file under build/lib folder of qjson source. It is like your_disk_name:/qjson-0.7.1/qjson/build/lib/qjson.dll.a. Now all you have to do is to tell QMake in your .pro where is located your header files and lib file.

Ex: type as following in any where of your .pro file

INCLUDEPATH += "c:/qjson-0.7.1/include"

LIBS += "c:/qjson-0.7.1/qjson/build/lib/qjson.dll.a"

That's it. Enjoy qjson in QT. Some initiative code snippets on qjson for qt can be found here.




Distributed Resource Management System for Business Process Management Systems

I did my final year research on Distributed Resource Management System for Business Process Management Systems. I have shared my research abstract which was published in UCSC researh symposium 2011 here with. For the purpose of research evaluation and demonstration, RESTful Distributed Resource Management System (DRMS) engine has been developed and integrated with one of FOSS BPMS.

Business Process Management (BPM) is a discipline which maps human tasks and non human tasks according to a predefined workflow in a way that technical and non technical people in the organization can administrate, monitor and communicate effectively and efficiently. Considerable amount of BPM software are available to automate business processes. When business becomes more complex and needed to be expanded or out sourced, a single BPM server may not be sufficient to tackle all these processes. This may lead to manage several BPM systems within one organization. However if those servers are not properly connected and configured, even allocating a single resource for a single BPM system can also be difficult due to the lack of information available at a glance. Apparently a mechanism should be established to enforce cooperation among homogeneous BPM systems.

DRMS for YAWL is a distributed resource management system which leverages administrative activities like monitoring, decision making and scheduling for YAWL, an open source Business Process Management System (BPMS) developed by YAWL foundation. When business is needed
to be expanded to cope with internal or external transactions, organizations should have to increase their technical servers from one to several. At this stage when each of these servers is dealing with organizational processes (business processes) instead of writing their own logic to tackle with business, they can use existing BPM engines to get efficient and effective results. While using several BPM systems within same organization, accurate coordination among each is
highly required to place correct decisions and schedules. Placing a new business process tends to be difficult if the administrator cannot deterministically come to a conclusion, in which BPM engine he should place the new process. In fact that is what DRMS is trying to solve.

DRMS uses existing resource patterns and introduces some new patterns to cope with distributed resource management. DRMS is equipped with two major perspectives called snapshot view and rule execution. In snapshot view, global synchronized view and non-synchronized view are considered. Synchronized view is what administrator can get as a real global view of all resources in BPM cluster. Non-synchronized view lets administrator to explicitly decide in which distributed BPM servers’ view he tends to view in a given time independently from other servers. Before making decisions when managing resources distributed across a cluster of servers, it is more important to analyze the current state of the cluster; thus, we came up with this idea of global view. For this, we have extended few resource patterns where more significant and important features of a state of the cluster can be extracted easily. By thoroughly analyzing, we manipulated several key factors of functions which must be available in any view, to speed up the process of making more effective decisions. The idea of granting administrators both synchronized and non-synchronized views can leverage identifying different states of the cluster before executing the correct rule set. There administrators of the organization can analyze independent views by switching among each of BPMS by standing with a single interface of DRMS. This is facilitated in non-synchronized view. Gradually when cluster expands, implicit information gathering from cluster by the system is more efficient and it is facilitated by synchronized global view.

Views help to decide on decisions that are going to be made. In fact to execute those decided decisions, there should be a distributed rule execution mechanism for DRMS which is called rule implementation. At the moment these rules can be evaluated and put in to action in the synchronized view. Distributing resources according to capabilities, roles or positions and assign administrative access levels to employees are two patterns which are implicitly available in DRMS. Distributing newly available work items (processes) among BPM cluster based on how similar kinds of processes were executed in history is an advanced solution. Mutual and union resource extraction and updating the cluster through global flooding with or without a restriction are some sub patterns that are also available in DRMS for YAWL.

DRMS also supports for load balancing up to some extent. Workflows will be deployed according to the selected load balancing algorithm. Four suggested workload routing algorithms namely random, round robin, priority and dynamic help to adjust the load of the BPM cluster as determined. At the moment DRMS has been developed to work with YAWL BPM engine through mainly communicating via its resource engine. However one of the key features of DRMS is that its implementation is completely independent from YAWL’s implementation issues. That is, DRMS calls to YAWL remote functions via RESTful service calls over HTTP and in order to facilitate this DRMS service, it would be more appropriate to have a homogenous BPM cluster. That means each and every BPM engine should be from the same vendor or otherwise must be same open source product. Apparently, in reality, it is very rare that a particular organization may use different kinds of BPM engines within their domain as it adds performance and scalability issues while integrating, controlling flow of events, associating data and handling exceptions due to different architectural implementations of each BPM systems.

Main objective of this project is to show that if managing several BPM engines, by using a mechanism which is equipped with view analyzing and rule execution by extending standard resource patterns and introducing some new resource patterns to fit with a BPM cluster, both resource and work item scheduling can be orchestrated more easily and effectively. It adds a central accessibility for all distributed engines. Hence, we suggest by applying our studies to existing BPM systems, both local and global contexts will be implicitly available for customers unlike existing BPM engines support only for resource management within its local context. Therefore, as distributed resource management among homogenous BPM engines via work flow patterns is not yet ported, we hope our research findings will be useful in coping with similar kinds of situations in future emerging extensible Service Oriented Architecture (SOA) based BPM engines.