Re: Smart client - general data access best practice question

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

Bandwidth usage is minimal - firstly the sessions are stateful so its only
Deltas that are exchanged, and that traffic is gzipped using SOAP extensions
anyway. High latency does hurt, but anything better than 200ms is fine, and
under 500ms usable.
We have several live clients, some using PDA (O2 XDA II) devices in realtime
via GPRS as well as Rich Windows clients.

We are looking forward to playing with XAML - I believe the server could
publish form definitions as well as provide all of the functionality.

Whitepaper on its way to your inbox.

Radek


"Marc Gravell" <mgravell@xxxxxx> wrote in message
news:uvAOYbIAGHA.216@xxxxxxxxxxxxxxxxxxxxxxx
>I would be interested in that paper - while I admire the central nature of
>this approach, doesn't this *significantly* increase the bandwidth and
>latency of the application? An interesting discussion.
>
> Marc
>
> "Radek Cerny" <radek.cerny@xxxxxxxxxx> wrote in message
> news:%23czCvpGAGHA.3296@xxxxxxxxxxxxxxxxxxxxxxx
>> Marc,
>>
>> the approach we take is to have all functionality (eg business rules,
>> persistence, everything) reside on the server, and deploy purely as Web
>> Services. This allows for rich [but thin] client access, AJAX browser
>> access, SmartPhone, PDA, B2B etc.
>>
>> It has taken a while (many many years actually) to develop a
>> framework/platform for building systems like this, but it has paid off,
>> as we can now deploy any business functionality (eg ERP, CRM, Financial)
>> purely as hosted Web Services.
>>
>> The client simply has access to server objects - objects in the pure
>> sense being Fields and Methods. A change to a text box, click of a
>> checkbox etc results in an a request to the server to make the
>> corresponding change (<Delta field="FirstName" value="Fred"/> for a
>> Textbox called 'FirstName'); business rules are executed, validation,
>> calculations, calls to the persistent store etc and the net results are
>> sent back to the client for distribution (eg <Field id="FullName"
>> value="Smith,Fred"/> if there was a server rule that made FullName =
>> LastName +","+ FirstName). Methods are invoked similarly (reflection on
>> the server is used) and repeating data for display in grids and listviews
>> has a particular schema that the client understands.
>>
>> Our server sessions are Stateful, so no cookies or state restoration is
>> required (a parameter of the calls is SessionID)..
>>
>> I have a Whitepaper if you're interested.
>>
>> Good luck,
>>
>> Radek
>>
>> "Marc Gravell" <mgravell@xxxxxx> wrote in message
>> news:egRikX8$FHA.1028@xxxxxxxxxxxxxxxxxxxxxxx
>>> Kind of an open question on best-practice for smart-client design. I'd
>>> really appreciate anyones views (preferably with reasoning, but I'll
>>> take what I get...). Or if anybody has any useful links on the subject?
>>> (and yes, I have already googled it at length, but still no strong
>>> decision)
>>>
>>> =============
>>>
>>> After a long stint of pure-desktop / pure-server applications, I'm
>>> currently working on a number of smart-client projects in C# using .Net
>>> 2.0.
>>>
>>> Obviously we need to do our data access through the web-service, but we
>>> have various options available to us, including:
>>> * Define rich classes at the server (exposed directly as e.g. the return
>>> value from [WebMethod] functions), then use WSDL.exe to extract a
>>> representation of those objects to use at the client
>>> * Using datasets
>>> * Using a hand-crafted, documented schema (presumably xml) on the
>>> web-service and manually constructing (separate) rich objects at both
>>> ends
>>> * Not using objects on the web-service, but simpler
>>> "parameter-per-property" based invokes
>>> * Others
>>>
>>> Personally I favor the first object, as it
>>> a: best fits my (pre-conceived? naive?) ideas of OO
>>> b: doesn't bind the client and server too closely together (i.e. I could
>>> probably call the web-service from a VB6 or Java client if I wanted - no
>>> dependency on the more complex dataset object, and no dependency on a
>>> .Net client (as would exist if I did binary serialization))
>>> c: seems reasonably efficient code-wise, as I don't need to write all my
>>> own code to stub out the client objects and web-service methods
>>> (WSDL.exe does that for me)
>>> d: allows me to pass complex data in a single round-trip to the server,
>>> rather than multiple calls which would then need more complex
>>> transaction management
>>> e: thanks to the BindingSource and the flag to WSDL.exe that enables
>>> INotifyPropertyChanged, meets all of my UI data-binding needs
>>> f: avoids messing with datasets, which (maybe incorrectly) I percieve as
>>> slightly messy and less efficient that performing my own database access
>>> at the server
>>>
>>> OK, this means that at the client I have objects with reduced
>>> functionality (arrays instead of object-collections), but in the few
>>> cases where I genuinely need something more sophisticated I can always
>>> wrap it in a facade or other wrapper, so no huge issue here.
>>>
>>> ---
>>>
>>> So - before I go to town, am I barking up the wrong tree? Am I making my
>>> life hard for the future, or is this a reasonable approach? I don't have
>>> any immensely complex/specialized requirements, so it should be similar
>>> to other peoples experiences...?
>>>
>>> All thoughts appreciated.
>>>
>>> Marc
>>>
>>>
>>
>>
>
>


.

Relevant Pages

  • Re: Browser as Platform (was DesignBais - Impressive)
    ... storing state on the client -- will sessions be managed on the client, ... Given the security on ... trying to work without a Java app-server, like tomcat, on the server. ...
    (comp.databases.pick)
  • Re: [PHP] Passing var from one page to itself
    ... I prefer using POST/GET and/or SESSIONS. ... That's the way I pass data between client and server. ...
    (php.general)
  • Re: [PHP] Passing var from one page to itself
    ... tedd wrote: ... I prefer using POST/GET and/or SESSIONS. ... That's the way I pass data between client and server. ...
    (php.general)
  • Re: TCP/IP Newbie
    ... Have many client apps either PC's or Terminal Services/Citrix ... I thought a listener could be implemented anywhere client or server. ... (That seems to be the way citrix sessions are ...
    (microsoft.public.win32.programmer.networks)
  • Re: What doesnt lend itself to OO?
    ... >> proxy and instructs the server to constuct the real object. ... rather than client code. ... If 'clock' is instantiated in the server, ... > for the server interface at the OOA level. ...
    (comp.object)