Agree with package and module naming. I just thought that Service is a self-suffucient component and provides high-level API to user/other components/services (e.g. RaftService to TableService). Manager is internal component - a logical brick of the Service (e.g. RaftGroupManager or TableSchemaManager, TableAffinityManager), it is not self-sufficient as affinity or schema make no sense without the table. Processor is just helper-component of the Service that routes messages, executes async tasks, manages subscriptions and implements some secondary functions.
On Tue, Mar 30, 2021 at 11:24 AM Alexey Goncharuk < alexey.goncha...@gmail.com> wrote: > Hello Alexander, Igniters, > > I support the suggestion, we need to work out some ground rules to have a > consistent naming convention. Agree with having at most one component per > project module - this requirement may turn out to be too strict in the > future, but now it seems reasonable and may help us to better structure the > code. Additionally, I would encourage us to make package names consistent > with the module's structure to make modules Jigsaw-compliant. We do not > have module definitions now, but I think it would be great to have them, it > should help us to enforce component boundaries and proper responsibility > encapsulation. > > As for the naming, it's not entirely clear for me when to use the term > Service vs Manager. Serice is an entry point to a component/server, but so > is Manager - a Manager defines an API that is exposed by a module to other > modules. Subjectively, I see the following difference between a Manager and > a Service in the examples of entities you provided: > * A Manager is a node singleton. Its whole purpose is to provide an API > gateway for other components into a particular subsystem of a node > * A Service is an object that is bound to a particular runtime entity > (raft group service is bound to a raft group, and we can have multiple Raft > groups; partition service is bound to a particular partition). We can > re-create services based on changing runtime state and/or configuration. > Does this make sense? > > Finally, I would use lang module name instead of core (the core is > confusing because right now core contains all necessary classes required to > start a minimal Ignite instance; this sets up wrong expectations for Ignite > 3). Additionally, I think it would be good to exploit the old > org.apache.ignite and org.apache.ignite.internal naming scheme: all public > classes must go to the non-internal package. The ignite-lang module will > have both public and internal packages. This automatically implies that all > modules except ignite-api and ignite-lang must reside solely in > org.apache.ignite.internal.* packages. This will be easy to check and > maintain. > > Throughts? > > --AG > > пт, 26 мар. 2021 г. в 20:28, Alexander Lapin <lapin1...@gmail.com>: > > > Igniters, > > > > Seems that within Ignite-3 we have some mess in terms like manager, cpu, > > service, module, etc. Let's clarify this point. Also It'll be great to > > discuss the rules of dividing code into modules. > > I'll use the context of Ignite cluster & node lifecycle > > < > > > https://github.com/apache/ignite-3/blob/ignite-14393/modules/runner/README.md > > > > > for terms definition and as an example source. > > > > *Terms clarification.* > > > > - Component - semantically consistent part of Ignite that in most > cases > > will have component-public but ignite-internal API and a lifecycle, > > somehow > > related to the lifecycle of a node or cluster. So, *structurally* > > TableManager, SchemaManager, AffinityManager, etc are all components. > > For > > example, TableManager will have methods like createTable(), > > alterTable(), > > dropTable(), etc and a lifecycle that will create listeners (aka > > DistributedMetastorage watches) on schema and affinity updates in > order > > to > > create/drop raft servers for particular partitions that should be > > hosted on > > local node). Components are lined up in a graph without cycles, for > more > > details please see mentioned above Ignite cluster & node lifecycle. > > < > > > https://github.com/apache/ignite-3/blob/ignite-14393/modules/runner/README.md > > > > > - Manager is a driving point of a component with high level lifecycle > > logic and API methods. My intention here is to agree about naming: > > should > > we use the term Manager, Processor or anything else? > > - Service is an entry point to some component/server or a group of > > components/servers. See RaftGroupService.java > > < > > > https://github.com/apache/ignite-3/blob/main/modules/raft-client/src/main/java/org/apache/ignite/raft/client/service/RaftGroupService.java > > > > > as an example. > > - Server, for example RaftServer, seems to be self-explanatory itself. > > > > > > *Dividing code into modules.* > > It seems useful to introduce a restriction that a module should contain > at > > most one component. So that, combining component-specific modules and > ones > > of api, lang, etc we will end up with something like following: > > > > - affinity // TO be created. > > - api [public] > > - baseline // TO be created. > > - bytecode > > - cli > > - cli-common > > - configuration > > - configuration-annotation-processor > > - core // Module with classes like IgniteUuid. Should we raname it to > > lang/utils/commons? > > - metastorage-client // To be created. > > - metastorage-common // To be created. > > - metastorage-server // TO be created. > > - network > > - raft // raft-server? > > - raft-client > > - rest > > - runner > > - schema > > - table // Seems that there might be a conflict between the meaning of > > table module that we already have and table module with > > create/dropTable() > > - vault > > > > Also it's not quite clear to me how we should split lang and util classes > > some of which belong to the public api, and some to the private. > > > > Please share your thoughts about topics mentioned above. > > > > Best regards, > > Alexander > > > -- Best regards, Andrey V. Mashenkov
