We have guided by the following goals and principles:
- Microservices architecture – all PetroVisor functionalities are grouped and provided as set of small services. Each service is independent and replaceable.
- Using Microsoft stack of technologies – to leverage existing development experience and suit client deployment environment. This includes (among other) the latest features of .NET like parallel and asynchronous execution.
- Using client library as ‘façade’ for remote access - applications which are using PetroVisor API are working with local client library which is encapsulates everything related to remote services access. Thus, applications are independent of PetroVisor server host location, used communication and security types.
- No direct database access – all the data must be read/written through use only of PetroVisor API services. Thus, applications which are using PetroVisor API are independent of data storage location, structure or its physical type.
- Data access layer caching - all PetroVisor objects (except production data) have to be cached in memory to improve the performance.
- Simple stateless operations – PetroVisor API provides only simple atomic stateless non-application specific operations; thus applications can build their own complex business logic using simple operations provided by PetroVisor.
- Scalability and performance improvement through new technology – improved performance on Multi-Core systems by leveraging latest .NET features
- Cross platform
- Multi-Core parallel execution
- Asynchronous processing
- Net, Blazor and latest web technologies
- Domain Specific Language P# – additional higher level alternative to PetroVisor API for non-programmers. The language should use the same domain business objects and operations as PetroVisor API, but allow to express them in much simpler form for non-programmer users.
- Data-driven Language – the domain specific language should focus on definition of data objects, their contexts and expressions rather than to be a set of instructions to execute. PetroVisor engine automatically executes all required PetroVisor API calls during evaluation of defined data objects and expressions using specified context.
- Minimal third-party dependencies – PetroVisor implementation should be based only on public available industry standard components and technologies.
Architectural Constraints
The following constraints have been obeyed:
- No periodic queries for database table updates - all periodic scanning of the database for updates need to migrate onto the Publish/Subscribe pattern.
- Keep PetroVisor public interfaces intact - existing code base is relying on public PetroVisor API– so changes must be applied only to implementation of PetroVisor API.