Section 2.2. Programming Paradigms


2.2. Programming Paradigms

The first programming paradigm that enabled abstraction from the details of computer programs was functional decomposition and the related technology of functional analysis. Functional decomposition pioneered the formal introduction of flow charts, showing data that flows through a number of processes. One of the first people to formalize it was Myers in 1976 [Myers76]. However, the first language that was suited to functional decomposition was the COBOL (Common Business Oriented Language) programming language that was created as early as 1959 by a body called CODASYL (Conference on Data Systems Languages) and that was later adopted as an ANSI standard. Having undergone many improvements and additions since then, it is still a prevailing programming language in many major organizations. Apparently, more code is written in COBOL than any other language. In 1970, while working at the Polytechnic University of Zurich, Niklaus Wirth invented Pascal, a language that explicitly encouraged functional decomposition and that remains one of the most popular teaching languages for computer science.

Functional programming concepts remain popular because they are easy to understand by students, programmers, and customers. They provide a powerful tool to create reusable blocks of codefunctionsthat can even be sold in the form of software libraries.

Functional programming contributed to the service concept because functions essentially provide some form of abstraction. However, the amount of abstraction they can provide is limited.

It soon became apparent that the functional paradigm had its limits. Multipurpose reusable functions are hard to create. Often, the caller must provide many parameters, and a lot of data must be passed into multiple functions in order to obtain the required result. The concepts of software modules and software components were created to cope with this growing complexity. These concepts came in many different flavors. The first time these concepts appeared was in the original implementation of the ADA programming language, modules in the Modula2 computing environment (also created by Niklaus Wirth in 1979), and the hugely commercially successful MS Visual Basic's VBX components. Although very different, they share the common abstraction of software components as a container for both data and the functions that operate on that data. Even before the advent of software components, it was considered good programming practice to shield a function's user from its internal details. At this point, the concept was introduced as a language element known as encapsulation.

The significant increase of abstraction and encapsulation that components provide are an important step towards service orientation. However, their main purpose was in-situ development reuse, while service orientation focused on distribution and runtime reuse.

By the early 1980s, modularization and component programming were widely recognized as the next big trend in software development, and the MODULA language provided a stable and mature programming platform for this trend. However, the Japanese and U.S. governments poured massive amounts of money into the development and marketing of their own programming environments, PROLOG and ADA.

The uncertainty that emerged from this proliferation of platforms delayed the adoption of component-oriented programming long enough for it to be outrun in popularity by object-oriented programming,[2] which introduced the object as a programming and runtime concept. Originally, object-oriented programming was developed for simulation purposes. The first object-oriented language, SIMULA, was developed as early as 1967 at the Norwegian Computing Center in Oslo by Ole-Johan Dahl and Kristen Nygaard, and it has since been developed further [Kirk89]. Object orientation entered mainstream programming paradigms in the mid 1980s with the creation of Smalltalk [Gold83] and C++ [Stro85]. New versions of most other object-oriented languages, such as Java, were invented, while others, such as Pascal or even COBOL, were extended to embrace object orientation in one way or another.

[2] It took approximately 15 years until the concepts of component-orientation reemerged in the late 1990s, this time supported by concrete component platform implementations such as Enterprise Java Beans.

Objects are much like components in that they support encapsulation and the bundling of data and functions and add the concept of individual entities (the objects) as instances of classes. The objects communicate through message exchange, but more importantly, object orientation adds the concept of inheritance, where types can be derived from other types. The derived type inherits all the internals and behavior of its ancestor. This spawned new concepts such as the programming by interface paradigm.

A common problem of object-oriented programming is that the level of abstraction and granularity that is exposed to the clients of a component is too fine to enable efficient reuse, let alone distribution (see Figure 2-3). Therefore, object-orientationwhile being great for large, usually relatively isolated and monolithic applicationsproved to be a dead-end from the point of view of distributed computing. Service-orientation aims to overcome a lot of the problems of distributed object computing, especially with respect to the right level of granularity and access patterns for remote services. Service-orientation also often goes a step backward when it comes to the question of how tightly data and functionality should be coupledwhile OO imposes encapsulation of data and functionality, service-orientation often assumes that data and functionality are separated.

Figure 2-3. The development of programming languages had a strong impact on the interfacing techniques for distributed components and the implied access pattern to these components.


As we can see, the evolution of the different programming paradigms also had a huge impact on the concept of service-orientation. Modern programming languages and development environments are providing the technical foundation for enterprise-level services. However, not all programming concepts are directly applicable on the enterprise service level. With the ever tighter coupling of remoting and programming language technology, it becomes even more important to be aware of these mismatches between programming languages and enterprise services and to avoid falling into the trap of exposing too finely grained technical concepts to the enterprise level.[3]

[3] See Sections 9.1.2.2 and 9.1.2.3 for detailed insight into this specific discussion.



    Enterprise SOA. Service-Oriented Architecture Best Practices
    Enterprise SOA: Service-Oriented Architecture Best Practices
    ISBN: 0131465759
    EAN: 2147483647
    Year: 2003
    Pages: 142

    flylib.com © 2008-2017.
    If you may any questions please contact us: flylib@qtcs.net