You are not logged in.
Pages: 1
Hi,
I want/have to deploy a server app, that runs on different servers in a company network (distributed all over the world).
I think about implementing it using the interface based approach.
I would have one interface that is implemented by the server app but runs on several servers.
How can I implement the connectivity to an undefinded number of servers in my local calling app, which all publish the same interface?
In addition I need to check all of them, one at a time.
It could also be, that not all servers are running all the time, or that new servers are added later on.
The procedure would be more or less like this:
- Connect to server 1
- check if desired information is available
- disconnect
- connect to server 2
- check if desired information is available
- disconnect
.
.
.
when the decision is made, download the data from server1 or server2
The second usecase would be to upload data to a single server or to a selectable amount of servers.
I think about adding one Client instance with one "Service" field to call the interface.
Then I could lookup the configured servers in my config file, and poll through all servers in a loop.
I would need to
- create the client object
- look up if the service is available/published by this service
- make the call
- free the service
- free the client
What do you think?
Any help is greatly appreciated.
Best regards
Bastian
Offline
I would:
1) define each workflow as interfaces,
2) write some test scenario calling these interfaces,
3) implement those interfaces using classes (on the same process), with a resolver pattern
4) run the tests
5) and... once the logic is fine within the same process, use mORMot interface-based services to publish those interfaces over one or several servers.
The idea is to use mORMot only for the client/server, and use regular class/interface code for your own logic.
One common mistake is to move the logic within the framework, or try to make the framework do the logic for you.
The easiest and safest is to put the logic outside of the framework, then use it for what it is good for: SOA remote calls.
It will ensure that you would not blame the framework not to do all your business logic (and even perhaps the coffee?) for you.
Offline
Thanks for your valuable feedback.
I have my existing business logic separated from the mORMot Framework (a lot of legacy code that needs a huge amount of refactoring and rewriting).
I agree, when refactoring the code it would absolutely make sense to split the workflows into separate interfaces to decrease the complexity and simplify testing.
It would make sense to follow the steps you've described when cleaning up and extending the existing code and finally attaching it to the mormot framework.
I would have intended to use the mORMot only for the SOA calls (mistakes and coffee are handmade )
Can you give me some further details about the mentioned resolver pattern.
I tried to look it up but couldn't find the required infos on what problem it solves in which way.
Thanks
Bastian
Offline
Pages: 1