Oct 22, 2014

Online Banking: New features

With increasing number in mobile banking use (also in online banking), customers are looking for ease along with security.
And mobile wallet is probably future.

Essentially a digital container running on a mobile device, a mobile wallet is designed to aggregate and manage mobile commerce services, supporting payment cards, tickets, loyalty cards, receipts, vouchers and other items that might be found in a conventional wallet (or purse).

Wallet revolution failed so far, until Apple Pay. On 21st Oct, Bloomingdale, Foot locker, Toys R Us started accepting Apple Pay. Apple’s partnership with Visa, MasterCard, and American Express boosts the customer’s trust and legitimacy. Few months back Standard Chartered launched mobile wallet Philippines. M-pesa is available to Vodafone customers in many countries, and similar is Pingit by Barclays to UK customers.

Banks focusing on Online Banking and mobile banking should provide mobile wallet to their customers, because according to survey -

So, Every Bank should launch mobile wallet asap, if not done yet. 

Still many banks want to upgrade their online banking features and looking for what new can be done. 
I have found some features are very unique to some bank and which are rare but interesting and attractive. 
Online banking provides common features like balance check, fund transfer, direct debit, payment, etc. And recently many have added graphs for better visualizations. 

With tablets  taking over market, online application lives. A adaptive and responsive UI will work and attract more customers to login to online banking. But I believe we can build a powerful Online Banking application and over that we build small apps. Customer should have option to install optional mobile apps and also customer should be able to customize online banking application and make it simple.

But if still you are looking for more innovative ideas for online banking, or looking for what new can be done to attract more customers to online banking, or give overall online banking experience an amazing one to your customers, then below is my list of top ten features which can be added to online banking - 

10. Let user set background image
Description: cid:image001.png@01CFEDFF.8DE433A0
(Source - SalemFive Bank)

9. Intelligent Calculator, not like below but smart, along with other tools.
Description: cid:image002.png@01CFEDFF.F4FD5440

8. Allow to upload pictures of beneficiaries.

And display them accordingly in movement list.

7. Integrate CloudIt and other cloud features with banking app

6. Robust search -
Search for transactions using natural language (for example, "Starbucks purchases under $10")”
(Source: logixbanking.com)

5. Graphs for goals -

(Source - mint.com)

4. More categorization, like 102$ payment is 100$ payment and 2$ fee.

(Source: Mint.com)

3. A UI as simple as Simple.com
As we add more graphs and features, we have to keep it simple. And that is tough.

2. A tool, a message as attractive as below -

1.      Virtual Wallet integrated with Calendar

Oct 19, 2014

Still using EJB's: Is EJB dead - Not Yet

EJB - Server side components to hold business logic with lot server provided capabilities.

EJB evolution - 

EJB 1.0 was released in 1998. EJB 1 had basic component features like RMI, deployment descriptor, Security, transaction, along with bean types: Stateful session beans, Stateless session beans, and Entity beans. Session beans hold business logic. Stateless session bean is request scoped, where as Stateful session bean holds conversational state. Entity beans were not just POJO. Entity beans were coarse-grain object(bean) with functionality, data, and dependent objects. Creating Entity bean means fulfill following -
Create remote interface for bean, create home interface for bean, define primary key, implement remote interface methods, implement EntityBean interface and its methods, methods that match home interface methods, deployment descriptor. This was tough.

EJB 2.0 introduced local interfaces and message driven beans. CMP beans were extended with capability to define relationships (CMR). Multiple entity beans were allowed to have relationship.

EJB 2.1 added web service and timer service support. MDBs and EJB-QL were enhanced.

EJB 2.1 and earlier required deployment descriptor.
EJB 2.1 & earlier required two minimum interfaces - home & remote.

EJB 3.0(2006) was giant leap which excluded the need for deployment descriptor, home & remote interfaces, introduced annotations, EJB's are now POJO and expose POJI, Interceptors, and new persistence model JPA 1.0 to supersede Entity bean components.

EJB 3.1 further simplified EJBs and added new features; No-interface view, .war packaging, Singleton session beans, application initialization & shutdown events, timer enhancements, and @Asynchronous in session beans.
Subset EJB 3.1 lite excluded features - remote interfaces, RMI-IIOP interoperability, JAX-WS endpoint, persistent timers, and message driven beans.

The current EJB's have complete capabilities to write server side layer with business logic, transactional, secure, and persistence.

EBJ is used as a business layer in a 3 tier architecture. We can almost everything using EJB and design complete application/business layer using EJB's only.
All we need to know, how easy is to develop a EJB layer, that can process any request of presentation layer. Because EJB is just like any other java class with some annotations. But since it is an EJB, container does lot behind the scene, which we take for granted like -
  • Concurrent EJB access by multiple clients in thread safe manner.
  • Scalable layer with load balancing & clustering.
  • Provide JNDI for lookup
  • Dependency Injection
  • Transaction management
  • Message handling using MDB's
  • Scheduling using Timers
  • Interceptor service
  • Web service support
  • Security

3-tier architecture -

Stateful session bean had bad reputation since its inception and was rarely used. Stateless session bean was the most commonly used EJB. Clients (like servlet) call the Session Bean (stateless) generally remotely and session bean interacts with entities (or entity beans of 2.1 or earlier). Session bean responds back to client. Session bean provided remote & local interfaces. In case a asynchronous call was required, a common approach is to use JMS, send message over queue, and use MDB (Message driven bean) to handle message and respond back asynchronously. So Session bean and MDB's act as facade which manage entities and hold business logic.

A call between Servlet and EJB (session bean) might be remote or local.
We can have several session beans implementing business logic. Each session bean encapsulating a business case, and interaction between session beans is always possible. A session bean can call other session beans and involve one or more entities, all these can be done in single transaction or in multiple transactions based on how we configure. Best part of using EJB's is how container manages transactions.
Transactions involving different resources like (Database, JMS destination, IBM MQ, etc.) can be merged into one so if rollback happens it is done on all resources.

I was working on a project of stock market - middle office in 2009 where we used EJB 3.0 + JPA.
We decided on using UI JSF as presentation, EJB for business layer and any ORM solution.
We went for Oracle, and used ADF for presentation layer and EJB and Toplink as ORM. The development was damn fast and complete middle office was developed in 6 months.
User actions on ADF (UI) are mapped to EJB (session bean) methods, Managed beans (ADF backing beans) are mapped to entities, and its done.
Drag and drop components from pallette, double click action buttons to map to EJB methods, map backing bean to entities, set cache settings in Toplink, and its done. Project is ready.
Possibly you can check below tutorial -
But JSF's are dead already, above design is old and most probably no longer will be used.

Downfall of EJB and Rise of Spring - 

Coming back to EJB's, why EJB's got bad reputation was because of two reasons -
1. Over complicated EJB 2.1 & previous versions
2. Better option - Spring framework in 2004.

Some nicely engineered features of Spring like APO, Inversion Of Control, MVC framework, and integration with Hibernate - changed the complete design of Java EE software's.
Declarative transactions can be applied to any POJO and can be deployed in Tomcat.
Spring+Hibernate ruled the Java EE software architecture from 2005 to 2010 and is still most popular framework.

Reinvention of EJB - 

EJB was reinvented with EJB 3.0, which included annotations, Dependency Injection, and POJO's.
EJB+JPA couldn't replace Spring+Hibernate because EJB & JPA are specification left for vendors (IBM, Oracle, BEA) to implement. But EJB was limited to few types of beans and annotations, compared to full fledged framework Spring. The power of Sping was in beans and its modules like Spring Webflow, Spring MVC, etc. In Spring it was easy to create layer's of beans, inject beans into one another, define scope of beans (session, request, singleton, prototype, etc.), integration with EL, etc. We can create a layer of Controllers beans, layer of Service beans, layer of Business objects, etc. And inject one layer beans into another using DI which means ability to choose at deployment time which implementation to use.

CDI - 
CDI (Context Dependency Injection) was introduced in Java EE 6 and below was mentioned on Oracle site for Java EE -
"Contexts and Dependency Injection (CDI) for the Java EE platform is one of several Java EE 6 features that help to knit together the web tier and the transactional tier of the Java EE platform. CDI is a set of services that, used together, make it easy for developers to use enterprise beans along with JavaServer Faces technology in web applications. Designed for use with stateful objects, CDI also has many broader uses, allowing developers a great deal of flexibility to integrate various kinds of components in a loosely coupled but typesafe way.
The most fundamental services provided by CDI are as follows:
Contexts: The ability to bind the lifecycle and interactions of stateful components to well-defined but extensible lifecycle contexts
Dependency injection: The ability to inject components into an application in a typesafe way, including the ability to choose at deployment time which implementation of a particular interface to inject
In addition, CDI provides the following services:

  • Integration with the Expression Language (EL), which allows any component to be used directly within a JavaServer Faces page or a JavaServer Pages page
  • The ability to decorate injected components
  • The ability to associate interceptors with components using typesafe interceptor bindings
  • An event-notification model
  • A web conversation scope in addition to the three standard scopes (request, session, and application) defined by the Java Servlet specification
  • A complete Service Provider Interface (SPI) that allows third-party frameworks to integrate cleanly in the Java EE 6 environment "
CDI's are so impressive that many feel that CDI is replacement of EJB. 

More about CDI can be read on Oracle websites, but for sure most of the things done using EJB or Spring are possible doing with CDI. But CDI should not be thought as replacement of EJB since because features like timers, asynchronous, declarative transactions, monitoring, and pooling are only available to EJBs. In future CDI might include all aspects currently available in EJB 3.1, but for now a Java EE design will have EJB as a layer with CDI's injected. 

One more major reason of still using EJB's is that  -
"Although an EntityManager injection works also for CDI maanged beans, the beans cannot be directly exposed to the UI layer. 
The EntityManager in a stateless environment can be configured only with the 
@PersistenceContext(type=PersistenceContextType.TRANSACTION) annotation, which is also the default value. Every interaction with the EntityManager requires, therefore, an active transaction; otherwise a javax.persistence.TransactionRequiredException is thrown. Transactions cannot be started in CDI managed beans - out of the box. An EJB solves the problem elegantly, because neither manual transaction management nor realization of CDI extensions is required to start a transaction. A single, no-interface view bean, such as a facade, manages the transactions without any further configuration, frameworks, or manual coding" - Stateless Session bean.
Above is the extract from "Real World Java EE Patterns" book by Adam Bien
And thus our current Java EE design (suitable for all Java EE softwares) will be -
EJB 3.1 + CDI + JPA

© Technology Strategy Architecture and Development | All rights reserved.
Blogger Template Crafted by pipdig