Rosario Von Li the Santificator: 2009-03

A Comparative Study: Component-based software engineering V.S. Service-oriented software engineering

1 Project introduction 3
2 Component based software engineering 3
2.1 Definitions(Component based software engineering) 3
2.2 Concepts (Component, Module, Interface, Object) 3
2.3 Objectives 6
2.4 Benefits and disadvantages 6
2.5 Needs and Motivation 7
3 What is SOA-based software engineering? 7
3.1 Definitions 7
3.2 Concepts 8
3.3 Objectives 9
3.4 Benefits: 12
3.5 The future of SOA 13
4 What are the major differences and similarity between these two approaches? 15
5 What are the differences between service components and modern components? 20
5.1 What is service? 20
5.2 What is modern component? 21
6 Building SOA-based software system is same as building a component-based system using service components? 24
7 Tools and technologies for building service components 26
7.1 Visual Basic Extensions, OCX/ActiveX/COM and DCOM from Microsoft 26
7.2 IBM Service Component Architecture Explorer Tool 26
8 Discussions and justification comments 27
8.1 What is SOA? Can we buy it? 27
8.2 What’s the base system of SOA? 27
8.3 How to design service contract? 28
9 A summary, conclusions, and future directions 31
Reference 32

1 Project introduction
There are people who start to accept the “new idea” and try to change their software product structure into component based, and there are also people who start to research on new concepts on software structure to replace the “nearly old fashioned and full of overestimate” – Service oriented architecture. Things might be worse under the current economic crisis as adopting new business architecture are lacking of funds, even some specialists pointed out “SOA met its demise on January 1, 2009, when it was wiped out by the catastrophic impact of the economic recession” [1]. That’s the IT industry, which seems they never have the latest and the best technique in all kinds of areas.
Neutrally speaking, component based architecture is still enough for most of current requirements, despite of its “old” age of more than 20 years. And after the depression, SOA will still be the most prospective architecture within a few years, but there are already articles that doubt if SOA will be easily applied by most enterprises and easily get the expected positive results after applying SOA.
This paper will briefly compare component based software engineering and service oriented software engineering. The concepts, comparison, tools and methods will show how these two major software architectures play their roles in current enterprise software.
2 Component based software engineering
2.1 Definitions (Component based software engineering)
Component based software engineering (Abbreviation: CBSE), Component based development, Component based programming, are exactly the same thing in software industry. In Wikipedia, CBSE is defined as “a branch of the software engineering discipline, with emphasis on decomposition of the engineered systems into functional or logical components with well-defined interfaces used for communication across the components”
This definition introduces the basic unit forming the CBSE – Component (Software component). The architecture is built by the relations between the components “decomposed” from the whole system. The interfaces enable these components communicate with each other and connected to form the whole system.
2.2 Concepts (Component, Module, Interface, Object)
To explain the concepts in component based software engineering and their functions, relationships, we would like to introduce a kind of toys which was very popular in our childhood – Electronic bricks, as the example. Each brick has outer plugs to be connected with other bricks, and have different functions: line, battery, bulb, diode… Under the instructions, players could build up a radio with easy functions or a speaker, etc.
 Component
A software component is a unit of composition with contractually specified interfaces and explicit context dependencies only. A software component can be deployed independently and is subject to composition by third parties.[2] Clement Szyperski lists three major properties of software component: a unit of independent deployment ; a unit of third-party composition ; no observable state (Encapsulated).
Let’s consider the CBSE as a set of Electronic Bricks. Here is what a single brick is designed in this toy: An opaque plastic shell, with sockets in the bottom, and outlets in the top, and a kind of electronic component or a set of circuit inside. The sockets and outlets are used to connect with other bricks or the main board to install these bricks. Players could only see the corresponding electronic symbol instead of the inside structure of the brick.
Let’s conclude the properties of this brick and compare them with the properties of CBSE to get the ones of CBSE much clearer and organized:

Figure 1 “Electronic bricks” – Components
Unit of independent deployment: a brick is the basic unit of setup any kind of “product”, so do the software component.
Third-party composition: The players are not the producers of these electronic bricks.
Encapsulated: The players could not see the inside structure of the bricks. They can only judge the function of the brick by its electronic sign on the top.
Communicating with other components: A brick could connect to others with its sockets and outlets.
Multiple use (Reusable): These bricks could be used by many times to setup many kinds of products.
 Component Interface
Return to the electronic bricks, the board which has specified placed outlets to install the bricks, is exactly playing the role of component interface.

Figure 2 “Bricks and board” - Components and interface
In CBSE, connecting and enable communication between components is not so easy as plug the bricks on the outlets. First of all, a good designed interface is required. An interface of software component could be defined as a specification of its access point.
The interface doesn’t offer any implementation of its operations, only provides the descriptions and protocols. Thus, it enables itself to replace implementation with interface changes, or add new interfaces and implementation without any change on implementation.
 Other concepts
Patterns : a pattern defines a recurring solution to a recurring problem. It could be employed in the design and documentation of a software component. It could be used to describe the low-level implementation details of the behavior and structure of the components, or the relationships between components in the context of a particular programming language.
Component model: A component model defines a set of standards and conventions used by the computer developer, whereas a component framework is a support infrastructure for the component model.
2.3 Objectives
There comes out the question, what should CBSE do after they are applied? Why the definitions of CBSE are clinched to those principles? Let’s list out those obvious things which will benefit the whole software production.
First of all, under CBSE the components could be reused many times, the designers don’t need to mess with the inside code of the component, just get it, setup on the interface, and then connect them together. CBSE has very specified detail document to provide support for these operations so that the designers would not confuse on the component functions.
Thus, applying component based software engineering should have these objectives :
To reduce system production cost and time by reusing existing reusable and high quality components
To provide support for the development of systems as assemblies of components
To support the development of components as reusable entities
To facilitate the maintenance and upgrading of systems by customizing and replacing their components
2.4 Benefits and disadvantages
By achieving these goals, CBSE has several advantages towards the old software architectures:
a) Lead time reduced : by building applications from reusable components
b) Cost reduced : Multiple reusing components could save the cost of developing new components
c) Higher quality: more times a component has been used, more times it has been tested. Retesting is one of the most powerful methods to enhance coding quality.
d) Easy Maintenance: easy updating with simply replace the old version components by new version, which could also save the maintenance cost.
Of course, CBSE is not the answer to every problems in software designing, that’s why SOA is grabbing more and more users. Before we talk about SOA, let’s see what the things CBSE lacks of are.
e) Difficult specification: it’s not easy to specify component standards during first time design.
f) Lacks of ideal component models: there are still many existing component models which are incomplete, inconsistent, and have problems during deployment. In one word, they are not standardized.
g) Life cycle problems: As components are not observable, there will be more problems during independent component development process.
Production from scratch is a very expensive undertaking. Suboptimal solutions in all but the local areas of expertise are likely. Maintenance and “chasing” of the state-of-the-art, such as incorporating web access, can become a major burden. Interoperability requirements further the burden, with other in-house systems and, more critically, also with business partners and customers. As a result, most large projects fail partially or completely, leading to a substantial risk. [3]
2.5 Needs and Motivation
CBD claims include reductions both in development costs and time and the increase of the developed software system’s overall quality [4]. These improvements result from reuse: building software from existing well tested building blocks is more effective than developing similar functionalities from scratch. It is important to analyze the reuse related improvement achieved through CBD. The bulk of component related research has been mainly focused on the functionality and composability of components, as well as their specification. The research niche of component quality assessment, with an emphasis on quantitative approaches , is fairly unexplored. The few existing evaluations are performed at a qualitative level, which makes the assessment of the true impact of the above-mentioned claims harder. In our research, we are particularly interested in the quantitative evaluation of software components and their impact on the systems they are integrated in.
3 What is SOA-based software engineering?
3.1 Definitions
It is hard to find an exact definition of the term SOA. The problem is not that there aren't any definitions; the problem is that there are many different definitions. To give you an idea of how they are similar and dissimilar, a selection of published definitions are sidebars in this chapter. You'll find some common phrases and attributes as you read them, but you will also find a lot of differences in the context, level of abstraction, and wording [5].
However, at least all definitions agree that SOA is a paradigm for improved flexibility. Here are some definitions
 A paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains. It provides a uniform means to offer, discover, interact with and use capabilities to produce desired effects consistent with measurable preconditions and expectations.
- OASIS (the Organization for the Advancement of Structured Information Standards)
 In computing, service-oriented architecture (SOA) provides methods for systems development and integration where systems group functionality around business processes and package these as interoperable services. An SOA infrastructure allows different applications to exchange data with one another as they participate in business processes. Service-orientation aims at a loose coupling of services with operating systems, programming languages and other technologies which underlie applications. [6] SOA separates functions into distinct units, or service [7]. which developers make accessible over a network in order that users can combine and reuse them in the production of business application [8]. These services communicate with each other by passing data from one service to another, or by coordinating an activity between two or more services.
- Wikipedia
 SOA is not a concrete architecture: it is something that leads to a concrete architecture. You might call it a style, paradigm, concept, perspective, philosophy, or representation. That is, SOA is not a concrete tool or framework you can purchase. It is an approach, a way of thinking, a value system that leads to certain concrete decisions when designing a concrete software architecture.[9]
3.2 Concepts
Here are the key technical concepts of SOA that allow it to cope with the system characteristics just described [10]:
 Services
Software development is the art of abstraction. We have to abstract reality in such a way that only the relevant aspects of a problem are handled. However, we all know that we can abstract from different perspectives. SOA aims to abstract by concentrating on the business aspects of a problem. The fundamental term introduced here is service. In essence, a service is an IT representation of some business functionality. The goal of SOA is to structure large distributed systems based on the abstractions of business rules and functions.
This gives a clear structure to the IT systems we design and develop. Although internally they are, of course, technical systems, the external interfaces should be designed in such a way that business people can understand them. Externally, you should not see the technical details. The smart consequence of this approach is that at this level of abstraction, platform-specific details don't matter. Thus, platforms can be heterogeneous.
Besides this broad definition, it is not clear what exactly a service is or can be. There are very different opinions about the exact attributes a service must, can, or should have. I will discuss services in detail in the next chapter (presenting several different existing definitions for services as well). As a rule of thumb, however, you can consider a service to be the IT representation of self-contained business functionality, such as "create a customer," "get a customer's contracts," "transfer money," "turn on the radio," "calculate the best route for my car," and so on.
 Interoperability
With heterogeneous systems, the first goal is to be able to connect those systems easily. This is usually called "high interoperability." High interoperability is not a new idea. Before SOA, we had the concept of enterprise application integration (EAI), and regarding interoperability, SOA is nothing new.
However, for SOA, high interoperability is the beginning, not the end. It is the base from which we start to implement business functionality (services) that is spread over multiple distributed systems.
 Loose coupling
As I've already mentioned, we live in a world ruled by marketing guys. We don't always have time to analyze, design, and implement carefully. We need fast times to market, so flexibility is often valued over quality. This leads to several problems.
Consider that at the same time we are integrating more and more systems, and implementing business processes by distributing them over different systems. In principle, data flows in such a way that processes run successfully in all the affected systems: we create a customer in all our systems, transfer money from one system to the other, or process a customer's order by shipping a product and sending a bill.
3.3 Objectives
The upcoming set of sections describes each of these strategic goals:
Overall goals [11]:
 Increased Intrinsic Interoperability
Interoperability refers to the sharing of data. The more interoperable software programs are, the easier it is for them to exchange information. Software programs that are not interoperable need to be integrated. Therefore, integration can be seen as a process that enables interoperability. A goal of service-orientation is to establish native interoperability within services in order to reduce the need for integration.
 Increased Federation
A federated IT environment is one where resources and applications are united while maintaining their individual autonomy and self-governance. SOA aims to increase a federated perspective of an enterprise to whatever extend it is applied. It accomplishes this through the widespread deployment of standardized and composable services each of which encapsulates a segment of the enterprise and expresses it in a consistent manner.
 Increased Vendor Diversification Options
Vendor diversification refers to the ability an organization has to pick and choose “best-of-breed” vendor products and technology innovations and use them together within one enterprise. It is not necessarily beneficial for an organization to have a vendor-diverse environment; however, it is beneficial to have the option to diversify when required. To have and retain this option requires that its technology architecture not be tied or locked into any one specific vendor platform (Figure 3).

Figure 3 A service composition consisting of three services.
 Increased Business and Technology Domain Alignment
The extent to which IT business requirements are fulfilled is often associated with the accuracy with which business logic is expressed and automated by solution logic. Although initial application have traditionally been challenging to keep applications in alignment with business needs when the nature and direction of the business changes.
Service-oriented computing introduces a design paradigm that promotes abstraction on many levels. One of the most effective means by which functional abstraction is applied is the establishment of service layers that accurately encapsulate and represent business models. By doing so, common, pre-existing representations of business logic can exist in implemented form as physical services
System goals [12]:
 Flexibility
 Scalability
 Fault tolerance
The key to fulfilling these goals is loose coupling. Loose coupling is the concept of minimizing dependencies. When dependencies are minimized, modifications have minimized effects, and the systems still runs when parts of it are broken or down. Minimizing dependencies contributes to fault tolerance and flexibility, which is exactly what we need.
In addition, loose coupling leads to scalability. Large systems tend to challenge limits. Therefore, it is important to avoid bottlenecks; otherwise, growing might become very expensive. Avoiding bottlenecks is important from both a technical and an organizational point of view. All large systems only work if the usual business can be done in as decentralized a manner as possible. One way to introduce loose coupling is to avoid introducing any more centralization than is necessary (unfortunately, you need some centralization to establish SOA because you need some common base).
 Needs:
Having read that the key technical concepts for SOA are services, interoperability, and loose coupling, you might conclude that all you have to do to enable SOA is to introduce services, interoperability, and loose coupling [13]:.
But as I stated earlier, you can't buy SOA. What's important is that you introduce these concepts in the appropriate fashion. That is, you have to find the right degree of centralization, you have to set up the corresponding processes, and you have to do your homework. A lack of these "ingredients" is what I most often find as the problem in real SOA projects. To establish SOA successfully, you have to care for your infrastructure, architecture, and processes (including the metaprocess, governance).
 Infrastructure
Infrastructure is the technical part of SOA that enables high interoperability. The infrastructure of a SOA landscape is called an enterprise service bus (ESB). This term is taken from enterprise application integration, where it was called the EAI bus or just enterprise bus.
The key feature of the ESB is that it enables you to call services between heterogeneous systems. Its responsibilities include data transformation, (intelligent) routing, dealing with security and reliability, service management, monitoring, and logging.
 Architecture
Architecture is necessary to restrict all the possibilities of SOA in such a way that it leads to a working, maintainable system. SOA concepts, SOA tools, and SOA standards leave room for specific decisions that you must make in order to avoid a mess. You have to classify different types of services, you have to decide on the amount of loose coupling, you have to restrict the data model of service interfaces, you have to define policies, rules, and patterns, you have to clarify roles and responsibilities, you have to decide on the infrastructure technology, you have to decide which (version of) standards to use, and so on.
 Processes
One thing that makes large systems complicated is that many different people and teams are involved in them. As a consequence, it is a long path from an initial business idea or requirement to a solution running in production mode.
 Governance
The metaprocess of all processes and a SOA strategy as a whole is governance. You have to set up the right process to establish SOA in your organization. This includes finding the right people who are able to combine all the different SOA ingredients to create a result that works and is appropriate. There is usually a central team (sometimes called the SOA competence center) that deals with infrastructure, architecture, and processes. This team is also responsible for establishing a common understanding, and doing the homework right. This requires management support, because in addition to time and resources, courage is required to deal with the organizational impacts of SOA Understanding, governance, management support, and homework are key factors for the success of SOA.
3.4 Benefits:
[14] An SOA can be evolved based on existing system investments rather than requiring a full-scale system rewrite. Organizations that focus their develop¬ment efforts around the creation of services, using existing technologies, combined with the component-based approach to software development will realize several benefits.
 Leveraging existing assets. This benefit is the first, and most important, of the requirements discussed earlier in this paper. You can construct a business service as an aggregation of existing components, using a suitable SOA framework and made available to your enterprise. Using this new service requires knowing only its interface and name. The service’s implementation specifics (such as its component architecture) or discrete functional components—as well as the complexities of the data flow through the components that make up the service—are transparent to callers. This component anonymity lets organizations leverage current investments, building services from a conglomeration of components built on different machines, running different operating systems, developed in different programming languages. Legacy systems can be encapsulated and accessed using Web services interfaces. More important, legacy systems can be transformed, adding value as their functionality is transformed into services.
 Infrastructure as a commodity. Infrastructure development and deployment will become more consistent across all your different enterprise applications. Existing components, newly developed components and components purchased from a range of vendors can be consolidated within a well-defined SOA framework. Such an aggregation of components will be deployed as services on the existing infrastructure. As a result, the underlying infrastructure becomes more of a commodity. Over time, as services become more loosely coupled from the supporting hardware, you can optimize the hardware because the service assembler is no longer dependent upon the hardware environment on which the service operates at run time.
 Faster time-to-market. Organizational Web services libraries will become your organization’s core assets as part of your SOA framework. Building and deploying services with these Web services libraries will reduce your time to market dramatically, as new initiatives reuse existing services and components, reducing design, development, testing and deployment time in the process. As services reach critical mass in your organization or trusted network, the larger ecosystem emerges — enabling you to assemble composite applications using services, rather than developing custom applications.
 Reduced cost. As business demands evolve and new requirements are introduced, the cost to enhance and create new services by adapting the SOA framework and the services library, for both existing and new applications, is greatly reduced. The learning curve for the development team is reduced as well, as they may already be familiar with the existing components.
 Risk mitigation. Reusing existing components reduces the risk of introducing new failures into the process of enhancing or creating new business services. You will also reduce the risk in the maintenance and management of the infrastructure supporting the services.
 Continuous business-process improvement. An SOA allows a clear representation of process flows identified by the order of the components used in a particular business service—and provides business users with an ideal environment for monitoring business operations. Process modeling is reflected in the business service. Process manipulation is achieved by reorganizing the pieces in a pattern (components that constitute a business service). This function allows you to change the process flows while monitoring the effects to facilitate continuous improvement.
3.5 The future of SOA
So far, this white paper discussion centers around the need to increase speed of business changes, and to improve business performance and efficiency. These requirements mandate a set of IT imperatives for flexibility where SOA becomes a key enabler. But what if a completely new model for application development emerges? Will the notion of an SOA still be meaningful or required? The answer is a resounding, yes. Two new, emerging concepts are beginning to be implemented: grid computing and on demand computing. While these models are distinct and have developed separately, they are closely related; and each makes the evolution to SOA even more imperative. Representing every application, resource or business capability as a service with a standardized interface allows you to quickly combine new and existing applications to address changing business needs and improve operational effectiveness — the essence of SOA. As a result, SOA becomes the DNA of grid computing and on demand computing.
 Grid computing
An in-depth discussion of grid computing is beyond the scope of this paper, but a couple of points are worth mentioning. First, grid computing is much more than just the application of large numbers of millions of instructions per second (MIPS) to effect a computing solution to a complex problem. It enables you to divide resources into multiple execution environments by applying one or more concepts, such as hardware or software partitioning, or time-sharing, machine simulation, emulation and quality of service. This virtualization, or on demand deployment, of all your distributed computing resources lets you use them wherever and however they are needed within the grid. Virtualization is simply a form of resource management for devices, storage, applications, services or data objects. Hence, applying SOA allows you to maximize resource utilization in a grid environment. You can deploy and migrate a services ecosystem onto appropriate nodes in a grid environment to respond efficiently to changes in your internal and external business environment.
 On demand computing
An in-depth discussion of on demand computing is also beyond the scope of this paper. But, again, SOA can be an essential prerequisite for on demand computing. SOA is an enabling architecture for on demand applications. Thus, applications must operate in an SOA to realize the benefits of on demand. Web service is an enabling technology for SOA. As a subset of on demand computing, Web services on demand is simply business services exposed using Web services standards.
On demand computing can cover a wide spectrum. One end of this spectrum focuses on the application environment; the other end focuses on the operating environment, which includes items like infrastructure and autonomic computing. Transforming your business means leveraging both the application and operating environments to create an on demand business. At the heart of your on demand business will be business services on demand where application-level services can be discovered, reconfigured, assembled and delivered on demand, with just-in-time integration capabilities.
The promise of Web services as an enabling technology is that it will enhance business value by providing capabilities such as services on demand, and over time, will transform the way IT organizations develop software. It could even transform the way business is conducted and the way you offer your products and services over the Web to your entire value chain. What if all of your applications shared the same transport protocol? What if they all under¬stood the same interface? What if they could participate in, and understood, the same transaction model? What if this were true of your partners? Then you would have applications and an infrastructure to support an ever-changing business landscape—and you would have become an on demand business. Web Services and SOA can make this possible for applications.
4 What are the major differences and similarity between these two approaches?
The increased speed and scale of IT-enabled processes has been met with a proportional increase in the demand to modify processes to meet changing conditions. IT has accelerated the speed at which citizens, businesses, and organizations both operate and change.
The major difference between Component-Based Engineering and Service-Oriented Engineering is different architecture, for different needs of customers, the fundamental shift that will allow these visions to be realized is a move to Service Component-Based Architecture (SCBA). Today, the IT industry has generally accepted Service Oriented Architecture (SOA) as the most promising architectural approach to-date. SCBA complements traditional SOA approaches and is designed to provide an optimal, long-term service-oriented approach aligned with the FEA that recognizes the value of component-based service delivery. SCBA builds upon SOA in three key ways:
• it is tightly integrated with the Federal Enterprise Architecture,
• it provides a description of what the architecture is (a collection of services designed and implemented to achieve an organization’s mission)
• It identifies the organizational, cultural, and process elements, as well as technological elements, that need to exist for these architectures to be successful.
SCBA also treats business processes and the IT systems in the same way, allowing both to be reused across organizations. In order for a business process or technical system to be a “Service Component,” and thus participate in the overall architecture, it must offer a well-defined interface with well-defined functionality. These two characteristics represent the minimum criteria needed for a business process or technical system to be reused. Service Components are intended be a subset of the “components” defined in the FEA SRM. The SRM does not require rigorous interface or functionality descriptions, only systems and processes with these descriptions are both SRM Components and SCBA Service Components. SCBA attempts to realize the potential of the SRM by requiring that business processes and IT systems be designed or modified to make them easy to reuse. Later sections of this document will describe SCBA in further detail.
In the mid-90s, an additional development emerged: component based development (CBD). CBD takes the concept of abstraction in a new direction. Rather than reducing lines of code, CBD separates various aspects of the functionality into isolated units that can be produced and managed independently of the other aspects. This again allows a developer or consumer of the functionality to deal with one aspect at a time – ignoring the other aspects. In a component-based architecture the various aspects are organized into layers, most commonly: presentation, orchestration, business logic, data management, security, and infrastructure.
Service-oriented architecture represents a generalization of the component model by dealing directly with what is offered, rather than how it is packaged. The tiered architecture enables components to be easily incorporated in solution architectures. The evolution of services standards (e.g., WSDL, UDDI, and SOAP) and the maturity of distributed computing architectures (e.g., Java Enterprise Edition and .Net) have enabled "single-copy reuse" via shared services. Thus, SOA is a tiered framework that empowers solution developers to employ abstraction techniques, at all architectural tiers, without having to struggle with many of the interoperability and multiple implementation challenges faced by previous generations of reuse proponents. The future of software development will likely consist of complete assembly of applications from services and components – often referred to as “true software manufacturing.”
Figure 4 Evolution of Reuse in Software Development
Software components are units of software that provide business or technical functionality. These units are independently deployable; that is, they are self-contained and can be deployed virtually anywhere on the network. Business components execute business logic, enforce business rules, and manage corporate data. Technical components provide the platform or infrastructure capabilities that the business components rely on such as messaging, error handling, security, etc.
 Components
Software components are the reusable building blocks for application development. A software component typically consists of: (1) a specification (process and data model representing the user or consumer’s view) that defines what the component does, (2) an implementation which is the internal design for the component, (3) an executable (run-time) module that gets deployed, (4) one or more interfaces that provide access to the component’s functionality. The key concept behind components is that the implementation is hidden behind the interface – the consumer of the component does not need to know the details of the implementation to exploit the capabilities offered. Thus, in general components are an approach to provisioning capabilities that are highly flexible. Component-based reuse is illustrated in Figure 5.

Figure 5 Illustration of Component-Based Reuse
 Services
Services are focused on satisfying business or technical requirements based on a provider/consumer model. Services represent a broader concept than components. They are the activities executed in response to a request (or an event) in order to deliver some result. Both concepts employ the notion of an interface that defines the set of activities (or services) offered. However, whereas all components offer functionality as services, not all services are implemented as components. Figure illustrates the distinction between services and components – services are driven from business requirements, whereas components are a method of providing services. For example, one way to implement a service is to put an interface on some legacy functionality. The legacy system may be very unstructured (and not divided into independent components), yet the interface may offer the services required by other and new applications. As discussed in the roadmap section below, creating interfaces to access services from legacy systems is one common way to begin to implement an SOA.

Figure 6 Differences between Services and Components
Services and components enable reuse, although with slightly different twists. Components are typically designed to be redeployed or integrated into multiple different applications. In fact, commercial-off-the-shelf (COTS) components are typically licensed to be embedded in applications. Reuse is achieved by producing multiple instances of the component and building them into applications. Services can be exploited in this way, but also offer the possibility of shared-services – running a single instance of a service that can be called by other applications across the network, as shown in figure 6.
An important additional concept is service discovery, or the ability to find (either manually at design-time or automatically at run-time) and access existing services. Many technologies exist today that enable this, and a coordinated strategy for identifying and categorizing services across the enterprise is critical. In the Federal government, the FEA provides the first step in implementing this strategy. Since services may be thought of as an abstraction of components, it is not too difficult to consider them both when describing reusable government-wide assets.

Figure 7 Illustration of Service-Based Reuse
A summary of the key concepts in CBSE and SOSE is listed in Table 1.
Table 1 Comparison of key concepts in CBSE and SOSE Concepts CBSE SOSE
Concepts CBSE SOSE
Module Component Service
Specification Component Contract Service description
Interface Component interface Service interface
Assembly Component
composition Service
composition
 Module.
In CBSE, components are the building blocks that can be deployed independently and are subject to composition by third party [10]. Based on the formulation by Clemens Szyperski [7], a software component is a unit of composition with contractually specified interfaces and explicit context dependencies only. It can be both fine-grained providing specific functionality and coarse-grained encompassing complicated logics.
In SOSE, services are the building blocks that can be reused and offer particular functionalities. They are generally implemented as coarse-grained discoverable software entities [6], operating on larger data sets, encapsulating business functionality and exposing the functionality to any source that requests the functionality through well-defined interfaces. Thus, the services can be reused and accessed at various levels of the enterprise application and even across enterprises boundaries.
 Specification.
In CBSE, the component specification provides for the clients the definition of the component’s interface, i.e. the operations and context dependencies. Furthermore, an abstract definition of the component’s internal structure is specified for the component providers [10].
In SOSE, the service description is a service contract that advertises the following information: (i)service capabilities - stating the conceptual purpose and expected results of the service; (ii) interface - describing the service signatures of a set of operations that are available to the service requester for invocation; (iii) behavior - describing the expected behavior of a service during its execution; and (iv) quality - describing important functional and nonfunctional service quality attributes [9].
 Interface.
Although both CBSE and SOSE are interface-based in the sense that interfaces are the specifications of access points, the separation between service descriptions and service implementation is more explicit than the separation between component specification and implementation.
 Assembly.
In CBSE, component composition is the process of assembling components using connectors or glue code to form an assembly, a larger component or an application. The components are assembled through the component interfaces and the composition is made out of several component instances that are connected and interact together.
In SOSE, the composite services are built by composing service descriptions. The realization of the service composition is during run time when the service providers are discovered and bound.

Table 1 Summary of similarities and differences of CBSE and SOSE
CBSE SOSE
Process Building system from preexisting components.
Separate development process
of components and system.
More activities involved in design time Building systems from pre-existing services.
Separate development process of services and system. More activities involved in run time
Technology Constrained by component models. Ranging from white box, gray box to black box. Static and dynamic binding between components. Dynamic discoverability is not a major concern Platform independency. Black box. Only dynamic binding between services. Dynamic discoverability
Quality Interoperability concern between heterogeneous components. Achieve component substitutability through explicit specifications. Better predictability Interoperability through universally accepted standards. Achieve service substitutability through service descriptions.
Predictability issue
Composition Homogenous composition. Design time and run time composition and design time composition allows for optimization. Pipe and filter; event mechanism etc. Composition is made out of several component instances Heterogeneous composition. Services are composed at run time.
Pipe and filter; orchestration etc.
Composite services are built by composing service descriptions
5 What are the differences between service components and modern components?
5.1 What is service?
The OASIS SOA Reference Model states [14]:
The noun "service" is defined in dictionaries as "The performance of work (a function) by one for another."
This can mean everything or nothing. As with the term SOA, it is hard to find an exact, useful definition of the term "service" because so many definitions exist. Again, I have collected some of these definitions. You'll find some common phrases and attributes as you read them, but you will also find a lot of differences in the context, level of abstraction, and wording.
 SOA is focused on business processes. These processes are performed in different steps (also called activities or tasks) on different systems. The primary goal of a service is to represent a "natural" step of business functionality. That is, according to the domain for which it's provided, a service should represent a self-contained functionality that corresponds to a real-world business activity. In other words, business people should be able to understand what a service does [6].
 Services exist as physically independent software programs with distinct design characteristics that support the attainment of the strategic goals associated with service-oriented computing. Each service is assigned its own distinct functional context and is comprised of a set of capabilities related to this context [10].
5.2 What is modern component?
Let us review some of the important definitions of software components given by the experts. One of the earliest definitions is given by Gready Booch [15]:
A reusable software component is a logically cohesive, loosely coupled module that denotes a single abstraction.
This definition captures the idea that a reusable component is an encapsulated software module consisting of closely related component elements. Later, Clement Szyperski presented his well-known definition of a software component at the 1996 European Conference on Object-Oriented Programming [16]:
A software component is a unit of composition with contractually specified interfaces and context dependencies only. A software component can be deployed independently and is subject to composition by third parties.
This definition is well accepted in the component-based software engineering community because it highlights the major properties of software components that are not addressed in traditional software modules, such as context independence, composition, deployment, and contracted interfaces. In 2000, a broader, more general notion of software components was defined by Alan W. Brown [17]:
An independently deliverable piece of functionality providing access to its services through interfaces.
A similar idea is also expressed in the unified modeling language (UML) definition [18]:
A component represents a modular, deployable, and replaceable part of a system that encapsulates implementation and exposes a set of interfaces.
Recently, Bill Councill and George T. Heineman gave a new definition to emphasize the importance of a consistent component model and its composition standard in building components and component-based software [19]:
A software component is a software element that confirms to a component model and can be independently deployed and composed without modification according to a composition standard.
To simplify the concept of software components, we classify the notion of software components into three types: (1) reusable modules, (2) reusable components, and (3) composite building blocks [20].
 A reusable module is an independent and deliverable software part that encapsulates a functional specification and implementation for reuse by a third party.
 A reusable component is an independent, deployable, and replaceable software unit that is reusable by a third party based on the unit’s specification, implementation, and well-defined contracted interfaces.
 A composite building block is a reusable component that is developed as a building part to conform a well-defined component model and the accompanying composition standards.
The differences between service components in SOA and modern components in CBSE.
 Comparison in properties[16], [6], [20].
Table 2 Comparison in properties
Properties Software Components in CBSE Services in SOA
Encapsulation: Each component encapsulates a set of closely related data elements and implements coherent functional logic to perform a specific task. Services are abstractions that hide implementation details from the consumers.
Stateless Sometimes, the components are stateful, sometimes are stateless. Sometimes, services are defined as being (ideally) stateless.
Reusable Reusability of software components is the key to the success of component-based software engineering. SOA leads to better reusability because all systems that need a certain functionality just call the same one.
Composable Components are composite if they are developed based on a standard composition method to support component composition. Kinds of business functionality can be broken into smaller steps, which are themselves services.
Vendor-Diverse Hard to reach Vendor- Diversification. Because there maybe some different frameworks or languages among components which are hard to be cohesive systems are usually very heterogeneous. Being able to use different platforms and different products for implementing services.
Interoperable Components are interoperable if they are developed based on standard communication channels and data exchange mechanisms defined in a component model. High interoperability is a core requirement of SOA. In the sense that services can be called from any other systems, they are inherently interoperable.
Independency Software components must be delivered as independent parts that can be replaced under certain conditions. The goal is to minimize dependencies so that a SOA is appropriate for distributed systems with different owners.
Contract-based interfaces An interface between software components defines a contract between the client of an interface and a provider of an implementation for the interface. Communication among services components is based on service contract which is implemented by Web service at the most time.
Deployable Software components are known as deployable if a well defined
deployment approach has been built inside a component to support its deployment Service components are deployable if service contracts among them are well developed to support them for working together.
From the comparison in properties we could infer that:
i. There are some excellent properties the two shard, they are: Encapsulation Composable, Reusable, Interoperable, Independency, Contract-based interfaces and Deployable.
ii. Obviously there are some differences between them including: Status, Vendor-Diverse.
 Comparison in different perspectives
Table 3 Comparison in different perspectives
Perspectives Software Components in CBSE Services in SOA
Base units of system Component-based system consists of composite components. System based on SOA is comprised of composite services.
Component design Component selection, creating, evaluation and testing. Service connection, creation, evaluation and testing.
Contract design Function implementation à Interface connection. Interface design à Function implementation.
Implemented by Various programming languages, frameworks and technologies or something like that is permitted. Mainly Web Service and related technologies.
Development process A dedicated component engineering process is in place to control and manage the construction of components. A service-oriented development process is used to control and manage module development.
Reuse scopes Large reuse scopes encompassing different projects, product lines, organizations or even the programming endeavors of the general public. Reuse of almost every service in the system and the scope of services could be extended by plug-in other services following the same standards.
From the comparison in different perspectives we could infer that:
i. These two design paradigms are all based on reusable, independent, interoperable component. One is software component, the other the service.
ii. Connections among the components are contracts. However the design processes is different, or we could say they are inverse.
iii. They have large scale of reuse and reach a high level of flexibility and interoperability.
iv. Different components are implemented by various technologies.
6 Building SOA-based software system is same as building a component-based system using service components?
I think there are no large differences of the lifecycles between them. We can assume that the service is definitely a unit in the system, like a component, too. Therefore, actually, we are able to adopt the lifecycle processing of component based system which will work effectively in service-oriented system too. There are some effective lifecycle models of component-based system, such as, V development process, Y development process and component-based waterfall development process. Obviously they are suitable for SOA-based software system design. The only potential variations between them are the unit – one is the component, the other the service, and in detail, is the phase of integration of units.
The main emphasis is put on component selection and its integration into the system. This process can require additional efforts. First the selection process should ensure that appropriate components have been selected with respect to their functional and extra-functional properties. This requires verification of the component specification, or testing of some of the component’s properties that are important but not documented. Second, it is a well known fact [8] that even if isolated components function correct, an assembly of them may fail, due to invisible dependencies and relationships between them, such as shared data shared resources. This requires that components integrated in assemblies are tested before they are integrated into the system. At last, the combination of these assemblies must be testes again, since all combined assemblies of correct ones maybe incorrect although the assembly oneself are correct [7].
One of the main reasons is that Particular component model requires a particular architectural framework, and the application is supposed to use this framework. This directly has impact on architectural decisions. For example if the component model requires a client-server architecture style, it is obvious that the application will use that style and not another (for example pipe-filter) [12]. This will put limitations on the system design.
Things seem better in SOA based architecture. Because avoiding normal data transmission among components, we only need to transfer an XML info, which is carried by SOAP and Http, for them to communicate. The pattern of XML info complies a standardized principle. Therefore we are easier to control transmission among different services. In this way, consideration about frameworks like we should consider in the component-based system is not necessary in that no matter what inner framework it is, the output and input is always the standardized XML (Figure 8). Services could send and receive them easily.
However, all these are based on well developed service contracts. Before the information sent out by service, it has to be translated via specific service contract. Then all the information are definitely in a same, concrete and standardized pattern, which will certainly improve the overall effectiveness of the system, because of the time of transformation has been saved.

Figure 8 Role of Web service and service contracts and their relationship.
7 Tools and technologies for building service components
7.1 Visual Basic Extensions, OCX/ActiveX/COM and DCOM from Microsoft
In computer programming, a Visual Basic Extension (commonly abbreviated VBX) or custom control was the component model used in Microsoft Visual Basic versions 1.0 to 3.0. It is still supported in the 16-bit version of version 4.0, but was made obsolete by OCXs. VBX has also been supported in some versions of Borland Delphi.
The VBX specification was created so that developers could extend Visual Basic. According to rumor, Bill Gates reviewed the first version of Visual Basic before release and told the development team that it must have an extensibility mechanism. Since at the time Visual Basic was an interpreted language with limited power compared to C, VBXs which were most often written in C or C++ provided the ability to create very powerful and efficient software which could easily be hooked up to form based user interfaces.
Visual Basic 4.0 added support for the newer OLE Controls or OCXs (which became ActiveX controls), implicitly deprecating VBX controls. OCXs are based on the Component Object Model.
Each version of Visual Basic has come with many controls. By incorporating VBX controls into Visual Basic, Microsoft spawned the first commercially viable market for reusable software components. Third parties have created a large market of custom controls for resale.
VBX components were called "custom controls" because the Microsoft development team envisioned them as visual "control" components like a toggle switch or button. Enterprising third party software component developers saw opportunities to use the VBX specification for non-visual components, such as components for creating ZIP files, manipulating low-level system settings and communicating with TCP/IP.
7.2 IBM Service Component Architecture Explorer Tool
A metadata explorer that presents information about the service component architecture (SCA) services available in a given WebSphere Enterprise Service Bus server or WebSphere Process Server.
SCA Explorer presents information about the SCA services available in a given WebSphere® Enterprise Service Bus (ESB) server or a WebSphere Process Server (WPS). This information includes details such as how to locate and invoke such services (for example, when developing a new application that intends to re-use existing services in the enterprise).
SCA Explorer presents a Web page with tree widgets that allow the user to select an SCA module and "drill down" to see the components inside, their available interfaces, the operations available on such interfaces, the structure of the input and output Service Data Objects (SDOs), and any exceptions that can be raised by such operations. SCA Explorer also displays information about the imports, exports, and references used by such services; binding information, such as EJB JNDI names (Enterprise Java Beans, Java Naming and Directory Interface), Web service ports and endpoints, resource adapters, Java Message Service (JMS) destinations, etc.; and information about the implementation of such services.
With SCA, metadata is expressed via the Service Component Definition Language (SCDL), and an SPI exists that allows one to query this SCDL information. SCA Explorer is a JSP (Java Server Pages)-based application that demonstrates the use of this SPI to obtain information about the available SCA services and display it via HTML. Also included is a command line J2SE version that prints the same information to System.out and a command line tool that uses Eclipse Modeling Framework (EMF) to generate an XML file containing such information. [5]
8 Discussions and justification comments
8.1 What is SOA? Can we buy it?
SOA is not a concrete architecture: it is something that leads to a concrete architecture. You might call it a style, paradigm, concept, perspective, philosophy, or representation. SOA establishes an architectural model that aims to enhance the efficiency, agility, and productivity of an enterprise by positioning services as the primary means through which solution logic is represented in support of the realization of strategic goals associated with service-oriented computing [5]. Therefore, SOA is not a concrete tool or framework you can purchase. It is an approach, a way of thinking, a value system that leads to certain concrete decisions when designing concrete software architecture.
This aspect of SOA has a very important consequence: you can't buy SOA. There is no tool or recipe you can use to make everything work. While applying this paradigm to your concrete situation, you must make specific decisions that are appropriate for your circumstances [11].
8.2 What’s the base system of SOA?
Of course, flexibility is dealt with very differently on different layers and in different components. So, one important question is which kinds of software systems this paradigm is appropriate for. As it turns out, SOA copes well with many difficult-to-handle characteristics of large systems [1].
 Distributed Systems
As businesses grow, they become more and more complex, and more and more systems and companies become involved. There is constant integration and constant change. SOA is well suited to dealing with complex distributed systems. According to the OASIS SOA Reference Model (see [OasisSoaRM06]), it is a paradigm for "organizing and utilizing distributed capabilities."
SOA allows entities that need certain distributed capabilities to locate and make use of those capabilities. In other words, it facilitates interactions between service providers and service consumers, enabling the realization of business functionalities.
 Different Owners
The OASIS SOA Reference Model's definition of SOA continues by stating that those distributed capabilities "may be under the control of different ownership domains." This is a very important point that is often suppressed in SOA definitions. You won't find it in any of the other definitions quoted in this chapter, but it is the key for certain properties of SOA, and a major reason why SOA is not only a technical concept.
SOA includes practices and processes that are based on the fact that networks of distributed systems are not controlled by single owners. Different teams, different departments, or even different companies may manage different systems. Thus, different platforms, schedules, priorities, budgets, and so on must be taken into account. This concept is the key to understanding SOA and large distributed systems in general.
 Heterogeneity
Another very important difference between small and large systems is the lack of harmony. We all know this from experience (although we might not agree about whether it's a natural phenomenon or the result of bad design). Large systems use different platforms, different programming languages (and programming paradigms), and even different middleware. They are a mess of mainframes, SAP hosts, databases, J2EE applications, small rule engines, and so on. In other words, they are heterogeneous.
In the past, a lot of approaches have been proposed to solve the problem of integrating distributed systems by eliminating heterogeneity: "Let's harmonize, and all our problems will be gone," "Let's replace all systems with J2EE applications," "Let's use CORBA everywhere," Let's use MQ series," and so on. But we all know that these approaches don't work. Large distributed systems with different owners are heterogeneous. This is a fact, and therefore something we must accept when designing large distributed solutions.
8.3 How to design service contract?
It is worth singling out Decoupled Contract at this stage because a Web service contract is essentially an implementation of this pattern. When building services as Web service. Service contracts are positioned as physically separate parts of the service architecture (Figure 9). This allows us to fully leverage the technologies to design and develop these contracts independently from the logic and implementations they will eventually represent.

Figure 9 The Web service contract is a physically separated part of a Web service implementation.
To design and develop service contracts is a huge project. So let’s introduce it briefly.
A service contract needs to have the following components [13]:
• Header
o Name - Name of the service. Should indicate in general terms what it does, but not be the only definition
o Version - The version of this service contract
o Owner - The person/team in charge of the service
o RACI
 Responsible - The role/person/team responsible for the deliverables of this contract/service. All versions of the contract
 Accountable - Ultimate Decision Maker in terms of this contract/service
 Consulted - Who must be consulted before action is taken on this contract/service. This is 2-way communication. These people have an impact on the decision and/or the execution of that decision.
 Informed - Who must be informed that a decision or action is being taken. This is a 1-way communication. These people are impacted by the decision or execution of that decision, but have no control over the action.
o Type - This is the type of the service to help distinguish the layer in which it resides. Different implementations will have different service types. Examples of service types include:
 Presentation
 Process
 Business
 Data
 Integration
• Functional
o Functional Requirement (from Requirements Document) - Indicates the functionality in specific bulleted items what exactly this service accomplishes. The language should be such that it allows test cases to prove the functionality is accomplished.
o Service Operations - Methods, actions etc. Must be defined in terms of what part of the Functionality it provides.
o Invocation - Indicates the invocation means of the service. This includes the URL, interface, etc. There may be multiple Invocation paths for the same service. We may have the same functionality for internal and external clients each with a different invocation means and interface. Examples:
 SOAP
 REST
 Events Triggers
• Non-Functional
o Security Constraints - Defines who can execute this service in terms of roles or individual partners, etc. and which invocation mechanism they can invoke.
o Quality of Service - Determines the allowable failure rate
o Transactional - Is this capable of acting as part of a larger transaction and if so, how do we control that?
o Service Level Agreement - Determines the amount of latency the service is allowed to have to perform its actions
o Semantics - Dictates or defines the meaning of terms used in the description and interfaces of the service
o Process - Describes the process, if any, of the contracted service
One of the most challenging questions for component based software engineering is that, has CBSE really been out-fashioned? This could be separated into several sections :
Could SOA solve all the disadvantages of CBSE?
If so, is the cost acceptable?
Are those disadvantages really defective enough to have the users changing the system into new one with SOA?
9 A summary, conclusions, and future directions
For components to be independently deployable, their granularity and mutual dependencies have to be carefully controlled from the outset. For large systems, it becomes clear that components are a major step forward from objects (classes). This is not to say that objects are to be avoided. On the contrary, object technology, if harnessed carefully, is probably one of the best ways to realize component technology. In particular, the modeling advantages of object technology are certainly of value when constructing a component. On the flip side, modeling of component-based systems is still a largely unsolved problem, although there have been some recent inroads (for example, D’Souza and Wills, 1999, and Cheeseman and Daniels, 2000). UML, for instance, is still ill equipped to model component-based designs, though improvements in this area are one of the major goals for the UML 2.0 definition (still in its early phases in early 2002). Under the constant pressure of Moore’s law, the world of software has been expanding to take advantage of exponentially more powerful hardware resources. The resulting solutions reach into ever more areas of business and society, leading to new requirements, new markets, and new overall dynamics at a rapid pace. Software technology responded with a very dynamic evolution. However, components are hard to establish in a world of extreme dynamics. While much in the world of software needs to continue to progress rapidly, certain aspects need to evolve more gradually at a more controlled pace. These include the foundations of software components, including component models and basic technologies. The significant market advantage that can be gained from having third-party component backing for any platform creates the necessary feedback loop. To grow and sustain any such third-party communities, the major drivers of software technology, such as Sun and Microsoft, need to maneuver carefully. Players focusing on supplying components can only be viable if investments can be amortized (and profits drawn) before the rules change again.

Reference
[1] http://www.itworld.com/soa/60169/soa-gets-obituary
[2] C. Szyperski, Component Software. Addison-Wesley Professional, November 2002.
[3] Wikipedia, Service-oriented architecture, http://en.wikipedia.org/wiki/Main_Page.
[4] Ivica Crnkovic1, Stig Larsson2, Michel Chaudron, Component-based Development Process and Component Lifecycle, Information Technology Interfaces, 2005. 27th International Conference on June 20-23, 2005.
[5] CBSE: a Quantitative Approach Miguel Goulão Departamento de Informática – FCT/UNL 2825-114 Monte de Caparica, Portugal
[6]. Nicolai Josuttis, SOA in practise, 1st edition, O’Reilly media, Inc. Aug, 2007, ISBN: 978-0-596-52955-0
[7]. Newcomer, Eric; Lomow, Greg (2005). Understanding SOA with Web Services. Addison Wesley. ISBN 0-321-18086-0.
[8]. Bell, Michael (2008). "Introduction to Service-Oriented Modeling". Service-Oriented Modeling: Service Analysis, Design, and Architecture. Wiley & Sons. pp. 3. ISBN 978-0-470-14111-3.
[9]. Erl, Thomas (2005). Service-oriented Architecture: Concepts, Technology, and Design. Upper Saddle River: Prentice Hall PTR. ISBN 0-13-185858-0.
[10]. Erl, Thomas, SOA: Principles of Service Design, Prentice Hall, 2007, ISBN: 978-0-13-234482-1
[11]. Kishore Channabasavaiah, Kerrie Holley, Edward M. Tuggle, Jr., Migrating to a service-oriented architecture, IBM CorporationSoftware Group, 2007
[12]. Ivica Crnkovic, Michel Chaudron, Stig Larsson, Component-based Development Process and Component Lifecycle, Software Engineering Advances, International Conference on Oct. 2006
[13] Kurt Wallnau, “Dispelling the Myth of Component Evaluation” in Ivica Crnkovic and Magnus Larsson (editors), “Building Reliable Component - Based Software Systems”, Artech House Publisher, 2002.
[14]. http://www.eu-orchestra.org/TUs/SOA/en/html/Unit4_learningObject1.html, OASIS Definition of SOA, 2007, Orchestar.
[15]. Booch, G., Software Components with Ada: Structures, Tools, and Subsystems, 3rd ed.,
Reading, MA: Addison-Wesley, 1993.
[16]. Szyperski, C., Component Software—Beyond Object-Oriented Programming, Reading,
MA: Addison-Wesley, 1999.
[17]. Brown, A. W., Large-Scale, Component-Based Development, Englewood Cliffs, NJ:
Prentice Hall, 2000.
[18]. OMG Unified Modeling Language Specification, Version 1.4, Object
Management Group, 2000.
[19]. Heineman, G. T., and W. T. Councill, (eds.), Component-Based Software
Engineering: Putting the Pieces Together, Reading, MA: Addison-Wesley, 2001.
[20]. Jerry Zeyu Gao, H.-S. Jacob Tsao, Ye Wu, Testing and Quality Assurance for
Component-Based Software, ARTECH HOUSE, INC., 2003, ISBN 1-58053-480-5

Rosario Von Li the Santificator

2009年3月12日星期四

Component API Design Evaluation

2009年3月7日星期六

A Comparative Study: Component-based software engineering V.S. Service-oriented software engineering

关注者

个人友情链接