| .NET was crafted by Microsoft to make software developers more productive. Key to this productivity was providing a set of tools and technologies that hides the inherent complexities of traditional software development and makes them available through runtime services. Also, developers needed a pluggable component model for easy assembly of applications. The Internet has evolved to a maturity level making it imperative to leverage the standards-based Internet infrastructure. Also needed was the capability to support multiple programming languages and provide a rich set of common class libraries. Last, but definitely not least, was to ensure interoperability with existing technologies and security. -
Component-based architecture ” The introduction of Component Object Model (COM) and Distributed COM (DCOM) has already sown the seeds for a component-based architecture for designing, building, and managing applications. A component-based application model is a key element in the division of a complex business process into a set of manageable components , facilitating reuse and concurrent application development. Whereas COM/DCOM provided developers with a basic component model establishing a common set of interfaces that were required by developers to utilize the model, at the same time it required developers to build the necessary plumbing by themselves to effectively use it. In a number of scenarios, developers got drenched in the core plumbing efforts rather than focusing on the core business logic. Visual Basic was an attempt to abstract the component-based architecture to make it easier for developers, but it, too, came with limitations, such as the lack of full-blown object-oriented features. -
Leverage the ubiquitous Internet ” DCOM introduced the required framework for supporting distributed application development where application components could be deployed on a distributed set of servers for scalability and performance. However, DCOM also introduced the Network Data Representation (NDR) format, which was proprietary and didn't work well with enterprise firewalls and across enterprises . Developers and administrators wanted to utilize the ubiquitous Internet protocols and data formats such as HTTP/HTTPS, Web services, SOAP, XML and so on. -
Support multiple programming languages ” One of the achievements of the COM programming model was that COM components could be developed in different programming languages, including C++, Visual Basic, and J++. However, developers still lacked true language integration and weren't able to inherit the capabilities of a class developed in one programming language in another programming language. Whereas developers liked the support of multiple programming languages, they needed true language integration rather than just interoperability. -
Common class library ” The nonexistence of a common class library was probably one of the biggest concerns of COM developers. What was Microsoft Foundation Classes (MFC) in Visual C++ was something entirely different in Visual Basic. Even lower-level libraries for input/output were totally different between programming languages. The lack of a unified class library resulted in the creation of several application programming libraries to achieve the same purpose in different programming languages; in fact, in some scenarios there were multiple libraries for the same purpose for a single programming language. At the same time, Microsoft developers saw the evolution of the Java programming language, which featured a rich class library, and expected a similar class library to be available in the Microsoft platform. -
Common development platform ” Microsoft C++ and Visual Basic were primarily focused on developing client/server applications and component libraries. The introduction and emphasis on the Web-based application delivery model created a need for a tool for Web application development. Visual Interdev was introduced to solve this problem but had yet another programming and application development model. Similarly, the introduction of mobile devices brought the challenge of developing mobile applications that run on devices. Embedded Visual C++ and other tools were introduced; although they used the same programming languages, they had totally different programming models and libraries. Visual Basic for Applications (VBA) was yet another model used for developing applications and extensions with the Office Suite of products. Developers required a consistent toolset and an underlying framework to be used across different application-delivery models. -
Ease of deployment ” Although COM introduced component-level reuse, it introduced another problem, called component clashes , which occurred when a version of a particular DLL used by one application was not compatible with another application and was overwritten by yet another application, breaking the existing application. This problem, sometimes termed DLL Hell , was a major cause of concern in large-scale application development and deployment. Adding to this was the requirement of registering components and unregistering components when applications were deployed or removed. Administrators needed a much better deployment model through which they could easily install, configure, and uninstall applications and components. -
Security ” The requirement of having applications dynamically downloaded to a client workstation introduced an added level of security requirements on the code. On the competitive technology landscape, Java Virtual Machine had a notion of running applications in a sandbox with configurable security permissions. Developers expected a similar set of features to be available within the Microsoft platform. -
Interoperability ” With the introduction of any new platform comes the question of how existing components and applications interoperate and/or migrate. Developers expected the next -generation Microsoft software platform to easily interoperate with existing applications and components. Another concern, primarily for enterprise application developers, was the presence of multiple development platform approaches within their organization. They expected easy interoperability, not just within the components of the Microsoft platform, but even with competitive platforms using standard protocols and formats. SHOP TALK : BEING COMPETITIVE IS KEY TO INVOCATION In a number of ways, the real reason Microsoft .NET was created was to be competitive with another common application development platform, J2EE (Java 2 Enterprise Edition). Java developers enjoyed rich class libraries, a virtual machine-based managed-execution model, APIs and platform capabilities such as Enterprise Java Beans (EJB), Java Server Pages (JSP), Java Database Connectivity (JDBC), and so on, which provided a server-based component model, an efficient and rich Web programming model, and common database connectivity, respectively. Whereas J2EE has its own set of benefits, there is always room for innovation and a strong competitive alternative. The DNA platform (COM, ASP) was definitely around but lacked some of the key capabilities and wasn't built on top of a standards-based infrastructure. I have found that this very need for being competitive in the application development marketplace is definitely one of the biggest reasons behind the new capabilities and innovation in .NET, and I expect this trend to continue. |
|
