Hi,
I design a soft real-time system that should handle different clients’ requests and activities (such as telephone calls, processing of different types of events occurring during the calls, inserting these calls into the Data Base). Thus my server has to provide the client with suitable interfaces allowing opening new session, new call, close the call, update the call etc. and, at the same time, the server has to send events that can be raised as result of changing in the calls status to these clients . Also the system should support some kind of “keep alive”.
I am going to use Indigo as my infrastructure (duplex interface). Also I have to provide my clients (it is global requirement to the whole system) with assemblies including data structures and our security framework (from other team).
My clients are internal servers and services (in 99%) that provide different functionalities for endpoint user.
I have doubts in the way I should provide my clients with the interface.
My question is whether it is better to provide my clients with just duplex interface or hide from the client the infrastructure and provide him with regular class functions (since anyway I have to provide the clients with my assembly) that can include some functionality and use only one interface (for example SendMessage) and to resolve how to process this message on the server side.
1.
Client MyAsembly APIServer Process server
design issues in client-server system
Efergus
I don't think it matters how your assembly calls the process server - as long as you isolate the clients from these decisions.
You probably want to do something like providing the clients with the interface they need (StartCall, EndCall etc.) and a mechanism to inject your DLL in runtime - this way you can replace the DLL whenever the technology or protocols change without recompiling any of the clients.
Arnon
Optima Warehouse Solutions
I'll try to make my answer more clear
The dependency you "inflict" on the other groups is the piece of code you provide which they need to compile and test with the rest of thier code.
Since you own (write) the two sides of the protocol - you write the code on the client side and on the server, it is of secondary importance how you do that. (though it is reasonable to assume you can prepare a stable client side code faster using the first more loose coupled approach).
Now if you can finalize the interface with your users (startCall, endCall and whatever) give them a stub or a mock to program, test and integrate with - you would be free to code your protocol in what ever way you want and evolve it in the future (as long as the "contract", the interface and its behavior are kept) - I describes such a way in the first reply
Arnon
... no and then!!
Hi,
I don't want to inject my dll in runtime. The client will get it in compile time, but since we are in different groups, our cycles of development and building are not the same.
I'll try to make my question more clear :
On the one hand, I want a loosely coupled integration solution (SOA - the first approach),
On the other hand I want to allow to my server API to share not only data , but functionality as well(minimal protocol checking, keep alive, building messages for SendMessage function ), that should provide (IMHO) better abstraction and extensibility (the second approach).
So the question is when it is a good idea to share functionality (not only data structure) between applications, or ,maybe, the second approach is not good idea at all
Thanks