> > Putting some > logic at a > > middle tier, not necessarily at the DBMS server, also has > advantages. > > At the risk of yet more bandwidth, but not consuming licenses, many > > basic validation rules can be exposed as client-independent web > > services. That approximates that interpreted layer, makes changes > > virtually instantaneous, and eliminates deployment issues. > > Goes to show you what we'll do for cost considerations. > Introducing another tier seems like madness, unless it's cheaper. :-) >
Yes, there are times it makes sense to use a third tier, especially where data manipulation or db-independent operations need to take place, or you need access to languages that can provide facilities not best handled in mv Basic (complex parsing, dynamic rules or anything requiring working with large data sets for example). Middle tier logic is pretty much an essential in the RBDMS world as (for the most part) there isn't the complexity available directly in the database that we have with our inbuilt Basic. In a sense, an MVDBMS is both a tier 2 and tier 3 (if I haven't got the numbers back to front!) in the same space, so if you look at it from that point of view just about any multivalued C/S application is essentially three tier <grin>. I've been putting together a tool mapping web services onto mvBasic subroutines, using an XML parser built into an ISAPI DLL in the middle tier to decompose the mapping of complex types to and from dynamic array subroutine arguments, and the results are proving reasonable in terms of performance. There's room for improvement at this stage, but as a model it seems to work well - once you get through the minefield of just how many different 'interpretations' you need to support to handle different SOAP clients. I'll be looking out for some beta testers some time soon (hint!) as I don't have the facilities any more to simulate volume processing. Brian ------- u2-users mailing list [email protected] To unsubscribe please visit http://listserver.u2ug.org/
