Explicación de los componentes de software (elementos constituyentes del software), esbozo del desarrollo basado en componentes (CBD), componentes black box (sin acceso al código fuente), componentes de mercado abierto y servicios Web.
According to Merriam-Webster Collegiate® Dictionary, the word Component came into common usage in the English language in 1645. They define a component as:
1: a constituent part : See Ingredient
They go on to talk about the etymology of the word component: Latin component-, componens, present participle of componere to put together.
This definition fits Software Components because they truly are becoming "ingredients of applications", and you "put together" these ingredients to get your job done. The further definition of a software component in today's world is any piece of pre-written code that defines interfaces that can be called to provide the functionality that the component encapsulates. These are typically packaged in "industry standard" ways so that they can be callable from multiple languages, or from multiple environments. Typically components are created as Microsoft® .NET or Microsoft Component Object Model™ (COM) components, Java™ 2 Platform Enterprise Edition (J2EE) or JavaBeans™ components, Borland Delphi™ VCLs, or a number of other lesser known architectures. .NET/COM and J2EE/Java-based components are the most widely used as there are vast numbers of programmers who program in these compatible environments. The new paradigm of assembling components and writing code to make these components work together has a name, and of course an acronym, Component-Based Development (CBD).
Component-Based Development is truly the idea of creating software applications from components. The developer, during the design and specification phase, uses both internally developed components and open-market components to provide as much functionality as they can for their application. The developers then write the additional components needed and the glue code that hooks all the components together. They may put the new components they have created in a company storehouse, or repository, so that others can use the functionality that they have created. This can help lead to Software Reuse which can bring down the costs of development. For example, if a developer creates a component to access a customer in the corporations' database, then no other programmer should have to write that functionality again. They can find that Customer component in their repository, and use it in their applications to do that functionality.
There are two main categories of components, white box components and black box components. White box components are components that are source code. They are readable, and directly changeable by the programmers that use them. Black box components are typically in compiled or binary form. They are discrete components that cannot directly be changed. All the programmer knows about them is the documentation that describes their functionality, and their published "publicly known" interfaces. These interfaces may include properties (or attributes) that can be viewed, or new values placed in them. Secondly, Methods, which allow the component to do a pre-described action. Finally, Events, which trigger when the component wants to notify the programmer that an action has occurred. The benefits of using black box components outweigh those of white box components. Black box components cannot directly be modified by a programmer. They extend the functionality by creating a new "wrapper" components to wrap and extend the existing component. This keeps that original functionality intact so that upgrades, bug fixes, etc, made by the original developer can be implemented. If you were to start changing the source of a white box component you would have a new source stream, and old bugs would not be fixed and propagated to new instances of components.
In the early 90's a new type of component came into existence. These were the commercially available components that could be purchased. ComponentSource coined a new term to describe these types of components: Open Market Components. Open Market Components are reusable components that are available to purchase off the shelf. The components are based on standard component architecture such as COM, or Java and you can buy these components without having to purchase support, integration, or other types of services. They are truly plug-n-play components. I had the pleasure of working on the first commercial open market component in 1991. It was VBTools™ from a company called MicroHelp. It was based around the Microsoft Visual Basic™ component model (or VBXs). That model matured to true COM-based components (OCXs), and now to today's .NET components. There are a plethora of open market components available, 1,000's at this writing, to make a programmer's job easier but allowing them to concentrate on programming their core competency tasks by implementing their corporation defined business processes or functionality instead of having to write all sorts of components or routines to do common things like data display, charting, calculations, algorithms, and many others that are available on the open market. Browse our marketplace and you will get an idea of what I am talking about. Reuse has become a reality because you are able to reuse open market components, which is really just code that someone else has written, tested, and documented.
Web services are a proposed future natural extension of a distributed component environment where the local area network becomes the Internet. Instead of the components of the application sitting on a server, somewhere in the network, they could be sitting somewhere out on the Web. Web services are effectively the component equivalent of a hosted solution. Instead of hosting a complete application, you can simply have individual components hosted. This provides compelling simplicity with respect to deployment, administration and licensing.
Since June 2000 the major platform vendors have announced their proposed offerings here, notably Microsoft's .NET, Sun's Sun ONE, HP's eServices, Oracle's eSpeak and IBM's Websphere program. Full delivery of these technologies, however is still a year away (at the time of writing this article).
Granularity has become a new term that many programmers using components are talking about. Granularity is the word that describes how much functionality a component, or a set of components that work together, provides. For a simplified example, a Fine Grained Component might provide the functionality of adding 3 numbers together, it is also small and compact with low overhead, and most likely not much customizability. Its functionality is very discrete. A Large Grained Component would provide a large piece of functionality. This might be a File Access library, a database component, or framework based "near complete" functionality like a CRM, ERP, eCommerce, or other system. For example, an eCommerce component may provide 80% or 90% of the functionality of a full eCommerce system including registration, shopping cart, catalog services, invoicing, emailing, etc. It can be accessed as a single component but in reality it is a framework of components that are integrated together to provide a large grained solution.
So which is better, fine or large grained. They both have their positives and their negatives. While large grained components may provide a large amount of your application functionality, typically they will not be as customizable as you putting together many different fine grained components. This is usually because the fine grained components are discrete and you end up writing more of the glue code that makes these components work together in the way you want them to. This means, of course, writing more code which can be time consuming. In a large grained component that glue code is written internal to the component with no way for you to customize it. You are left to set the properties/attributes that the developer of the framework allows you to set to customize how the framework works.
As you read the other papers in this section I am sure you will see a cohesive picture come together. Using CBD techniques, your application development process can become streamlined. You can use, purchase, and create reusable assets in the form of components and code. This will bring your development department into the 21st century of programming, a truly collaborative effort that will improve your productivity, and bring all the benefits of reuse, code sharing, and especially time to market issues around developing your applications.