DGS eGovernance - Too many of incompetent Cooks spoiling the broth

Sub: DGS eGovernance - Too many of incompetent Cooks spoiling the broth - Removal of Edit Tab in the Ship Profile Module - Unsound technical coordinates brought to the notice of DGS eGovernance - Regarding.

Dear Sir,

At the outset, I take this opportunity to welcome you to the Indian Maritime Administration, the right citadel for ship safety and seafarers' rights. And I am sure under your able stewardship, theDirectorate will reach logical heights in reaching the pinnacle of glory in achieving the motto of safer ships, cleaner oceans and happy seafarers. As the original architect of the DGS eGovernance Project during 2005-08, I have unforgettable memories of having rolled out the first seafarers’ module before time in February 2008. And it was the first-ever seafarers module brought out boldly online in the world by the National Administration. Since then few nations have followed suit though the Indian eGovernance module for seafarers will continue to be the best, despite concerted efforts of a few at the helm of affairs, whose IT expertise never reaches the Notepad or any other ASCI Editor for hardcore programming ever since they came to hear of progamming to wither down the technical soundness of the modules by ‘Cut and Paste’ approach however inappropriate in the context of the fast improving Java technology after its takeover by Oracle in 2009 and it merger with the RDBMS, on whose edifice the DGS eGovernance stands. What some inane authority with no technical knowledge tries to tweedle with the eGovernance is tantamount to throwing the spanner in the works for whom the fulcrum of the issues lies in the Edit button of the Profile module of the RPS System. In their own wisdom they thought that removal of the Edit button will scare away all the vices of the system, not aware that core modules of a system are the cornerstones of the Java architecture with a hundred and one and the whole backend including the RDBMS on which the module rests will collapse like a castle of cards. These super-users - if you want to know who they are, consult the developers of the system - in their attempt to turn over a new leaf have removed the fulcrum of the module. They need to know HTTP protocol and Web Servers are stateless, what it means is that for web servers every request is a new request to process and they can’t identify if it’s coming from a client that has been sending requests previously. But sometimes in web applications, one should know who the client is and process the request accordingly. The eGovernance application should identify an RPS Provider from a seafarer who is sending the request to add a file in which file the item has to be added or who is sending a download request so that it can charge the amount to the correct client. If this basic security is not embedded in the server application the privacy issues of all the stakeholders namely ship owners, RPS Providers and Seafarers would have been compromised. The rule benders have no idea Session is a conversational state between client and server and it can consist of multiple requests and responses between client and server. Since HTTP and Web Server both are stateless, the only way to maintain a session is when some unique information about the session (session id) is passed between server and client in every request and response.

There are several ways through which a Java Server provides a unique identifier in request and response. 

User Authentication – This is the very common way where an RPS user can provide authentication credentials from the login page and then we can pass the authentication information between server and client to maintain the session. This is not a very effective method because it won't work if the same user is logged in from different browsers.

HTML Hidden Field – We can create a unique hidden field in the HTML and when the user starts navigating, we can set its value unique to the user and keep track of the session. This method can’t be used with links because it needs the form to be submitted every time a request is made from client to server with the hidden field. Also it’s not secure because we can get the hidden field value from the HTML source and use it to hack the session.

URL Rewriting – We can append a session identifier parameter with every request and response to keep track of the session. This is very tedious because we need to keep track of this parameter in every response and make sure it’s not clashing with other parameters.

Cookies – Cookies are small pieces of information that are sent by the web server in response header and get stored in the browser cookies. When a client makes a further request, it adds the cookie to the request header and we can utilize it to keep track of the session. We can maintain a session with cookies but if the client disables the cookies, then it won’t work.

Session Management API – Session Management API is built on top of above methods for session tracking. Some of the major disadvantages of all the above methods are:

Most of the time we don’t want to only track the session, we have to store some data into the session that we can use in future requests. This will require a lot of effort if we try to implement this.

All the above methods are not complete in themselves, all of them won’t work in a particular scenario. So we need a solution that can utilize these methods of session tracking to provide session management in all cases.

That’s why we need a Session Management API and J2EE Servlet technology that comes with a session management API that the system can use.

The eGovernance Modules for the RPSL Companies are very unique, covering the whole gamut of DMS, possibly using the Crystal Reports - unless you improved upon it - as was originally architectured by me as the Sole Architect of the eGovernance System, as I then was. Though I would have preferred a more intelligent DMS with proper validations meanwhile using the Session tracking Servlets or other mechanism that servlets use to maintain state about a series of requests from the same user, originating from the same browser, across the same period of time, when Sessions are shared among the servlets accessed by a client. Everything was going hale and healthy, fine as a fiddle, until someone in his twisted, paranoiac mind, possibly good at policing with no idea how a servlet functions - especially when a Truncated class file at java.lang.ClassLoader - behaves when the remainder of the deprecated Servlet - is killed before parsing of XML whitespace   TLD function signatures - thought up in his great wisdom to remove the Edit Tab on the web application Frontend, as if it were the root cause of all the mailaises in the Indian Ship Crewing System.  And you did exactly that, making the Truncated class file stand up like a sore thumb, to cause the java.lang.ClassFormatError: And then comes the disaster.

In the earlier version of the eGovernance system we had some flexibility as a matter of some practicable gap from the time of upload of new ship particulars inasmuch as the text could be uploaded first and saved followed by the upload of the respective certificates such as P&I, MLC, DMLC and so on using the Edit button. If any details are left out or a  fresh certificate was required to be uploaded it was possible using  the Edit Tab against each vessel. This was all the more needed as the  session controls of the server allowed only short sessions and  uploading of a certificate, which took a lot of time with inherent  validations, though most have been dispensed with, was not accepted by the server as an ‘activity’ and we  were logged off due to ‘inaction’ which was not true. Hence first we  uploaded the text data. And one by one uploaded the heavy pdf files one by one so as not to upset the session controller servlet on your Java Application Server.  This system has been modified for reasons not gone into or not notified / available and now there are only view and delete buttons. The change obviously is technically unsound, not exactly user-friendly. The Ship particulars once entered cannot be deleted also so reloading is also not possible. All these new procedures have been causing considerable inconveniences in uploading of ship documents and subsequent sign on protocols.

As you might see, I had entered the text details of the last ship MV Kabul and saved. But when I tried to upload the certificates it had been rendered inadmissible since the Edit link was removed since.

Since the earlier name of MV Gulliver has changed to Kabul, it has to be shown as a change of ship only. Accordingly a few of my seafarers who had  boarded MV Gulliver had to be shown as shifted to MV Kabul from 25th February 2020 but had to  be signed off from Gulliver itself on 13th March 2020 without incorporating the ship  changes. They are totally aggrieved and the owner is frustrated with the non-execution of the change of ship in the e-Governance records of the DGS.

Hence it is humbly requested to either get the old system of uploading of the certificates through the system restored or work out a technically workable alternative. For the time being the following certificates may kindly  be got uploaded in the system and the ship changes in respect of the seafarers shown in the attached excel sheet may kindly be got shown as  “Changed ships from MV Gulliver to MV Kabul on 22nd February and  signed off from Kabul on the respective dates. In given circumstances it is DG Shipping responsibility to make

change of ship effected for these seafarers.

The following certificates/ documents are attached.

P&I

MLC

MLC 252

MLC 4.2

DMLC 2

The Excel Sheets containing the names of the affected seafarers.

The following suggestions are made to improve upon the technical coordinates of the file uploading system.

Supporting file uploads is a very basic and essential requirement for many web applications. In the RDBMS  versions of the Servlet specification, implementing file upload required the use of external libraries or complex input processing. The Java Servlet specification helps to provide a viable solution to the problem in a generic and portable way. Java Servlet technology now supports file upload out of the box, so any web container that implements the specification can parse multipart requests and make mime attachments available through the HttpServletRequest object. Even   the validations can be embedded behind the JSPs in lieu of the outdated JavaScripts in a Servlet Container.

The javax.servlet.annotation.MultipartConfig, could be used to indicate that the servlet on which it is declared expects requests to be made using the multipart/form-data MIME type. Servlets that are annotated with @MultipartConfig can retrieve the Part components of a given multipart/form-data request by calling the request.getPart(String name) or request.getParts() method.

The following optional attributes may also be considered.

location: An absolute path to a directory on the file system. The location attribute does not support a path relative to the application context. This location is used to store files temporarily while the parts are processed or when the size of the file exceeds the specified fileSizeThreshold setting. The default location is "".

fileSizeThreshold: The file size in bytes after which the file will be temporarily stored on disk. The default size is 0 bytes. 

MaxFileSize: The maximum size allowed for uploaded files, in bytes. If the size of any uploaded file is greater than this size, the web container will throw an exception (IllegalStateException). The default size is unlimited.

maxRequestSize: The maximum size allowed for a multipart/form-data request, in bytes. The web container will throw an exception if the overall size of all uploaded files exceeds this threshold. The default size is unlimited.

You can also use a Support Case Manager (SCM) file upload method as the preferred and most secure option for uploading files to cases.

Files transferred by using this option could be encrypted in transit and constrained to a size of 250 GB. The communication channel between the customer’s computing device and the router is encrypted. Files uploaded through SCM are immediately linked to the associated case and stored in an encrypted format. Hopefully you are using Cisco Routers for transmission of the image and doc data from the customers’ computers, in which case they might have a suitable firmware for handling these protocols.. If not you’d better do it.

To make a system work, you need to work from the ‘mind of the computer’, which we did while designing the system. The technical hardcoding was done in our presence, step to step monitoring how the frontend and backend ‘behaves’. This was possible as the users and developers worked in close physical proximity. As long as I was there in DG Shipping, as the Technical Coordinator of the eGovernance System, I had established and run the datacenter on the First Floor of the then Jahaz Bhavan and did not agree to outsourcing to the hermits.

It is high time the DG Shipping installed its IT Cell as it existed during my time. It is twelve years since the Governance Cell runs without competent IT People.

Finally, whenever any brilliant idea strikes your mind like the one that comes to the BEST bus driver to jerk the brakes to make the commuters crash their head on the bulkheads or to the traffic constable hiding under a tree to catch a traffic offender to slap him with a ticket and sometimes the unprintable instead of regulating the traffic from the traffic island, you are requested to call a workshop for exchange of thoughts. In our days, when I happened to be the DDG (eGovernance), there used to be an Interface with the industry that met every month as a sounding board to consider, and debate on the eGovernance modules under roll out or enhancement every month. Nowadays you seem to be more inclined towards policing rather than training, auditing more than educating, fault-finding rather than facilitating. DGS did conduct a onesided workshop, all muscles and muzzles in the midst of a possible Covids 19 disaster. Less said the better.

Technical inadequacies apart, this kind of sudden, unnotified, abrupt changes do lead to turmoil and uncertainties in the Shipping Industry, throwing the seafarers into a sea of woes and worries, as also causing possible transfer of the manning  contracts to countries of cheaper maritime labour such as Philippines, Bangladesh and Sri Lanka. Better coordination between DG Shipping  e-governance and the Industry, it is expected, will go a long way to ensure better working conditions, continued employment and better acceptability for Indian seafarers, regulatory and smooth monitoring of seafarers service records, ship details, ship changes onboard.

Let my having architectured the first ever successful eGovernance module for Indian maritime administration as the then Architect and Technical Coordinator of the Program and running it successfully for three years be my excuse for encroaching upon your valuable time.