Business and Technical Solution

Why a National e-Service Bus?

Different government organizations have already developed software to digitalize their information and data in isolated ways that are not interoperable for use by other organizations, causing huge monetary involvement to prepare the same information and data. The National e-Service Bus will remove this duplicity and will provide seamless data flow between organizations. The National e-Service Bus, to facilitate citizen service delivery, is a crucial part of the BNDA framework.

Electronic services, or e-services, are a critical component for establishing e-Government. All government entities under the Digital Bangladesh vision are currently engaged in providing e-services to the citizens and businesses. E-services are the final outcome from the BNDA. E-services would include G2G, G2C, G2B, or Government-to-Employee (G2E). However, the data exchange, interoperability between e-services and other Government of Bangladesh agencies, data centers, and third-party systems require complex integration and orchestration to deliver required data. The National e-Service Bus plays a key role.

Due procedures and guidelines have been established around the governance to ensure robust and standardized controls are being followed by the BNDA working team.

What is the National e-Service Bus?

What is the National e-Service Bus?

The National e-Service Bus is a software-driven middleware platform, which is being developed to enable online services, sharing of information and data of ministries, departments, and directorates to ensure interoperability and an end user’s easy access to it. The National e-Service Bus is connected/integrated with various government databases and systems. The National e-Service Bus acts as a hub for foundation building block services (such as the citizen authentication service, birth registration verification service, and mobile number validation service, etc.) of the BNDA architecture as-a-whole. The online system is deployed in a clustered and load-balancing environment of the National Data Center (NDC) to ensure its scalability and 24/seven availability.

This is a critical component in the interoperability architecture domain and is key to ensuring the seamless exchange of information and services for the Government of Bangladesh. It is a conduit for channeling and routing information requests to and from various government agencies. The National e-Service Bus is based on an SOA paradigm. It is a gateway for accessing government data repositories such as the National Identity (NID), the Birth and Death Registration System, Government Employee Database, etc., and acts as a translator between different systems.

The National e-Service Bus and Ecosystems

Figure 2: The National e-Service Bus and Ecosystems (Source: link:referenced-documents#refbnda[BNDA])
Figure 2: The National e-Service Bus and Ecosystems (Source: BNDA)

Project Management

A project management plan was prepared and finalized following standard project management practices. An architecture review and compliance check were addressed as part of the project governance. This was followed by requirements of gathering, consolidation, analysis, clarifying expectation details from senior management, brainstorming sessions, and depicting probable scenarios/use-cases, etc. The test engineer started to prepare a test plan and test cases for testing the system exhaustively. The target system design and integration architecture were prepared, reviewed with stakeholders, and the timeline was adjusted accordingly, based on skilled resources across participating systems of engagement and systems of record. System and integration testing was conducted as per the plan, and bugs/defects identified from testing were addressed by the deployment team before piloting.

The system implementation plan and design were executed using an iterative stakeholder feedback mechanism, architecture review, and architecture requirements. The National e-Service Bus was piloted for four to five months. Based on user experience, operational experiences, and stakeholder feedback, the system was upgraded/modified and taken to live operation in June 2017.

The system deployment was accomplished in line with the BNDA Technology Architecture guidelines. The Apache® web server and Tomcat® container were selected as they implement Open Standards. The NDC’s infrastructure and virtualized environment was used to align with the “shared use of resources” principle. To align with security architecture standards, it is deployed in a private Local Area Network (LAN) of an NDC, as it does not have any public interface and it sits in the middle during data exchange among applications/services.

The project review process:

  • Conducted periodic status review meetings with the project director

  • Project findings and outcomes are shared in the Project Implementation Committee (PIC) meetings, headed by the organization head

  • Summary updates and progress is shared in the Project Steering Committee meetings, presided over by the secretary of the ICT Ministry

  • Apart from the above, it was communicated to various stakeholders via meetings, workshops, seminars, and milestone meetings, etc.

Key Principles and Decisions

The BNDA Application Architecture allows several integration components to enable citizen services, e-services, and government application systems to connect and exchange data and information when required.[1] Best practices of modern and futuristic reference architecture recommend loosely-coupled architecture. The National e-Service Bus supports loosely-coupled architecture and supports the TOGAF Standard reference architecture.

The national Enterprise Architecture and its components are developed based on the principle of standardization and simplification shown below:

  • Improving governance

  • Cooperation and collaboration

  • Cost optimization

  • Standardization

  • Reusability

  • Mature information systems

  • Comprehensive development

The National e-Service Bus was based on the following two primary Architecture Principles:

  • Sharing of Common Services

    Reduce duplication of effort and maximize efficiency by sharing services and data.

  • Reusability

    Government processes for management of information should highlight the reusable processes that can be adopted in other government functions.

Table 1: Two Key Architecture Decisions

Topic Description

Choosing the TOGAF Framework

We selected the TOGAF Standard/Enterprise Architecture category for this submission. We followed the BNDA framework in the customization, maintenance, and operating the National e-Service Bus. The BNDA framework is established to meet the growing demands of the public and private sector organizations and citizens by providing integrated and interoperable e-services in a more secure, reliable, and efficient manner using ICT. The BNDA addresses various areas in alignment with TOGAF framework architectures: Business, Data, Application, Technology, and Security.

Sectoral Service Bus

There are hundreds of citizen services, e-services, and government application systems in Bangladesh. If we consider the wide scale usage of the National e-Service Bus, it may create a huge workload due to integration scenarios among citizens service, e-service, and government application systems. It may result in scenarios that are hard to manage in real time. That is why the BNDA team recommended to use a small-scale service bus for ministry and department needs. In that case, the National e-Service Bus will cater only to important and popular citizen services and government application systems. A clause was included in the BNDA guideline regarding a sectoral service bus, so that the ministry and departments can deploy their own service bus (small-scale).

The Service Bus Ecosystem

The Service Bus Ecosystem is deployed as a private server inside the NDC network. It has a one-to-one integration with each provider and consumer. With a single integration consumers get all sorts of government services in a similar manner to build their systems over it. The BCC expects the Application Programming Interface (API) from the system/database owner organization. The API can be either Representational State Transfer (RESTful) web service or Simple Objects Access Protocol (SOAP) format. The system/database owner will be responsible to develop and maintain the API.

Figure 3: Service Bus Ecosystem Architecture (Source: BCC)
Figure 3: Service Bus Ecosystem Architecture (Source: BCC)

Core Features of the National e-Service Bus

Figure 4: Core Features of the National e-Service Bus (Source: BCC)
Figure 4: Core Features of the National e-Service Bus (Source: BCC)

Core Features

  • Front End: consists of API Publishing and API Developer Interface facilities

  • API Publishing and Management: enables API creators to develop, document, scale, and version APIs, while also facilitating more API management-related tasks such as publishing API, monetization, analyzing statistics, and promoting

  • Developer Portal: provides a collaborative interface for API publishers to host and advertise their APIs and for API consumers to self-register, discover, evaluate, subscribe to and use secured, protected, authenticated APIs

  • API Gateway: secures, protects, manages, and scales API calls

    The API Gateway intercepts API requests, applies policies (such as throttling) and security using handlers and manages API statistics.

  • Key Management: manages all clients, security, and access token-related operations

    The API Gateway connects with the Key Management to check the validity of Open Authorization tokens, subscriptions, and API invocations.

  • Traffic Management: helps to regulate API traffic, make APIs and applications available to consumers at different service levels, and secure APIs against security attacks

  • Monitoring and Analytics: provides a host of statistical graphs, an alerting mechanism on pre-determined events and a log analyzer

  • Highly available infrastructure and deployed behind private LAN

  • Supports publishing SOAP, REST, JavaScript Object Notation (JSON), and eXtensible Markup Language (XML) style services as APIs

  • Supports multi-tenancy, API routing, transformation, message mediation

Infrastructure Details

  • Business process manger

  • Message mediation

  • Two clustered servers for an API manager and governance registry

  • Two clustered servers for an identity server

  • One server for a data analytics server

  • Load balancers for an API manager, identity server

  • Database servers for an API manager, identity server, and data analytics server

  • TPS capacity: 5,000 API calls per second

Tools and Technology Used

  • The BNDA framework and portal, to follow/implement Enterprise Architecture practices

  • WSO2® API manager, to act as an API Gateway

  • WSO2 Enterprise Integration, to consolidate API Gateway and identity management

  • WSO2 Identity and Access Management, to manage identity and access control

  • WSO2 Analytics and Stream Processing, to get insight on API usage and data exchange

  • Apache web server and Tomcat container

  • MySQL®, for storing data and Hadoop® (for analytics data)

  • Ballerina®, for custom scripting

  • Virtual Machines (VMs) with CentOS™

  • Java®, Spring Boot™, Python®

Authentication and Security

The National e-Service Bus uses the same authentication and authorization process set up by the BNDA, and uses a multi-layer security structure for ensuring security. It runs on a private server situated in the NDC. To avail the benefits of the National e-Service Bus, a client (application, user, etc.) has to establish connectivity with our NDC and then an authorization header token with a valid Base64 encoded username and password is provided to the client. This token can be enabled/disabled and also can add usage limitations to it.

The National e-Service bus resides behind the firewall in the private LAN of NDC; no real IP is used for security concerns. Systems and services need to undergo security testing by the Software Quality and Testing Center (SQTC) and Computer Incident Response Team (CIRT) before connecting to the National e-Service Bus. It is kept under proactive surveillance of BCC CIRT activities. It has traffic throttling capability, so it can sustain itself in case there is a flood of requests from consumer applications and services. Note that due to data privacy concerns, the National e-Service Bus does not cache any data/information returned from the API response.

Checklist for Integrating with the National e-Service Bus

  • Establish an agreement with the BCC

  • Establish connectivity with the NDC

  • Network permission from the NDC

  • Meeting/demonstration on API specification

  • Test token for API integration and testing

  • Usage approximation for setting usage limitation

  • Provide live token with usage limitation to the client