Understanding Docker with an Analogy from Traditional Software Development

Docker, a Linux container that is becoming increasingly popular with developers for deploying apps to a cloud infrastructure. Docker allows application data to sync with the OS running on the cloud infrastructure. That means a developer can work directly from their desktop environment and use Docker to automatically sync updates.

Suppose a traditional software developer which follows the below steps as the development process.

1. Checkout a remote SVN/Git repository to the local file system 
2.  Improve the code in the local repository 
3. Test the code in local repository 
4. Push the modifications back to the remote repository, so others can update those modifications 

Then pushing those modifications to the production deployment is handled by a separate deployment engineering team. As developers only test their modifications in a local environment rather in the production environment, there can be bugs introduced in the production environment. This is mainly due to configuration differences between the local test environment and the production environment. This sort of bugs cause a lot of friction in the deployment process.

Docker tries to tackle this. Comparing with a source code repository system (SVN/Git) which manages the source code, Docker manage the complete software deployment (i.e. source code, configuration) as a "Container". This ensures every developer test their code in a developer environment exact similar to the production environment.

When it comes to maintaing the configuration of components with in the Container, it follows a JSON representation as follows.

WS-BPEL 2.0 Beginner’s Guide

Professor Matjaz B. Juric and I authored the book, titled "WS-BPEL 2.0 Beginner’s Guide". This book will be available in the near future and you can pre-order via PACKT Publishing site. We started working on this since 2012 and I would like to thank all who are behind the success of this book.

What you will learn from this book

•     Design and develop WS-BPEL 2.0 executable business processes
•     Get familiar with BPEL 2.0 activities and the most important usage scenarios
•     Develop a BPEL process to invoke other services and orchestrate them
•     Learn how to declare variables and store, assign, copy, and manipulate data within variables
•     Understand conditions and learn how to use the activities and loops
•     Invoke external web services using asynchronous communication channels
•     Recognize fault-handling capabilities to manage faults and to avoid unexpected states
•     Organize a BPEL process into hierarchical orders using Scopes
•     Define repetitive tasks in sequential or in parallel using dynamic parallel invocation activities

In Detail
Business Process Execution Language (BPEL, also known as WS-BPEL) has become the de facto standard for orchestrating services in SOA composite applications. It enables automation of business processes, reduces the gap between business requirements and applications, and allows better alignment between business processes and underlying IT architecture. BPEL is an open specification and one of the most important pieces of SOA. Therefore, learning BPEL is essential for successful adoption of SOA and for the development of composite applications.

This book provides a fast-paced practical introduction to WS-BPEL, one of the centerpieces of SOA. It covers the most important features of BPEL 2.0 and provides several real-world examples to underline its concepts. In addition to BPEL specifications, the book provides comprehensive coverage of BPEL support in JDeveloper and Oracle SOA Suite.

This book starts with an introduction to BPEL. It first teaches you how to develop your first BPEL process and understand the basic structure of BPEL processes. It will then move on to explain the core concepts such as invoking services, synchronous and asynchronous processes, partner links, the role of WSDL, variables, flows, and more.

Moving ahead, this book will make you familiar with concepts such as human tasks, fault handling, transaction management and compensation handling, scopes, events and event handlers, concurrent activities and links.

The book takes a fast-paced practical approach to WS-BPEL design and development based on practical examples and clear descriptions of the most important usage scenarios. This book is all you need to get up and running with WS-BPEL development.

Approach
A systematic guide for beginners which focuses on getting you up and running with building BPEL processes and learning the BPEL language with clear instructions and examples.

Who this book is for
If you are a software architect, a designer, a software developer, an SOA and BPM architect, a project manager, or a business process analyst who is responsible for the design and development of business processes, composite applications, and BPM/SOA solutions, then this book is for you. You should have a clear grasp of general SOA concepts including business processes and web services, but no prior knowledge of the BPEL language is required.

Time-lapse photography tryouts

I am working on few time-lapses these days. All shots were taken in Randwick, Sydney.

Sun turned red

Haven't see the sun turned red like this. This was due to multiple bush fires around Sydney and the due to the windy climate, the smoke covered up the whole city for several hours.

Defining Traditional Software Configuration Management (SCM)

Almost all the research on software configuration management has its own definition of the subject. All of those definitions highlights the idea of "dealing with the evolution". That means managing changes to the software during its life cycle. Much older studies on software configuration management processes more focus on controlling or limiting the changes happen to the software. But the studies that take agile process development in to the picture more focus on how to adapt to the changes to the software.  Here I have listed out few definitions of traditional software configuration management.

IEEE - "Configuration Management is the process of identifying and defining the items in the system, controlling the change of these items throughout their lifecycle, recording and reporting the status of items and change requests, and verifying the completeness and correctness of items." [1]

Tichy - "Software configuration management (SCM) is the discipline of managing the evolution of large and complex software systems."[2]

CMM - "Software Configuration Management involves identifying the configuration of the software (i.e., selected software work products and their descriptions) at given points in time, systematically controlling changes to the configuration, and maintaining the integrity and traceability of the configuration throughout the software life cycle. The work products placed under software configuration management include the software products that are delivered to the customer (e.g., the software requirements document and the code) and the items that are identified with or required to create these software products (e.g., the compiler)".[3]

RUP - "The task of defining and maintaining configurations and versions of artefacts. This includes baselining, version control, status control, and storage control of the artefacts." [4]

A common list of processes that usually are included in the definition of software configuration management:

• Identify configuration items
• Version control of configuration items
• Release management
• Build management
• Controlling/Adapting to changes
• Tracking status
• Auditing

[1] IEEE-Standard-729-1983, Standard Glossary for Software Engineering, ANSI/IEEE.

[2] Tools for software configuration management. In Proceedings of the International Workshop on Software Version and Configuration Control (Grassau, Germany), J. F. H. Winkler, Ed., Teubner Verlag, 1–20, 1988.

[3] Carnegie Mellon Univ. Software Engineering Inst.The Capability Maturity Model: Guidelines for Improving the Software Process, Addison Wesley, 1995.

[4] Philippe Kruchten, The Rational Unified Process: An Introduction, Addison Wesley, 2003.

    

Understanding the organisation's culture when designing a tool

When we design software for people, one thing we need to realize is the culture of the organisation. Because it exists before the implementation of the tool. Also organisation's culture determines the general mindset of people who are going to use that tool.
For an example, if you are going to design a issue tracker system for a software product, the sales team would expect a different set of user friendly UIs and data to be managed by the tool. If that tool is for developers, then they would expect more flexibility to add new resources to be managed and integration of the tool with other services/APIs like source code repository, email etc.
If we don't get this at design phase, a software development team will develop a tool for a sales team  where the tool has clueless features for sales guys.
One other aspect of this concern surfaces out when releasing major modifications to a tool. For an example, FaceBook users criticised a lot about the new timeline feature and GMail's new compose feature also was criticised a lot by the existing users.

Dynamic Performance Management in Multi-tenanted Business Process Servers Using Nonlinear Control

This conference paper "Dynamic Performance Management in Multi-tenanted Business Process Servers Using Nonlinear Control" is our latest publication which discusses the detail on our work on performance isolation aspect in a multi-tenanted business process execution runtime. It was recently published in 10th International Conference on Service Oriented Computing (ICSOC 2012), pp. 206-221. Authors of this paper are Tharindu Patikirikorala, Indika Kumara, Alan Colman, Jun Han, Liuping Wang, Denis Weerasiri and Waruna Ranasinghe.

Abstract of the paper is
The methodologies to develop multi-tenanted architectures have been investigated in the recent literature due to the popularity of cloud computing. A number of challenges need to be overcome if multi-tenanted architectures are to be effective and efficient. Among the challenges is the management of performance properties while effectively sharing the limited resources between the tenants. This work presents an approach to design such a management system for a multi-tenanted business process server. This approach not only enables performance to be maintained at different levels for different tenants depending on their priorities, but also autonomously detects the overloads of aggressive tenants and dynamically changes the control objectives to safeguard the business operations of other tenants. The novelty of the proposed approach is the use of the nonlinear feedback control. The experiment results indicate that the proposed nonlinear control approach achieves the objectives much better compared to the existing fixed and linear control techniques.

This paper can be accessed from here.

Relavant articles

• A Scalable Multi-tenant Architecture for Business Process Executions  
• Horizontal Format Data Mining with Extended Bitmaps - Extended version 
• Horizontal Format Data Mining with Extended Bitmaps 
• Mooshabaya: Mashup Generator for XBaya