Ok, let's see one by one:
Originally posted by P Das:
1) A systems extensibility is affected by modular code and design patterns? How? Because by themselves, to me, they cannot make a system extensible. It requires how they are deployed, too. Also, if we use Servlets to access distributed persistence, can it cause extensibility hazard? A counterargument could be, Servlets, through deployment can be extensible. Am I missing something?
Extensibility means you will be able to extends the application functionality in the easier way possible, so it's true the design patterns and modular code could affect this. A deployment will be able to add new funcionality to your application, I really don't think so. (give me an example to understand what you mean by "through deployment can be extensible")
Originally posted by P Das:
2) Can 'Thin Client' be a weakness in a 2-tier architecture with Perl/CGI Web-tier and persistence + business logic EIS-tier? If there is only one Web Server, does 'Performance' not seem to be more apt candidate for weakness?
Ok, the main problem with this type of architecture is the maintainability. The performance could be better with a 2-tier than a 3-tier, or n-tier application. take a look of this article to give you a better explanation about it:
Two, Three, N-tier which one should I pick?
Originally posted by P Das:
3) Can we build a Web Service client without supplying the WSDL? The WSDL, per me, provides the schema around which client need to 'Adapt' its method calls.
The answer is yes... you can, you need the wsdl to create your classes if you are using objects in your calls (Dynamic proxy), but you can access a webservice with it's url and using a technique named "DII" (Dynamic Invocation Interface) take a look of this:
http://java.sun.com/j2ee/1.4/docs/tutorial-update2/doc/JAXRPC5.html, this is useful if you don't have the wsdl at the coding time, or if the wsdl will change but it will keep the method you're calling available for you.
Hope this solves some of your questions...