Many partners that I'm working with now face with client-server to 3-layers migration challenge.
It gets harder in big organizations like banks where developers and other tech staff have grown on mainframes and just recently switched to "newest" client-server.
ISVs on the other hand must support their customers thus maintaining huge legacy code base.
They normally use MS C++ and VB, often Delphi for the client.
So it's a 2-side challenge: switching to 3-layers architecture and finding ways to migrate from the legacy code (while keep everything going).

High level mental flow can be the following:

  • 3-layers vs client-server - architectural differences. OK - agreed on 3-layers.
  • Rich client vs thin client. OK - selected client kind.
  • Technologies for the middle. OK - selected WS or Web app.
  • Composability. OK - vertically split business functionality (for the future possible mapping to WSs).
  • Data access and transactions. OK - selected declarative or manual, Enterprise services or ADO.NET or SQL.
  • Data flow. OK - selected how data traverses boundaries - DataSet, XML, classes. Performance vs simplicity.
  • State. Short operations - stateless, long operations - MSMQ/Yukon Service Broker/BizTalk or state in DB.

Security:

  • Authentication between boundaries.
  • Authorization and roles.
  • CAS.
  • Channel/message security.

Management and monitoring:

  • Level of inegration (aka "watch my stuff through system utils") decision
  • .NET Tracing
  • Write to Event Log
  • Perf counters
  • WMI
  • EIF

Then migration options:

  • Complete. Take all the code, extract "business logic" and "data acess". Rewrite for the new architecture.
  • Medium (rare possible). Take components. Reuse at the appropriate layer.
  • Evolutional. Write WS or Web facade. Use existing experience to create components from legacy code base on language of choice. This approach allows splitting development teams horizontally across functional layers which are developed independently.

Now performance and sclability:

  • You rely on DB - hence the same for the middle-layer
  • NLB - state challenge again
  • If scale up - app pools on different procs

Now extensibility:

  • At UI (mostly push-model)
  • At business logic (mostly pull-model, WS can play here)
  • At DB (aka metadata extensibility)

Then tools support:

  • Integrate to VS via VSIP
  • Integrate to VS via Add-ins
  • Just build components in VS

to be continued...

 

This posting is provided "AS IS" with no warranties, and confers no rights