WPF and Remoting | Syndrome of Yesterday
Talking about distributed system, now we have a lot of combination, take a look
- Windows Form + Web Services
- Windows Form + Remoting
- WPF + WCF
- WPF + Remoting
- WPF + Web Services
- Type your combination here
After doing a little research about the client, we have conclusion like below
- Client (new PC) -> we will use WPF for better UX
- Server (old PC) -> we will choose Remoting J << why? Why?
A word remoting is somewhat like "syndrome of yesterday", remoting have many problem in interoperability concept as well as communications security, but when we need a better performance in a single platform "who cares about the syndrome". Ok let's do a little research about implementation remoting in WPF.
- 1. Create a remote objects (it's class library bro!, that derivative from MarshalByRefObject )
- 2. Host the remote objects in Remote Server (I choose console mode hosting model)
- 3. Reference the Remote Server with the remote objects
- 4. Create an app.config that describe the remote objects, channel type , and the port
- 5. Call the configuration through Remote Server code
- 6. Create WPF Applications , add the reference from remote objects and System.Runtime.Remoting
- 7. Called the remote objects through WPF (that's it)
- 8. Run the remote server (ouch firewall)
- 9. Run the client
- 10. Debug and Test
Ok at least my POC is run, now it's time to improve it... As my homework's
- 1. Use soap formatter and HTTP channel
- 2. Use interface rather than derivative object like Patient
- 3. Do a real things in business logic
Ah here the sample code...
Ciao | Ridi Ferdiana