1

I have created a real-time GPS tracking web-based system using Java Servlets as a backend solution whereas the front end is using javascript with ajax requests and WebSockets. (Both the front and backend are operating together as a Web application)

Basically, the system is a web interface that shows at real-time vehicles on google maps and also users can build reports for past events based on input data like start timestamp, end timestamp, vehicle id and a bit more calibration staff.

So currently everything is on the same backend - the realtime logic and the logic of the reports (currently there are 50+ reports the user can choose from)

Due to the complexity of the reports and realtime data serialization, most of the database data associated with users and vehicles are loaded in memory.

However, from time to time (twice a day) there needs to be made improvements and or patch some bugs (for example some report logic needs to be changed a bit, or the front-end UI needs to be fixed, or the way the emails are sent needs to be modified for some clients) so I have to kill the users' sessions and deploy the fix but all this introduces downtime.

That's why I am considering dividing the system into multiple services and each of them to be on an independent server:

One independent service/server for the real-time data fetching and serialization.
One independent service/server for reverse geocoding.
One independent service/server for calculating and caching if current latitude/longitude is inside urban area or on a particular speed road.
One independent service/server for daily reports.
One independent service/server for event-based reports
One independent service/server for email and other notifications.
One independent service/server for tachograph data downloading and uploading to FTP.

and so on.

This way if some of the services need to be patched, fixed or upgraded I won't need to stop everything and kill the users' session.

(Please have in mind that there are daily requirements to change or introduce some logic in some of the services due to thousands of private clients who pull the strings and tell what should be made)

However, I have some objects like CustomDateTime, Vehicle, MarkedArea, DynamicPOI, ClosedGeoCurve, FuelFlowMeter, Canbus, GPSDeviceFirmware, UserSerializationPermissions, DistanceCalculationMethod and so on, that are heavily used across the system so if I divide the system on services and each of them is hosted on independent physical server machine I will need to have these Java objects on each of them and each time I introduce a new field, method and/or business logic to some of the classes I will have to deploy them again on each of the servers.

That's why I am still investigating what would be the best approach to handle this division and i will be more than happy if some of you show me the right direction using JEE architecture.

Thank you in advance.

  • 1
    Did you check for other questions here? Like [this](https://softwareengineering.stackexchange.com/questions/325614/microservice-architecture-shared-domain-models) and [this](https://softwareengineering.stackexchange.com/questions/305469/microservices-architecture-and-bounded-contexts)? If you have to update all services at once when a single property is added to a model then you're not gaining any benefit from microservices, in fact you're only making your job more difficult. – Dan Wilson Jan 18 '20 at 13:03

1 Answers1

2

I suggest to focus on persistence instead of dividing system:

  1. Try to use some network cache like Ehcache ( https://www.ehcache.org/ ) or fast non-relation database ( MongoDb ) instead of loading data into memory. This will allow to boot your system without spending time on filling in-memory data.
  2. Setup users session persistence, each JEE Server allows that. Persistent sessions will allow to keep users logged in between application restarts.
  3. If possible - move frontend part outside of web application package and deploy directly on web server. So users will always see web interface loaded and backend restarts will look as short network failures.

In summary you'll have much faster deployments with almost zero-downtime for end users.

If you explicitly need to split system into services, then start with pure technical: email delivery, PUSH/SMS notifications ( if present ). Such logic could be easily extracted from application and moved to dedicated service.