Cloud commercial object-oriented business application for a paid toilet or thinking about architecture
Colleagues, all a good day. On sql'e someone created a joking topic, but the moderators cut it at the root. However, this topic launched a certain thought process, the results of which I would like to share with you. However, unfortunately, she gave birth to more questions.
So, deleted post:
And some of my thoughts that might be interesting to someone.
Let's decompose the architecture into 3 main components:
* this is the front (what the client sees, with what he works)
* application server (responsible for processing business logic)
* database (where data is stored)
It is also necessary to take into account two important points: the accounting system is not an end in itself. It is impossible to just keep all the data in such a way - they are for some reason needed. The question of what data we will store, for which they are needed:
* for conducting financial activity of the enterprise
* for the provision of regulatory reporting to regulatory authorities
* to study the needs of the client and the ability to satisfy them as much as possible (analysis of the supplied products and services, the study of behavioral models, forecasting demand based on historical data)
Therefore, we store the data that we will need in the future - for management and accounting and business intelligence. Also, for accounting and personnel records it is necessary to keep records of a number of strict reporting documents - checks / acts / accounts / orders, etc., but some of these functions belong to the back office and can be maintained in a separate system.
However, it is sometimes necessary to provide for the recording of transactions from the front-system (checks, authorization to perform operations with a bank card, etc.). And this sometimes requires a separate series of decisions on integration with payment systems and / or POS systems, as well as ensuring the security of such operations and restoring the history of operations in case of failure.
Thus, we come to important things - this is a backup, which, in principle, is possible by standard means of DBMS, and security.
Let's return to architecture:
* application server (responsible for processing business logic)
* database (where data is stored)
The question is which of these layers is necessary to ensure security and access separation?
There are 3 approaches:
1. At the application server level
We give only a few roles, and the Application Server (AOS) under them already addresses the database, the separation of roles to the database is sewn up in the AS, the distinction between the data / record level is maintained by means of AOS.
Pros: Easy administration. There is no strong dependence on the DBMS.
Cons: Business analytics usually clings directly to the database, and sees everything, without taking into account restrictions at the level of the joint venture. Implementing business analytics access through a joint venture is very nontrivial and can weigh heavily on a joint venture.
2. At the DBMS level
All user roles, access level, delimitation by data / record level are set at the DBMS level. Thus, it is necessary to finish the application server heavily, in order not to complicate the system administration: the administrator was configured in the workplace, and the roles were applied at the database level.
Pros: BI / reporting system can cling directly to the database under a particular user, there is no need for additional control of access rights
Cons: The complexity of implementation, since the implementation of this mechanism is highly dependent on the use of a particular DBMS.
The complexity of testing - zeroes fall out, and you need to understand why this is: this is a mistake in the application logic or in setting up access rights. Perhaps duplication of administration - brought the user, hooked business logic to it, and then tweaked the rights in the database.
3. Mixed
We give only a few basic roles, and a number of "typical", the difference in access to which differs at the level of filters.
Application server (AOS) for a number of main roles - refers to the database, the separation of roles to the database - is sewn into the SP
For “typical” - AOS comes with a restriction on each role, additional restrictions on data / at the level of records are maintained by means of the DBMS using filters.
With all the advantages - ease of administration, simple configuration of BI-systems (in fact, you have to duplicate the filters for the user in the DBMS and BI system), this is the most time-consuming method of implementation.
So, if it's easy to decide on the front - we live in the age of mobility, therefore, we need to foresee that our application will be opened from any kind of devices. It means that it will be necessary to write “thin clients” under iOS / Android / Win / Linux, or simply to write a front that will open in any environment — for example, from any browser. Since Java is now an uncertain situation, someone refuses the JVM, someone is prohibited by security policies, I would look in the direction of HTML 5 (6 ...). Although, again, the question is, your application will look on the monitor 24 "and on the phone 4" - here either autoscaling, or client substitution (display only the main one, or hit screens / elements) or again - write thin clients ...
Okay, let's pretend we’ve chosen HTML5. Ok, even Grid can be implemented.
Now to the DBMS. The main ones are MS Sql and Oracle, and there’s also a trend with Open Source, which means that PostgreSQL should not be forgotten. If you intend a large number of distributed installations, then you need to look at Hadoop / Mongo, etc., but these are not relational DBMS that solve certain tasks, are you not a search engine or a social network going to do? Let us, for the time being, stop at the first 3, and better - at least we will begin with Or we will foresee a certain independence from the DBMS, leaving only the inherent to all DBMS functions.
What is the business logic implemented on? What will be the connecting element between the browser and the database?
But an open question. I would listen to colleagues myself
If we prefer Oracle technology, then oracle apex. If we grow, then Fusion Middleware is in full growth + WebLogic
If we lean with Open Source, then Apache Tomcat. Yes, if the installation is large, then there would also be a load balancer, such as PgBouncer and Nginx. If distributed, then there is also a Pacemaker cluster resource manager, messaging between Corosync cluster nodes, etc.
If a supporter of technology MS - then the Studio and forth. Alas, I will not prompt the finished AOS in their stack. Only third-party framework type K2.
We collected an application server, integrated with the client bank (possibly using the Apache ActiveMQ guaranteed message delivery broker), established integration with the back office, it's time to think about business analytics, but this is a separate song.
So, colleagues, who thinks about the typical architecture? Which application server to use, on what to write business logic?
Who thinks what?
With respect,
George
So, deleted post:
pisun
Cloud commercial object-oriented business application for paid toilet
I have an average business - three paid toilets. I believe that the time has come to automate the business processes of my business with the help of commercial object-oriented cloud business applications.
What approaches, methodologies, frameworks need to be used to develop cloud-based commercial object-oriented business applications for pay toilets?
How many lines of a commercial code should a cloud-based commercial object-oriented business application for a paid toilet be?
')
What are the ready-made cloud-based commercial object-oriented business applications for pay toilet?
And some of my thoughts that might be interesting to someone.
Let's decompose the architecture into 3 main components:
* this is the front (what the client sees, with what he works)
* application server (responsible for processing business logic)
* database (where data is stored)
It is also necessary to take into account two important points: the accounting system is not an end in itself. It is impossible to just keep all the data in such a way - they are for some reason needed. The question of what data we will store, for which they are needed:
* for conducting financial activity of the enterprise
* for the provision of regulatory reporting to regulatory authorities
* to study the needs of the client and the ability to satisfy them as much as possible (analysis of the supplied products and services, the study of behavioral models, forecasting demand based on historical data)
Therefore, we store the data that we will need in the future - for management and accounting and business intelligence. Also, for accounting and personnel records it is necessary to keep records of a number of strict reporting documents - checks / acts / accounts / orders, etc., but some of these functions belong to the back office and can be maintained in a separate system.
However, it is sometimes necessary to provide for the recording of transactions from the front-system (checks, authorization to perform operations with a bank card, etc.). And this sometimes requires a separate series of decisions on integration with payment systems and / or POS systems, as well as ensuring the security of such operations and restoring the history of operations in case of failure.
Thus, we come to important things - this is a backup, which, in principle, is possible by standard means of DBMS, and security.
Let's return to architecture:
* application server (responsible for processing business logic)
* database (where data is stored)
The question is which of these layers is necessary to ensure security and access separation?
There are 3 approaches:
1. At the application server level
We give only a few roles, and the Application Server (AOS) under them already addresses the database, the separation of roles to the database is sewn up in the AS, the distinction between the data / record level is maintained by means of AOS.
Pros: Easy administration. There is no strong dependence on the DBMS.
Cons: Business analytics usually clings directly to the database, and sees everything, without taking into account restrictions at the level of the joint venture. Implementing business analytics access through a joint venture is very nontrivial and can weigh heavily on a joint venture.
2. At the DBMS level
All user roles, access level, delimitation by data / record level are set at the DBMS level. Thus, it is necessary to finish the application server heavily, in order not to complicate the system administration: the administrator was configured in the workplace, and the roles were applied at the database level.
Pros: BI / reporting system can cling directly to the database under a particular user, there is no need for additional control of access rights
Cons: The complexity of implementation, since the implementation of this mechanism is highly dependent on the use of a particular DBMS.
The complexity of testing - zeroes fall out, and you need to understand why this is: this is a mistake in the application logic or in setting up access rights. Perhaps duplication of administration - brought the user, hooked business logic to it, and then tweaked the rights in the database.
3. Mixed
We give only a few basic roles, and a number of "typical", the difference in access to which differs at the level of filters.
Application server (AOS) for a number of main roles - refers to the database, the separation of roles to the database - is sewn into the SP
For “typical” - AOS comes with a restriction on each role, additional restrictions on data / at the level of records are maintained by means of the DBMS using filters.
With all the advantages - ease of administration, simple configuration of BI-systems (in fact, you have to duplicate the filters for the user in the DBMS and BI system), this is the most time-consuming method of implementation.
So, if it's easy to decide on the front - we live in the age of mobility, therefore, we need to foresee that our application will be opened from any kind of devices. It means that it will be necessary to write “thin clients” under iOS / Android / Win / Linux, or simply to write a front that will open in any environment — for example, from any browser. Since Java is now an uncertain situation, someone refuses the JVM, someone is prohibited by security policies, I would look in the direction of HTML 5 (6 ...). Although, again, the question is, your application will look on the monitor 24 "and on the phone 4" - here either autoscaling, or client substitution (display only the main one, or hit screens / elements) or again - write thin clients ...
Okay, let's pretend we’ve chosen HTML5. Ok, even Grid can be implemented.
Now to the DBMS. The main ones are MS Sql and Oracle, and there’s also a trend with Open Source, which means that PostgreSQL should not be forgotten. If you intend a large number of distributed installations, then you need to look at Hadoop / Mongo, etc., but these are not relational DBMS that solve certain tasks, are you not a search engine or a social network going to do? Let us, for the time being, stop at the first 3, and better - at least we will begin with Or we will foresee a certain independence from the DBMS, leaving only the inherent to all DBMS functions.
What is the business logic implemented on? What will be the connecting element between the browser and the database?
But an open question. I would listen to colleagues myself
If we prefer Oracle technology, then oracle apex. If we grow, then Fusion Middleware is in full growth + WebLogic
If we lean with Open Source, then Apache Tomcat. Yes, if the installation is large, then there would also be a load balancer, such as PgBouncer and Nginx. If distributed, then there is also a Pacemaker cluster resource manager, messaging between Corosync cluster nodes, etc.
If a supporter of technology MS - then the Studio and forth. Alas, I will not prompt the finished AOS in their stack. Only third-party framework type K2.
We collected an application server, integrated with the client bank (possibly using the Apache ActiveMQ guaranteed message delivery broker), established integration with the back office, it's time to think about business analytics, but this is a separate song.
So, colleagues, who thinks about the typical architecture? Which application server to use, on what to write business logic?
Who thinks what?
With respect,
George
Source: https://habr.com/ru/post/281158/
All Articles