Dec 10, 2015

Why Professional Scrum Master

I worked in an Agile project for an year and it was an opportunity to succeed in certification.

But I didnt got any job of a scrum master after the certification because no matter how much industry standardize the need for an scrum master but any company wont hire just a scrum master.  Though personal but I believe many think Scrum master is a temporary role. the certification started gaining popularity and the existing novice project managers were first to get certified and no doubt they are the ideal person to perform this role. Scrum, Iterative, or Waterfall all project managers are still there and they perform the same responsibilities. Indeed after doing certification I ponder it aint much. "Professional Scrum Master I" was not more than scrum guide. Job market is of Team Lead + Scrum Master or Project Manager + Scrum Master.

But its more than job to understand the methodology which has gained so much popularity. After I learned Agile, which only happened when I prepared for certification - I found there is more than SDLC model, it can be applied to our daily life.

We do work in Iterative or incremental way. But I know difference between Iterative and Incremental only after I am certified.  Its like preparing for fight or like we join gym and our instructor tells us its long way and end goal is to develop complete body and we have to work on every part of body day after day and we keep on measuring performance and product is always ready. Building your body is perfect Agile example. We measure success every few weeks, our body is always deliverable and we work Iteratively. Probably working incremental is first develop biceps in one month and next month concentrate on chest.

Life is Iterative and so every aspect of it, Every model software or business is Iterative, and Success is Iterative.  We can apply Agile everywhere. As a certified scrum master its my responsibility to think Agile and guide others on that.

Knowledge I gained while preparing for PSM is applied in my work every day. I prepare task list, update it everyday, segregate it into todo, done, etc. and my product is ready always. We combine Agile with Cloud, DevOps, and technologies.

But if you are looking for a Scrum master role by doing Scrum Master certification then you are late. Unless you fit in TL+SCM or PM+SCM profile.


Sep 5, 2015

Practical Agile

Principles of Agile

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

A big change is in thinking from Waterfall to Agile is that in Waterfall we know very clearly what we are building.  Indeed if we know what we are going to build, which also means we know tools, technologies, Operations, Architecture, resources, etc.  But we live in ever changing world where only time follows the same cycle minute after minute, hour after hour, and so on.
We keep time roughly constant and build in that time in iterative manner.  Our customers are in highly competitive market, they know they need vehicle but they don't know they need exact model.
A customer can give example of BMW X5, but this is not what he exactly wants.
And so we deliver in iterative manner -
One example is we first deliver a skate board, then cycle, then motorbike, then car, and customize car.

Agile is an iterative and incremental model of approaching planning, designing, developing, and delivering. Software development is a complex process where we probe, sense, and respond
In Agile we focus not only on delivery but also on early delivery.  No Big upfront planning, no big upfront design, no big bang theory, and no big phases, and neither jigsaw puzzle.

Incremental vs Iterative

Source -

An Agile team are made up of people with required skills, expertise, and authority to complete the specific task, or a minimum of all user stories in current Sprint backlog.

Best results are gained with co-located team, but I believe same results can be achieved by dispersed team with modern technologies such as web camera, webex, video conference, etc.
Daily Scrum or sometimes called Daily Standup should be done in same place with whiteboard using kanban approach, but it can also be done using tools like JIRA and video conferencing.  We used whiteboard initially, but after days we found it hard to share the whiteboard. Not everyone is updated with current state of whiteboard as it requires sharing whiteboard image after any status change of any task. When we shared whiteboard in video conferencing, some had poor connection and they were unable to view it clearly. Later we decided to also use JIRA, and then we found it hard to maintain tasks at two places - Whiteboard and JIRA. Lastly we decided to only use JIRA.
We had short development cycles and regular delivery but without pair programming. No two person have same skills and it becomes personal when they do pair programming.
Another major step is Continuous Delivery, which meant automated testing and automated build.
And Last Step is Iterative Releases

In big organizations, One simply doesn't starts with Sprint 1 instead Agile needs to be incorporated into existing established practices.
Merging and mixing methodologies will create confusion and so moving towards Agile is extremely cautious process and must be done with help of coaches and experts.
Typically we still have few - four stages - Initiation (Risk, Regulatory, ROI, etc.), Inception (Rough planning with Rough Design), Sprints (Design, develop, test, and build), Iterations(release).
A project will have a team to complete stages and team will constitute of Product Owner, Scrum Master, and Development Team (which might also include architect and tester).
Apart from above team, an organizations have secondary teams - Business Analysts, Performance Testing, Technical Experts, and other Specialists - for occasional support.

Waterfall to Agile Shift -
Practically Agile Still has Stagesand stages are same as defined in Project Management standards. I still feel there 4 major process groups -
Management & Control, Plan & Design, and Execute.
Lets forget for some time the original 5 process groups and 47 knowledge areas

Management & Control

Plan & Design
Plan & Design will also include planning for Security Requirements, Testing Requirements, and Business Requirements. Deliverable will include Signed off business requirements along with incorporating requirements into design. 3rd party contracts, review of design, and presentation of design. 


Sprints based on Scrum framework.
Source -
Outcome of every Sprint is an addition to Finished Work (Software Product).
When its decided to Release this product, then some SDLC documents need to be produced: Operational Risk Impact Assessment, Implementation Plan, Test Completion Report, High Level Operational Design, Approval, and RAID Log approval.


A helpful article on InfoQ combined with another helped me prepare these useful tips
  1. Remove the developer urge to shrink backlog, instead remain motivated to work as planned in Sprint planning meeting, and dont get distracted by blockers.
  2. Existing project managers have experience in fixing impediments, resolving conflicts, and organization culture, so they should accept role of Scrum Master, if they wish.
  3. Office Space should be very well ordered so that multiple scrum teams can sit and work on same floor.
  4. Technologies and processes should support Agile such as Microservices, DevOps, and Cloud
  5. Automated testing, Quicker Code review, Build tools
  6. In scaled Agile, a solid coordination is required on "Definition of Done" and "Scrum of Scrums".
  7. In scaled Agile, break user stories into functions rather than one line tasks.

Below is top three Impediments for Agile Adoption by InfoQ voting, which says who to blame -
  1. Organisational culture is not aligned with Agile value.
  2. Insufficient executive support.
  3. Existing project management processes/rules

Also according to InfoQ voting, what is most important for Agile Adoption -
  1. Continous Integration
  2. Automated Testing
  3. User Stories

Aug 30, 2015

Internet of Things

"The Internet of Things (IoT) is a scenario in which objects, animals or people are provided with unique identifiers and the ability to transfer data over a network without requiring human-to-human or human-to-computer interaction." -

But to me Internet of Things is thinking smarter and smarter and smarter. Once you start using smart devices and explore App store, your imagination grows. We as a human being have power of imagination to see things before they happen, we have tools, devices, and infrastructure to support our ideas: smarter search, smarter marketing, smarter shopping, smarter payment, and even smarter cities.
Devices we use are not only better engineered but also possess huge artificial intelligence. Devices from phone to TV to car to everything. Everything means everything, and these things can talk, exchange data, generate reports and decide our next delight.

The Internet of Things moves beyond Machine to machine communication, which involves smart devices. IoT provides IP address to every thing possible via IPv6, which was developed to deal with problem of IPv4 address exhaustion. IoT facilitates communication between things over network.
In recent times we have seen huge adoption of cloud combined with heavy analytics on huge data.
Software industry is mature now with proliferation of applications from every part of any industry to every device to more and more humans. Ever growing number of interconnected devices, continuous data exchange, big data storage and analytics have lead to new avenues in Internet of things market.

Why IoT is so important today is because timing is so perfect, smart human and even smarter devices, intelligent applications on cloud, big data analytics, and ever increasing demand. How we see world today is in right image from WordStream.

I worked on smarter planet project by IBM for Europe, where you develop load shedding zones within your home by applying multiple sub meters and decide on switching on or off group of devices, and this project was done in year 2009.
We have moved to a point of Body Area Network (BAN) with smart watch, smart t-shirt, and smart shoes to name few. It's all about imagination. Human minds build cities, human minds build Internet of Things, and can build Smart Cities. When we study more and more we build imagination more as we build our imagination on top of others, that is what happened with me too when I read more and more.

Its time for new age innovators to think of new things, or combine old ideas with new opportunities. IoT brings opportunities for engineers, managers, digital officers, entrepreneurs, businesses, consumes, and everyone.

Hype is snagging IoT, no doubt when we imagine beyond expectation we are in hyped world in which we think machines should decide government and a world without loose basic values of emotions and morals. This is reason why recently release IoT manifesto includes Hype as the first point.

We are at the centre of a universe of devices, laws, practices, procedures, etc., but good thing is they are now smarter and connected, they don't live in isolation, they dont need us to facilitate communication and best part they can communicate with us and we control them.

If you look for ten technologies around us that make Internet of Things, you will find below from CNET or Telegraph or Google:

Behind the scenes are technologies that making these things possible. Its a parallel universe, where every object - people, self driven cars, smart appliances, etc. - make then selves recognizable, they comunicate, and make intelligent decisions. I am not talking of just IP, AI, 4G, or Big Data; I am talking of summation of these all.
Communication technologies 4G, Wireless Sensors, RFID, M2M, etc. enable IoT. IoT applications will provide control over a network: a network of home appliances, Office AC system, Telephony, Home Security, Electicity Grid, Package & Delivery, etc.


With time we are making progess in - Highly connected networks, IoT applications, Infrastructure, Cloud computing, Big Data Management, Security, Devices consuming low energy, and Standardization - we need to continue making progress for early success and early adoption.


Aug 18, 2015


Sprint is generally 2-3 week event, but can be of 1 week or 4 weeks too, to develop some user stories. 
Below images give some idea on Sprint. It starts with Sprint planning, in which we choose the user stories to develop and ends with Sprint review in which we review what we have done.

"Scrum Framework" by Source (WP:NFCC#4). Licensed under Fair use via Wikipedia -

"Scrum process" by Lakeworks - Own work. Licensed under GFDL via Commons -

I am working on totally Agile project using Scrum framework and since everyone has his or her own way of doing things, the Agile is also bit twisted by everyone to adhere to a organization goal. My ideal way of doing a Sprint is 3-week Sprint.

Sprint Planning
Before start of Sprint we do Sprint planning with big motive of coosing user stories from product backlog and placing them in Sprint backlog. In Sprint planning all we have to do is choose user stories. I have found that initialy people show interest in these planning sessions, but later on these meetings become boring.
Choosing User stories is collaborative effort in which user stories have priority but its development team that chooses the stories they can deliver and User Stories are ready, its important
At the end of Sprint, the chosen user stories should be in done, and if not they can be part of next Sprint. A user story with done status can have a attached evidence, such as a user story of delivering login screen, can attach a screen shot of login button.
I have seen some scrum masters suggesting standard way for deciding story points, but I disagree I think poker session is fun part of Sprint meeting. A story point is like T-shirt size which is based on more on complexity compared to time because we are working in time box system., but its size. A better explanation is on -  If a user story is big and can't be completed in a Sprint, it should be further broken into multiple user stories, but a user story doesn't contains user stories, it contain tasks. Epic is broken into multiple user stories and a user story is broken into multiple tasks.
A Sprint is created with Sprint backlog at the end of Sprint planning. In my experience user stories are all in To-Do status right now.
Throughout the Sprint the development team can update the Sprint backlog.

Daily Scrum
15 minutes meeting where every developer (not scrum master or product owner) answers below questions:
What did I do yesterday that helped the Development Team meet the Sprint Goal?
What will I do today to help the Development Team meet the Sprint Goal?
Do I see any impediment that prevents me or the Development Team from meeting the Sprint Goal?
And development team member asnwer to complete team not to scrum master or product owner. 
I generally manage the daily scrum call, what I do is when I send meeting invite I also send above questions in the meeting invite, so that developers are ready with answers. Developers one by one, in alphabetical order, update in meeting by answering the questions. For a global team we used WebEx to conduct calls at fix time 1 pm everyday for any Sprint. We talk only about one sprint, we dont know at what time or where daily scrum calls will be arranged for next Sprint.
(Image Source -
Big point to note is we dont solve any problem in this meeting, but we do mention any impediment we face or see.

Sprint Review
On the last day of Sprint or after Sprint we do review, Sprint Review, which is an Informal meeting to present what was done in Sprint to scrum team and stakeholders. Generally presentation is of increment and feedback is collected along with answering any questions raised, and meeting should not go beyond 4 hours.
Sprint review session begins generally with a presentation in which Product Owner discusses what is done and what is not done, development team demonstrate the work done in sprint, a tester might give testing updates, development team member can give details of governance activities, and product owner can present product backlog.
A preview on what to do next and input for next Sprint planning; review of goals, timeline, and budget; and revise the product backlog.

Sprint Retrospective
"The Sprint Retrospective is an opportunity for the Scrum Team to inspect itself and create a plan for improvements to be enacted during the next Sprint" -
Sprint Retrospective, a max. 3 hr meeting, is done after Sprint Review and before next Sprint planning.

It is also mentioned in scrumguides that
The purpose of the Sprint Retrospective is to:
Inspect how the last Sprint went with regards to people, relationships, process, and tools;
Identify and order the major items that went well and potential improvements; and,
Create a plan for implementing improvements to the way the Scrum Team does its work
In my experience we shared on wall three columns:
What went well, What went not well, and What do we want to improve.
The columns can also be named as with meaning nearly same:
What went well that we want to continue, What we can do diffrently, and Action Items
Each development team member asnwer these questions such as one below:
 After taking inputs from each development team member, each development team member can vote for say three action items (What we want to improve), which can be included as User Story in next Sprint.

In a typical Software firm we dont just deal in development and meetings, we have lot of surrounding activities, which are lot more critical. A sprint is not only abouty development, we have look after testing and delivery too along with lot of governance activities and documentations.

An ideal scenario - 
An ideal scenario is a successfully implemented Agile project. I have seen a project in which we had delivery every three weeks
Lets summarize by this self explanatory image by "The Scrum Master Training Material"
A sample project plan with Sprints

Aug 17, 2015

Architecture design in Agile

"Architecture evolves" is the key word in Architect's mind while in Agile. Architecture is a set of features (Architecture Features) on which business features are developed, and its collaborative iterative design.

Architecture Design changes begin with one or more Epics. Architecture Epics are decided after an brainstorming session or architecture epic kanban system.
Next step is to decide one which first probably using WSJF, identify risks, discuss with business and architects, and define success criteria - all can be document in concise Business case document - optionally. Approved Epics go in backlog. This is done before Sprinit 0. 
After initial planning involve developers, and throught program Design is iterative.
Developers and Product owners can design too and if required get it approved from Designer.

Throughout the project, designers should be involved in Sprint planning to make decisions on product grooming.

A big move from waterfall to Agile is in Design approach where previous suggested final design and wireframes but later suggests iterative design and UX, similar discussion is on

Sprint 0
In Sprint 0 we have opportunity to decide on what to be developed in Sprint 1. Get fundamentals right before a time box even - Sprint 0 - starts; therefore First brainstorming between product owner and architect must be done before Sprint 0.

Notes for Evereyone
Design is not final and do not wait for wireframes
Design is not done in vacuum.
Bootstrap - services, build, and UI - initially, if design is not ready
Designer should start talking early to everyone - Product owner, manager, UI, UX, etc.
World doesn't needs Minimum Viable Product
Talk, talk, and talk with everyone

Architecture features are implemented incrementally and implemented by Agile team. Architecture features complete the business features and they also originate from business features.

More to designers
Advance HTML, CSS, and JavaScript allows us to prepare attractive UI, which combines with business features to finally become a delighful product, which also happens to be our aim; therefore we should not wait for wireframes and start working on most delightful product.
Product owners and developers are part of Agile team and they can too design, so they must be provided with enough knowledge and tools to make changes in design if required.
UX designers should start with sketches and designers should start with tools.
Big Design Upfront, Minium Viable Product, Non technical person, etc. are gone definitions.
A light weight modeling at the start is Architect's envision to identify risks and critical points.

Question for SCM 

What are two (2) ways a Development Team can ensure a good application architecture?
The Development Team should have a set of guiding architecture principles that every Development Team member understands and follows when writing code.
The Development Team plans some time each Sprint to discuss the architecture needed for the features planned in that Sprint.
There is no specific "architect" role on a Scrum team, nor is there an architecture planning Sprint.  But, a good architecture doesn't just happen automatically.  Guiding principles and frequent conversations on the team help ensure that the most appropriate architecture is developed as it is needed by features being developed in the current Sprint.

Who is responsible for the system architecture of a product being developed using Scrum?
The Development Team.

When is a system's architecture decided?
Throughout the project, as understanding emerges and the Development Team learns more about the project.

Architecture spike?
A small development activity to learn about technical elements of a proposed solution

Big Agile Picture
(Source -
On site you can click on any icon and get more details.


Aug 16, 2015

Scrum of scrums

"A technique to scale Scrum up to large groups (over a dozen people), consisting of dividing the groups into Agile teams of 5-10. Each daily scrum within a sub-team ends by designating one member as "ambassador" to participate in a daily meeting with ambassadors from other teams, called the Scrum of Scrums."

A little more investigation on finding coordination between several agile teams, "scrum of scrums" is the best solution. 

A typical Scrum team is five to nine people. Rather than scaling by having a large team, Scrum projects scale through having teams of teams. In this way, we have worked on projects with more than 500 people and have consulted on projects with more than 1,000. This also means several product owners and several scrum masters, along with chief product owner and chief scrum master.
Although it's not the only thing necessary to scale Scrum, one well-known technique is the use of a "Scrum of Scrums" meeting. With this approach, each Scrum team proceeds as normal, but each team identifies one person(a technical contributor on the team rather than product owner of scrum master) who attends the Scrum of Scrums meeting to coordinate the work of multiple Scrum teams; if 4 or fewer teams then 2 person – technical contributor and scrum master - can join from one team These meetings are analogous to the daily Scrum meeting, but do not necessarily happen every day.  It is recommended that this meeting be time boxed, like 15 minutes, and daily; but if meetings tend to be longer like 30 to 60 mins then 2 to 3 times a week should be sufficient.
Scrum of scrums generally suffice all requirements, but scrum of scrum of scrums is also possible though it sounds silly. A problem identified during meeting should be addressed, because it might be affecting work of 100 people. 
Agenda of “scrum of scrums” can be same as daily scrum, but Mike Cohn suggests below agenda, if meeting is not happening daily –
  1. What has your team done since we last met?
  2. What will your team do before we meet again?
  3. Is anything slowing your team down or getting in their way?
  4. Are you about to put something in another team’s way?
After every team member answers 4 questions, any problem identified are resolved. Backlog can be maintained of problems identified.

Scrum of Scrums are so effective that other meeting such as status meetings with managers should be discontinued. In many companies we start with one team, but as team size increases such as from 6 to 18, we need to split and create multiple teams and immediately start scrum of scrums with a board, as is a case study mentioned in
Representatives from all teams gather in a room with board with three columns: Issues to resolve, Resolving, and Resolved. Its not necessary that all teams send representatives in the first meetings, but with time more and more teams can join “scrum of scrums”; more important is right people join the meeting, either developer or tester, and a scrum master facilitates the meeting chosen on rotational basis. Its not a program level meeting attended by managers who are not doing work, instead its for people doing work to discuss and resolve issues across teams.
So, its not meeting scrum masters where they will discuss status. 

So we can understand what details about "scrum of scrums" is mentioned on Agile Alliance - Its normal daily meeting where ambassadors report completion, next step, and impediments on behalf of team they represent, and problems identified are maintained in backlog.

Jeff Sutherland also suggests that "scrum of scrums" is responsible for delivering the working software to the definition of done either on specified date or multiple times a day.


May 29, 2015

Java Developer : Anatomy and life cycle

I have been a Java developer for years and probably more to come. Becoming a Java developer is easy, you need to read a book and develop a "Hello World" program, crack interview and work (with help of google). With your aptitude and learning you start programming fast and more your experience lesser you google. Not exactly, I do google many times a day since beginning. Technology is fast changing world, but concepts don't change so frequently. Once you learn the concepts, its easy for you to learn new frameworks & libraries. All it needs to learn Core Java, OOPS, and design patterns, though you would be using them not often. Then comes the framework like Spring & hibernate, Oh Man! without them many think you are not at all a Java developer. Most of the job requirements have core java, multithreading, design patterns, spring, and hibernate. List is incomplete, but above mentioned technologies are sufficient to land you a nice paying job. Include JSP, Servlet, EJB, JTA, etc. for variety and if requirement is more of J2EE(sorry Java EE).

Within few years of Java development, you are not just a man, your body is not just bones, nerves, blood, and muscles; java is in your blood now. You never write "Hello World" again and you never miss opportunity to discuss programming. Somewhat like below -
Many times recruiters call me ask if I have 10 years of Java experience in Multithreading. May be they don't know what we exactly do, and it might be rarest or rare possibility that most of us have been working on multithreading for continuous 10 years. But its ok, they need a man with 10+ years of multi threading experience, may be they don't need just a man, they need Spider Man. And Yeah!!! if you have 10+ years of hard core multi threading experience, you are indeed Spider Man : More than just a man. A Legend (Bruce Wayne, if you remember Liam Neeson in jail in Batman begins). 

And trust me you world be flying high, and your feet will never touch the ground. Your threads are your wings, Be like Mike. 

But there's more than that, what if a company gets a resource with expertise in Multithreading and Spring. Man!!! your managers are like kids and they will imagine you like Spring bed Spiderman, where they will jump, enjoy pillow fight, and eat lunch. 

May be it all looked like fantasy world, because realty we face everyday is different. Our managers can't give everyone the A rating, not everyone can get 30% increment, and plethora of Java developers in market makes us find hard a nice job. Not only this, everyday new technologies make our life worse. All those buzzwords(Cloud, REST, boot, DevOps, etc.) scare more than excite in interviews. Above all the interviewer expects us to sort a list, and design a Casino. Some one asks inner class, and some ask to explain hashing. There's no limit on how far an interviewer can go, doesn't matter I have 2 years or 12 years of experience, an interview question never gets outdated.
So that's a challenge. And so whenever I face a new question, I try to post on my blog, but there's no universal set of interview questions.

Also, we don't know which question to ask for a particular level of experience. Or any one knows what's difference between 2 years Java developer and 3 years Java developer.
BUT OK, classification is not that difficult. Ask me, I think as a man has several life stages like child, adult, old; A java developer also has life stages, and those are

  • 0 years of experience (also called 0-2 years of experience)
  • 5 years of experience (also called 4-7 years of experience, some also put 3-5 in this category)
  • 10 years of experience (also called 8-12 years of experience)
  • 15 years of experience ( rare )
  • 20 years of experience (very rare)

15 years and 20 years rare because till that time, many start climbing the corporate ladder like some become project manager, some architect, and some leave IT industry.

But I think there are some figuratively different stages, and they map to above mentioned stages.

  1. Fresher - 0 years of experience
  2. Developer - 5 years of experience 
  3. Dangerous - 10 years of experience
  4. Decaying - 15 years of experience
  5. Dying - 20 years of experience. 

So, if you are hiring you look at the experience level, and imagine what he is. A 10 years of experience and doing development is a dangerous man. He has knowledge, experience, standards, guidelines, vision, tummy, etc., But he might be very useful or he can be dangerous. He sees thing going wrong, he will shout. He will not spend day & night on silly requirements. He will force client interaction, and he can explain business to client. Such people spend much time in mentoring and sharing experience: not only java, but life experiences. They like to talk, discuss, and guide. But they might be frustrating to other junior developers or managers. 
A developer is -5+ years of experience. Yes, he is energetic, he has experience, he has knowledge, and desire to deliver & learn. He is the man. 
15+ years of experience man is doing development because he might be helpless, so you hire him better make him as an architect if he can, or hire him as supporting cast. But he has seen life, he has seen ups and downs and may be now he believes - works never stops, whether I do or not. 

I am a maroon 5 fan, I read motivational quotes and many times believe I am animal. And I think Java developers can also be classified as animals:

He or she starts career as a deer, and becomes horse, but with time he is old, and finally he is cute again. But remember inside he is panda now not a deer. 


Apr 23, 2015

Java EE Notion

Enterprise Java Beans - Business layer

In J2EE, EJB  was best fit for placing the business logic (Session bean and to some extent Message driven bean). and in Java EE still EJB best fits there. 

EJB's are of two types - Session and Message-driven.
where session bean suits for creating boundary, session facade, or service facade. Message-driven beans (MDB) acts as listener to JMS Queue or Topic.
Message-driven beans are used frequently to handle requests in asynchrnous manner, but since now we can have asynchronous session bean methods, usage of message-driven beans  will be limited.

Since message-driven bean is asynchronous, some transaction attributes wont be applicable.

With time boundary will become complex -

But a boundary may be far more complex, it might be coordinating multiple components, calling backend services, sending message on queue, calling utilities, logging, etc., but a satteless session bean is still enough.  Generally the bounday will expose coarse grained (not fine granied) methods, and with time boundary will become bloated and complex.  Controls are added to make boundary leaner. I learned this pattern from book - "Real World Java EE Patterns" by Adam, that control should be a POJO and should reuse the transaction started by boundaries.

Gateway (I am not sure, if it should be called Gateway) pattern suggest direct interaction between presentation and persistence, without any indirection from boundaries.
UI should directly communicate with entities. Indeed I believe we can have entities which represent database resources and expose them as REST services and let UI consume those services.
Which I believe very simple and very sophisticated.

Boundary or Anti-boundary comes down to choice, like REST or SOAP. Some times we need boundaries and some times we want to presentation (or client) consume directly server resources. Indeed, if you ask me we need both. Developing a complete application using REST is also not easy, for example how you will implement fund transfer. But developing application with lot of complex boundaries is not feasible today and is definitely outdated even before completion.

An application can be developed using microservices and aggregators can be used over microservices to present business boundaries, which is the trend now.
Aggregator patterns like on below link -

In Java EE, we need a server side Java class holding business logic, with container managed transaction, security authorization, etc. The developer concentrates on business logic, like for example the fund transfer. The developer has some basic assumptions that should be taken care by container: The fund transfer method should be transactional, and not every one is able to do fund transfer; these things should be managed by container. Session beans fit for writing logic of fund transfer; and let container manage transaction, secuity, pooling, creation, deletion, initalization, etc. 

Boundary design pattern and EJB as boundary - 
An online banking application has lot of business logic which can be encapsulated in several methods like fund transfer, account balance, account details, debit, credit, etc.  In a Java EE application or any enterprise application, we need to centralize business logic across business-tier components and services.  The access to business logic components has to be convenient, consistent, scalable, and maintainable. A dedicated remotely available transactional boundary is required.  The boundary exposes business methods, easy to consume business API, encapsulating business logic, and designed from domain perspective.  The boudary is not required to remember the client between several calls or maintain a session state for every client. Boundary should be stateless.  A stateless session bean with no interface is best suited as boundary. A remote interface can be provided if boundary will be used from another JVM.
No interface is required, bean can be injected into another components, and can be exposed as JAX-WS or JAX-RS endpoint.
EJB is just a POJO with @Stateless annotation. The annotation is enough to add default transactional boundaries and configurable security. Same EJB can be exposed to remote clients. Same EJB can be exposed as WebService with @WebService annotation. And Same EJB can be exposed to REST clients with @Path annotation. And this boundary is not required to implement any interface. 
The boundary is consumed by UI or client components, and every interaction is a business transaction (theoratically).  Transaction should be container managed and business methodsa should not explicitly deal with transactions.  By default transaction should be start and end with business method.  A stateless sesison bean (SSB) with container managed transaction (CMT) and default transaction attribute of REQUIRES_NEW is perfectly suitable for creating business boundary.

End users dont start transaction, presentation layer usually doesn't start transaction, even boundary methods dont invoke each other in same transaction, so REUIRES_NEW is best suited
transaction type for bounday. In EJB its default, and can be changed by setting the transaction attribute like below -
public boolean fundTransfer(Transaction txn){ ..}

Servlet is Java class that acts as a server for web clients. Servlet can response to any kind of request but commonly used by web clients using request/response model.
Container manages the life cycle, requests, response, etc. of servlet.
Examples -
1. @WebServlet("/account")}
public class AccountServlet extends HttpServlet ... {
2.  @WebServlet(name="AccountServlet", urlPatterns={"/account", "/all"})
public class AccountServlet extends HttpServlet ... {
At least one url pattern must be declared.
A servlet is defined with @WebServlet annotation on a pojo and it must extend HttpServlet. If name is not provided, the fully qualified class name is the servlet name.

Container on receiving first request for a servelet, will load the servlet class, create instance of servlet class, calls the init method of servlet class, and invokes te service method passing request and response objects.
There onwards only service is called, but if servlet is to be destroyed then container calls destroy method of servlet class. That means we can override (optionally) init to perform any initialization and destroy to perform any cleanup.
Service method is any method that can handle client request and return response. service() method is part of GenericServlet class, which is extended by HttpServlet, which we will extend while writing our Servlet.
HttpServlet has one doXXX() method for each HTTP method: GET, POST, PUT, DELETE, and so on.
Container (Server) will call the doXXX() via service method when client sends XXX request, that is to say doGet will be called when client send GET request. We will never override service() method, instead override doXXX() method,
and mostly doGet() or doPost().
By default container will create only one instance of servlet per declaration.
If application is marked distributed, container may have one instance per JVM.
Container will instantiate multiple instancs of servlet per JVM, if servlet implements SingleThreadModel (deprecated interface).
Web container handles concurrent requests to the same servlet by concurrent execution of the service method on different threads,
unless Servlet implements SingleThreadModel where container should gaurantee only one request at a time to service method.
It is recommended to use Atomic instance variables ot synchronized blocks to avoid multithreading issues, but avoid SingleThreadModel and synchronized doGet() or doPost() methods.
Any required intialization parameters are passed using @WebInitParam.

ServletContext is the interface (it has got methods that) servlet uses to communicate with container. One context per web application per JVM.
"In the case of a web application marked "distributed" in its deployment descriptor, there will be one context instance for each virtual machine.
In this situation, the context cannot be used as a location to share global information (because the information won't be truly global). Use an external resource like a database instead." - Oracle docs.
ServeltContext can be used to share information between servlets. Like an object can be added as attribute to context, which can be retrieved in other servlet.
Servlets can share information like objects by maintaining them as atrributes in one scope objects: context (ServletContext), session (HttpSession), request (ServletRequest), page (JSP page).

We can listen to Servlet lifecycle events and react to them by registering a listener class. Events like : context initialized/destroyed, attribute added/removed/replaced in context,
session creation/invalidation/activation/passivation/timeout, attribute added/removed/replaced to session, request recieved, attribute added/removed/replaced to request.

        name = "TransferServlet",
        description = "This class handles fund transfer",
        urlPatterns = "/ft"
        initParams =
             @WebInitParam(name = "minBal", value = "0"),
             @WebInitParam(name = "maxLimit", value = "50000")
public class TransferServlet extends HttpServlet {
private AtomicInteger counter; // thread safe counter, counts number of transfer
public void doGet(HttpServletRequest req, HttpServletResponse res) {
if(!(req.getParameter("amount") > Integer.parseInt(getInitParameter("maxLimit"))) {

A filter class can modify the header and/or content of request and response.
Multiple filters can be chained (by calling FilterChain.doFilter()), means filter will be callled in sequence before actually request reaches servlet or response reaches client.
Filter can add/modify/remove attribute to request, filter can change response, filter can perform logging like session log, filter can even block the request from reaching servlet (dont call doFilter()).
        urlPatterns = "/ft",
        initParams = @WebInitParam(name = "defaultCharge", value = "1"),
        description = "Filter to log and apply charges",
        dispatcherTypes = {DispatcherType.REQUEST, DispatcherType.FORWARD}    
public class TransferFilter implements Filter {
default dispatcher is REQUEST (to be used when request comes directly from client)

Asynchronous Servlet
Asynchronous Servlet was introduced in Servlet 3.0, and enhanced in Servlet 3.1 version as part of Java EE 7.
Idea is "Client sends request -> Container allocates thread (from pool) to handle request, and invokes servlet -> Servlet code calls request.startAsync and saves the AsynContext (like in list) -> Thread exits (or returns to pool) -> Connection is still open -> Some other thread uses saved AsyncContext and sends response (AsyncContext.getResponse()) and completes the process asyncContext.complete() -> Client receives the response".
So inside doGet or doPost, we will have code like below -
final AsyncContext asyncContext = request.startAsync(request, response);
asyncContext.setTimeout(10 * 60 * 1000);
list.add(asyncContext); // an option, otherwise an instance of Runnable (with AsyncContext) can be passed to a thread pool, so that another thread can handle sending response.
// Above code will be called by thread one, handling request
// Below code will be called by another thread sending response
asyncContext.getResponse().getWriter().println(htmlMessage); // an option

One of the new feature of Servlet 3.1 was support for Non-blocking IO (NIO).  Servlet 3.0 only supported traditional IO.
A typical usage is when we write code like below -
request.getInputStream() and read byte by byte, now if Input is blocked, then servlet is waiting. Similar situation can arise white writing OutputStream.
Below is the code which uses NIO
AsyncContext context = request.startAsync();
ServletInputStream input = request.getInputStream();
input.setReadListener(new MyReadListener(input, context));
where MyReadListener has callback methods -
onDataAvailable callback method is called whenever data can be read without blocking
onAllDataRead callback method is invoked data for the current request is completely read.
onError callback is invoked if there is an error processing the request.
Also Important is - The asynchronous behavior needs to be explicitly enabled on a servlet, i.e. add asynSupported attribute  on @WebServlet, like below -
@WebSerlet(urlPatterns="/xyzAsync", asyncSupported=)
MyAsyncServlet {

Thread per request
Also note the HTTP 1.1 where connection can be kept alive and can be reused for multiple requests.
So at bigger level, we can assume one thread per connection.
Major improvement came with NIO library where threads can be pooled, thread will be attached to connection when request is processed, and when connection is idle thread can be recycled & connection will be placed in a channel for selectors.
So we assume its Thread per request.

Servlet Protocol Upgrade
It is mentioned in section 14.42 of  RFC 2616(url) -
"The Upgrade general-header allows the client to specify what additional communication protocols it supports and would like to use if the server finds it appropriate to switch protocols."
So, if Servlet supports any other protocol (or allows upgrade of HTTP 1.1 to some other), then client can set the "upgrade" request header with desire to upgrade to mentioned protocol.
One example is RFC 6455(url) for Web Sockets. A nice example implementation of upgrade is -
In the example servlet's doPost method, below line checks the header value from client
if ("isbn".equals(req.getHeader("Upgrade"))); // assume the new protocol is isbn
if above line returns true, that means client supports isbn protocol and would prefer isbn over HTTP, if at all server finds its appropriate to switch.
At server end we have to provide an protocol handler, like in the example is "ISBNHttpUpgradeHandler".
The servlet container supports upgrade, but doesn't have any knowledge about upgraded protocol. The protocol processing & handling is provided in HttpUpgradeHandler, like for example ISBNHttpUpgradeHandler.
public class ISBNHttpUpgradeHandler implements HttpUpgradeHandler {..}
HttpUpgradeHandler has init() and destroy() methods, which needs to implemented. init() will handle the connection like reading input data, and destroy will be called when client is disconnected.

Servlet & MVC
In the MVC 2 architecture, the controller is Servlet.
Initial J2EE designs used to have JSP for view, Servlet as controller, and Java Bean as model. Many servlets, JSP's, and beans, where beans can be EJB's too.
A simple J2EE architecture can be like -
Later frameworks came with a big controller servlet. Servlet is for routing, and controllers are normal Java class. Servlet routes the request to appropriate controller.
Like in Struts 1 architecture -
In Struts, there was only one controller servlet : ActionServlet. URLs were mapped to handlers(actions), and mapping was mentioned in struts-config.xml.
ActionServlet routes requests to handlers (actions) and ActionForm (like JavaBean) is used to persist data between requests.
Important is all those servlet objects: request, response, session, etc. are available to action.
Struts lost somewhere, but Spring MVC is still one of the most popular framework for building web applications.
Spring also uses a central controller "DispatcherServlet" which receives the request, dispatches task to HandlerMapping to select appropriate controller, and task of executing the business logic of controller to HandlerAdaptor.
Controller executes business logic, sets Model, and returns view name. DispatcherServlet dispatches the taks to resolve View based on view name to ViewHandler.
View renders the model data and returns response.
Similar is the FacesServlet. FacesServlet is the central controller, and engine of JSF application.

I draw this picture to remind myself that we can optional Filters before Servlets, we can have Listeners registered for different Events, and Servlets share ServletContext


I am not using JSF and even dont recommend, but I am Java EE fan, so I was going through the JSF. Below is the short tutorial over JSF, very helpful to those who are new and to those who have forgotten.

JSF is framework to develop web applications.
Framework has everything like
server side UI components, renderers, and tag library which makes easy to develop(or as easy as generate) pages.
page flows
APIs to manage state, events, validation, conversion, navigation, internalization, etc.
Extension capability
Framework enables creating pages by drag drop, interactive web pages and presentation oriented web application.

With recent development and advancement of javascript frameworks, we have microservices architecture or service oriented web applictaion.
A service oriented web application enable exposing resources (like DB entries) as REST services, and another application which is presentation oriented(developed in HTML, Javascript fraemwork)
will consume the services.

A web application developed using JSF has presentation layer along with server side code. So, its presentation oriented.Easiest way I found to get started with JSF is using Netbeans, where you create a Database and get rest code generated using below wizards -
"Entity Classes from Database" and then "JSF Pages from Entity Classes".
The wizard will generate the pages along with CRUD capabilities, i.e. pages for creating new resource(entry in table) in database, updating resource in database, deleting resource in database, etc.

Developing a web application involves creating a component which will handle client requests and redirect them to appropriate handler(/controller) and send response back,
along with managing page navigation. AND we need a mark up language which will process and present the text. The markup language has code(tags) for formattting (layout and style), and xHTML is one such markup language (like HTML).

A bare minimum JSF application will include an xhtml page (or two), POJO with @Named annotation (or @ManagedBean), and web.xml. Yes thats's it.Assume index.html which also happends to be the welcome-file, with submit button and gets redirected to another xhtml, like response.xhtml. welcome-file is the landing page of a web application, and specified in web.xml, like below -

User fills some text boxes in index.html, like name, same name field is mapped to name field in POJO, and name value is displayed in response.xhtml.
response.xhtml has code Hello, #{}, to display name, where name is field in POJO (so by default
index.html has following code for input to enter name-
                         title="My name is: "
                         requiredMessage="Error: A name is required."
                         maxlength="25" />
where h is prefix for the JSF HTML tag library whose URI is, so h:inputText is an example tag of that tag library.
Similarly we have other tag libraries like core (c:), and sophisticated facelets with URI and prefix of ui.
@Named annotation gaurantees default EL naming (i.e. we were able to refer name field using #{}).  Also we can apply @RequestScoped on POJO Hello, so that pojo persists for siingle request only, which was suitable for our case, where use entered a value in one xhtml, value got set in POJO and was displayed in next xhtml. We can combine @Named and @RequestScoped to create a new annotation, like @Model (such an annotation is called stereotypes).
The next xhtml to display can be mentioned in the index.xhtml, liek below -


and so, response.xhtml is displayed next.
The next xhml can be configured in faces-config.xml : where we can define the flow, a flow of pages, something similar to Spwing Web flow or ADF flow.

POJO which also happens to be managed bean is exactly a CDI bean. A POJO with @Named anootation is CDI bean which acts like backing bean for JSF (we dont need @ManagedBean now).
Optionally(ane mostly) CDI bean will be communicating with entities (POJO with @Entity). And flow will be defined in faces-flow.xml, so a typical design will be like below -

Though its not much of concern, but its good to know how the request is handled, or life cycle

IN JSF application we can have classes like: We can have entity (POJO), a class to manage perstence for this POJO, and a controller clas that will act as managed bean for JSF.

Rest I will suggest you sample application can be ready using Netbeans, and then you can start with -
handling page navigation, layout of pages, custom components, etc.

Java EE Architecture today

Entity Control Boundary

Entity Control Boundary (ECB) is popular design pattern. I read in book by Adam Bien.
Below is the extract from "Real World Java EE Patterns" by Adam Bien -
"a boundary exposes the interesting functionality, coordinates independent Controls and hides irrelevant details".

Its not like many dead design patterns (Service facade, Business Delegate), and suits well to microservices designs.

I got a project for travel company. Category is like beaches, hills, etc. Destination is place like maldives.

A service (boundary) provides list of categories and hotest destinations in that category.

Entity - Category, Destination, etc.
Control - CategoryController which provides CRUD operations on Category and other operations.
Boundary - Some class with operation "HotDestinationsWithCategory"

No doubt now the most widely used design pattern is ECB (Entity Control Boundary). I am equivocal to some extent and I will say: Its straight, simple and everything. Yes to some extent that's true, You can design smallest to biggest enterprise application using this simple design pattern, and nothing else.

Even if you are not interested in JSF, lets asume its server side java code, which allows user to perform CRUD operations. I got entities, they are related, but I have one controller and one boundary for each entity, separately. We can have "One entity, one control, and one boundary", "Second entity, second control, and second boundary", and so on. Right now everything is in one package, but we can place each combination(entity, control, and boundary) in separate package(jar or even war). But generally boundary will involve multiple controllers.

I am working on an application, called Visit,and below are some classes I have generated (yes you heard right, generated, because I use Netbeans)..;)

In above generated classes, Category is entity and CategoryController is the controller.
If in case we need to write business logic and create business methods, we will use and combine multiple controllers. 
© Technology Development with Java background | All rights reserved.
Blogger Template Crafted by pipdig