Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 4 Next »

In an effort to modernize our product catalog we  would like to see if we can identify common functionality that we can then wrap up as a Web API.  This will allow us to build the feature set only once, reuse it across all products and make it easier to support all applications as changes would only need to be done in one place.  

When thinking of functionality we should ensure that each services follows a base microservice Architecture and Design, we may not be full microservice based at first but will take steps in the right direction :

  • In a microservices architecture, services are small, independent, and loosely coupled.
  • Each service is a separate codebase, which can be managed by a small development team.
  • Services can be deployed independently. A team can update an existing service without rebuilding and redeploying the entire application.

  • Services are responsible for persisting their own data or external state. This differs from the traditional model, where a separate data layer handles data persistence.

  • Services communicate with each other by using well-defined APIs. Internal implementation details of each service are hidden from other services.

  • Services don't need to share the same technology stack, libraries, or frameworks.

Some of the benefits of this approach are:

  • Independent deployments. You can update a service without redeploying the entire application, and roll back or roll forward an update if something goes wrong. Bug fixes and feature releases are more manageable and less risky.
  • Independent development. A single development team can build, test, and deploy a service. The result is continuous innovation and a faster release cadence.
  • Small, focused teams. Teams can focus on one service. The smaller scope of each service makes the code base easier to understand, and it's easier for new team members to ramp up.
  •  Fault isolation. If a service goes down, it won't take out the entire application, assuming we build in proper resiliency in both API and client ( http://www.thepollyproject.org/  - now built in to .NET CORE https://docs.microsoft.com/en-us/dotnet/standard/microservices-architecture/implement-resilient-applications/ )  


As we identify and build out these service API applications can then leverage pre-existing functionality so developers can create new capabilities and not have reinvent the or learn how to implement functions.  Hopefully we will be able to determine what features are used the most across our entire product portfolio, facilitate discussion, and prioritize implementation of this concept.  

  

Feature NameDescriptionProduct(s)Read \ Write \ LookupDatabase Implementation (CORE tables, custom)  
Vessel SearchService to provide Vessel search lookup. Implements search my name, Official Number, IMO  MSDTSREAD\ LOOKUP 

CORE Tables 

  • cpscsw.vessel@cpscs v, cpscsw.s_vessel_type@cpscs
  • SIRS.VW001_SIRS_SRCS_VESSEL@SIRS
  • scvls.tr11_xref_vessel_vessel_type@scvls t, scvls.tr05_vessel_type@scvls v



  • No labels