SDA India is an online resource for Software, Development,IT, Architecture, Open Source, Mobile, Security, Databases, Delphi, C, OS, Asp, .Net, Php, Xml, Java
Articles
Enterprise Architectural Principles: Structure of Software Components
In this article we look into component-oriented software development and evaluate it against other recognised principles.
Why Components?
Components are generally used in drag-and-drop application development. The idea is to put together readily configurable components from a central repository and build applications quickly. Although this idea looks impressive on a presentation (or seminar) slide, it is very difficult to put into practice. The component orientation deals with the design of reusable components and the integration of existing components, subsystems, and functions. Besides, CBD improves the quality of software.
What is a Component?
Components can be defined in various ways. For the purpose of this article, we shall concentrate on the definitions of architecturally relevant software component and not JavaBeans. Thus, components can be defined in the following ways:
We can design a simple Java component as per the general definition. In a Java package, the corresponding classes would be distributed. So the next step would be to decide on the tasks to be done, the union of appropriate classes, and bring together the functionaries with one or more interfaces. A simple POJO-Java component consists of the following elements:
According to this definition, the java sql.DriverManager seems to fit the bill of a perfect component. It is about the factory that is authorised for the production of the java.sql.Connection-Instances. The implementation of connection interface need not be visible to the component users who are solely interested in the functioning of the interface. Besides, the Driver Manager would also be highly reusable.
The example described here is about a finely granulated technical component. The peculiarities of a component are comparable to those of a class. The attributes of the class are responsible, just like the persistence of a component, for the capsulation of internal conditions. The public methods of the class correspond to the public interface of a component, while the private methods correspond to the realisation of a component. The construction of a class is comparable to the factory (or locator) of a component, and the component is comparable to a powerful class.
The simple infrastructure functionalities of the interface also contribute to the component’s high reusability.
What is a Professional Component?
Technical components offer professional components a granular and reusable infrastructure. The public interfaces are often so stable, that they can be further abstracted by a framework. An EJB container can be used internally for the persistence of an image. The functionaries of the java.sql package recovers these entirely in the CMP 2.0 container’s persistence manager. The container’s framework offers professional components an outlet environment – a component operating system. It is important to separate the technical details from professional ones, to ensure maintenance of the software. With the recovery of infrastructure in a container (the EJB container, for instance), these demands are naturally met.
A business component concentrates on the image of professional tasks or processes. In such a scenario, the challenge lies not in the implementation of such components, but rather on the identification of concluding and independent parts of a business process, which can be disposed of. The following points need not be taken into consideration while designing professional components:
Professional components concentrate on the functional demands, while the technical infrastructure takes second place. A business component, which depends on the existence of infrastructure services, should be independent of these.
What Constitutes a Good Component?
By now, we have defined the technical and professional components. However, we have yet to mention about their quality. A good component fulfills or surpasses the defined non-functional demands of an application. By non-functional demands, I mean the patterns that need to be put in place to ensure the development of object-oriented component software. The development of components does not in any way increase the maintenance costs.
Information Expert
It helps in evading redundancies. Additionally, it searches for components that are suitable to the image of the professional part. Also, new component candidates are identified when such components cannot be identified.
Low Coupling
The professional components need to be kept independent of the business processes, professional problems, and each other. The lesser they recognise each other, the simpler it is to maintain and extend the component. In an ideal scenario, components of an application can be fully deployed independent of each other. In practice, however, it is difficult to attain such independence, since such professional problems occur very rarely. There are also technical limitations, for example, CMR connections only within an ejb-jar.
High Cohesion
A component should fulfill a common task or responsibility. If this is not the case, it should be replaced with the principle of separation of concerns. A refactoring of the component could lead to dispatching certain responsibilities to other components or to the development of new component candidates. High cohesion is meant for technical as well as professional components. It should be determined on the basis of the component’s responsibility. A technical infrastructure component, which is responsible for the illustration (image) of persistence, is cohesive, if it is composed exclusively of classes, and is determined to accomplish the task.
Logging, connection pooling, and even caching classes are not cohesive and, in this regard, they are often assessed as 'strange body'. Refactoring leads to the creation of new components that are solely responsible for the caching or connection pooling. The simplest thing to do then is to allow component reusability, so other users can use the functionality.
Creator
The user (of the component) is solely interested in the solution. Therefore, she would only be interested in the external view of the component. Now, the question as to who will undertake the authorisation of this interface arises. In the component world, this can be done both explicitly and implicitly. Such an example for implicit authorisation can be seen in the POJO world. The Driver Manager gives the real connection authorisation and passes it on to the user. In the J2EE architecture, allocation of interface authorisation for a component is always explicit. The Business Delegate Pattern relevant to the component user obtains an authorisation to the interface, but through a proxy. The decision on whether to realise the component or not, is left to the EJB container.
Controller
The controller answers questions regarding how the component deals with external inquiries. Although this element has no professional significance, it is solely responsible for the coordination of the classes of a component. The java.sql.DriverManager coordinates with the responsible Driver to obtain the authorisation of a connection and send it back to the requestor. The coordination involves the realisation of a component and acceptance of the external view’s inquiries. In J2EE, the session front undertakes this task. Although the signature technique of the session front and that of Business Delegate are nearly equal, the session front is not in a position to implement the technique of the Business Delegate directly, owing to the J2EE transformation technique of patterns (for example, to the requested java.rmi.RemoteExceptions) and not due to the component design.
Polymorphism
This pattern is less significant for the design of the component’s external view, since the transmission of interfaces of a component is very rare. Moreover, this pattern only assists in the design of component realisation. The bad if-else statements, which are only meant as question type are totally replaced by means of transmission. Such object-oriented components set a limit in a J2EE environment. Here, the persistence layer cannot illustrate the polymorph transparency without any additional expenditure. Any additional expenditure for the illustration of object hierarchy should therefore be checked against a simple extension of the code by avoiding the if-else structure.
Pure Fabrication
Pure fabrication helps to minimise the coupling between independent components from the professional layer. As mentioned earlier, in practice, it is rare to find components that are fully independent of each other. Direct interaction between similar independent components is often necessary. Since the components are responsible for the illustration of professionally independent shared processes or their connections, their public interfaces are divided as per the requirements of the user; therefore, they are often very compelling and yet not fully independent of each other.
The reason for the interaction is not the reuse of the published functionality, but the realisation of the component. The solution for this problem would be either the additional publication of parts of realisation or the allocation of additional layers on the inner part of a component. The publication of additional functionalities with the external view of a component not only damages the capsulation, but also contributes to increased complexity of the interface.
Pure Fabrication suggests the introduction of additional elements that have no professional significance. In our case it could deal with a simple Java interface, which publishes parts of the realisation of the Address Finder of the Customer Directory components. Yet, this interface remains separate from the external view.
Indirection
One could still solve the problem wisely by introducing an artificial class in the Customer Directory. An Address Relation class could undertake the role of the Address class from the Address Finder component, to minimise coupling. Furthermore, the Address Relation class can be tied to the Address class, since its independence is not as critical as the original connection between the customer and the Address class. The capsulation of the Address Relation component will be damaged in this spot; therefore, it will be necessary to introduce a defined interface for the realisation of the Address Finder Component.
Protected Variations
There is an incalculable risk in direct coupling, from the view of a professional component. The variation must therefore be capsulated on this ground. This can be done by introducing an additional layer with stable interfaces (Java interfaces or WSDL, for instance). Of course, the idea of variation or stability depends on the context in which it is applicable. For a professional component the technique of another varying professional component is unstable. On the other hand, the implementation of necessary APIs can prove to be risky for technical component. A consequent application of this component leads to the layering of software, whereby the upper layer recognises the external view of the lower layer.
Don't Talk to Strangers
Components should always be independent of other components. In case the interaction with other component is needed, the provided interfaces should be used for this purpose. The realisation of a component should not be allowed to communicate with other components.
Designing Reusable Components
Reusable components are designed according to a certain set of pre-defined criteria and principles. The strict separation of a component’s external view permits the reusability of the external view while also allowing a transparent exchange in the inner workings of a component for the user. This uncoupling allows extending the inner life, without an accommodation of the external view component reuse is prevented only under certain circumstances such as the following:
The inner structure of a component is not of prime importance for its reuse. Well structured software can be easily understood, extended, and tested. Reusage really depends on the component's task. If the task is simple and fairly self-sufficient, it can be reused by other participants in the process. A component, which is responsible for the image of such tasks, is potentially reusable.
Conclusion
The principles meant for the design of POJO also apply to the design of the components. The main difference lies in the granularity of the public interfaces. The functionality of POJO is very simple compared to the components. Components consist of powerful interfaces that offers users a genuine additional benefit. Delicate and highly reusable POJOs work within a component to provide compelling functionalities. The GRASP pattern helps to combine the POJOs with each other, without damaging the principles of architecture and software development.
Why Components?
Components are generally used in drag-and-drop application development. The idea is to put together readily configurable components from a central repository and build applications quickly. Although this idea looks impressive on a presentation (or seminar) slide, it is very difficult to put into practice. The component orientation deals with the design of reusable components and the integration of existing components, subsystems, and functions. Besides, CBD improves the quality of software.
What is a Component?
Components can be defined in various ways. For the purpose of this article, we shall concentrate on the definitions of architecturally relevant software component and not JavaBeans. Thus, components can be defined in the following ways:
- A component consists of public interfaces, composed of many optional factors, including classes, interfaces, packages, UML Diagrams (graphs), and documentation
- A component consists of more public interfaces and its realisations (or conversions)
- A component will always address its public interfaces
- The interfaces are not visible for users and are therefore interchangeable
We can design a simple Java component as per the general definition. In a Java package, the corresponding classes would be distributed. So the next step would be to decide on the tasks to be done, the union of appropriate classes, and bring together the functionaries with one or more interfaces. A simple POJO-Java component consists of the following elements:
- All classes belonging to the package
- An interface that announces or publishes functionaries of these classes
- The realisation of these interfaces as recoverable or not (as in a sub-package)
- In the case of a factory that implements the interfaces, users of such interface should be tied to it, during the period of use
According to this definition, the java sql.DriverManager seems to fit the bill of a perfect component. It is about the factory that is authorised for the production of the java.sql.Connection-Instances. The implementation of connection interface need not be visible to the component users who are solely interested in the functioning of the interface. Besides, the Driver Manager would also be highly reusable.
The example described here is about a finely granulated technical component. The peculiarities of a component are comparable to those of a class. The attributes of the class are responsible, just like the persistence of a component, for the capsulation of internal conditions. The public methods of the class correspond to the public interface of a component, while the private methods correspond to the realisation of a component. The construction of a class is comparable to the factory (or locator) of a component, and the component is comparable to a powerful class.
The simple infrastructure functionalities of the interface also contribute to the component’s high reusability.
What is a Professional Component?
Technical components offer professional components a granular and reusable infrastructure. The public interfaces are often so stable, that they can be further abstracted by a framework. An EJB container can be used internally for the persistence of an image. The functionaries of the java.sql package recovers these entirely in the CMP 2.0 container’s persistence manager. The container’s framework offers professional components an outlet environment – a component operating system. It is important to separate the technical details from professional ones, to ensure maintenance of the software. With the recovery of infrastructure in a container (the EJB container, for instance), these demands are naturally met.
A business component concentrates on the image of professional tasks or processes. In such a scenario, the challenge lies not in the implementation of such components, but rather on the identification of concluding and independent parts of a business process, which can be disposed of. The following points need not be taken into consideration while designing professional components:
- The external view of a professional component (that is the public interface) should offer users a surplus value
- The external view must be kept as simple as possible
- The connection between the external view of a component and its professional requirements (eg. usecasediagrams and business processes) must be distinguishable
- The professional component should always exist in a professionally consistent condition. The connection of the component interface transforms a component from one consistency into another. A professional component is therefore capable of transactions
Professional components concentrate on the functional demands, while the technical infrastructure takes second place. A business component, which depends on the existence of infrastructure services, should be independent of these.
What Constitutes a Good Component?
By now, we have defined the technical and professional components. However, we have yet to mention about their quality. A good component fulfills or surpasses the defined non-functional demands of an application. By non-functional demands, I mean the patterns that need to be put in place to ensure the development of object-oriented component software. The development of components does not in any way increase the maintenance costs.
Information Expert
It helps in evading redundancies. Additionally, it searches for components that are suitable to the image of the professional part. Also, new component candidates are identified when such components cannot be identified.
Low Coupling
The professional components need to be kept independent of the business processes, professional problems, and each other. The lesser they recognise each other, the simpler it is to maintain and extend the component. In an ideal scenario, components of an application can be fully deployed independent of each other. In practice, however, it is difficult to attain such independence, since such professional problems occur very rarely. There are also technical limitations, for example, CMR connections only within an ejb-jar.
High Cohesion
A component should fulfill a common task or responsibility. If this is not the case, it should be replaced with the principle of separation of concerns. A refactoring of the component could lead to dispatching certain responsibilities to other components or to the development of new component candidates. High cohesion is meant for technical as well as professional components. It should be determined on the basis of the component’s responsibility. A technical infrastructure component, which is responsible for the illustration (image) of persistence, is cohesive, if it is composed exclusively of classes, and is determined to accomplish the task.
Logging, connection pooling, and even caching classes are not cohesive and, in this regard, they are often assessed as 'strange body'. Refactoring leads to the creation of new components that are solely responsible for the caching or connection pooling. The simplest thing to do then is to allow component reusability, so other users can use the functionality.
Creator
The user (of the component) is solely interested in the solution. Therefore, she would only be interested in the external view of the component. Now, the question as to who will undertake the authorisation of this interface arises. In the component world, this can be done both explicitly and implicitly. Such an example for implicit authorisation can be seen in the POJO world. The Driver Manager gives the real connection authorisation and passes it on to the user. In the J2EE architecture, allocation of interface authorisation for a component is always explicit. The Business Delegate Pattern relevant to the component user obtains an authorisation to the interface, but through a proxy. The decision on whether to realise the component or not, is left to the EJB container.
Controller
The controller answers questions regarding how the component deals with external inquiries. Although this element has no professional significance, it is solely responsible for the coordination of the classes of a component. The java.sql.DriverManager coordinates with the responsible Driver to obtain the authorisation of a connection and send it back to the requestor. The coordination involves the realisation of a component and acceptance of the external view’s inquiries. In J2EE, the session front undertakes this task. Although the signature technique of the session front and that of Business Delegate are nearly equal, the session front is not in a position to implement the technique of the Business Delegate directly, owing to the J2EE transformation technique of patterns (for example, to the requested java.rmi.RemoteExceptions) and not due to the component design.
Polymorphism
This pattern is less significant for the design of the component’s external view, since the transmission of interfaces of a component is very rare. Moreover, this pattern only assists in the design of component realisation. The bad if-else statements, which are only meant as question type are totally replaced by means of transmission. Such object-oriented components set a limit in a J2EE environment. Here, the persistence layer cannot illustrate the polymorph transparency without any additional expenditure. Any additional expenditure for the illustration of object hierarchy should therefore be checked against a simple extension of the code by avoiding the if-else structure.
Pure Fabrication
Pure fabrication helps to minimise the coupling between independent components from the professional layer. As mentioned earlier, in practice, it is rare to find components that are fully independent of each other. Direct interaction between similar independent components is often necessary. Since the components are responsible for the illustration of professionally independent shared processes or their connections, their public interfaces are divided as per the requirements of the user; therefore, they are often very compelling and yet not fully independent of each other.
The reason for the interaction is not the reuse of the published functionality, but the realisation of the component. The solution for this problem would be either the additional publication of parts of realisation or the allocation of additional layers on the inner part of a component. The publication of additional functionalities with the external view of a component not only damages the capsulation, but also contributes to increased complexity of the interface.
Pure Fabrication suggests the introduction of additional elements that have no professional significance. In our case it could deal with a simple Java interface, which publishes parts of the realisation of the Address Finder of the Customer Directory components. Yet, this interface remains separate from the external view.
Indirection
One could still solve the problem wisely by introducing an artificial class in the Customer Directory. An Address Relation class could undertake the role of the Address class from the Address Finder component, to minimise coupling. Furthermore, the Address Relation class can be tied to the Address class, since its independence is not as critical as the original connection between the customer and the Address class. The capsulation of the Address Relation component will be damaged in this spot; therefore, it will be necessary to introduce a defined interface for the realisation of the Address Finder Component.
Protected Variations
There is an incalculable risk in direct coupling, from the view of a professional component. The variation must therefore be capsulated on this ground. This can be done by introducing an additional layer with stable interfaces (Java interfaces or WSDL, for instance). Of course, the idea of variation or stability depends on the context in which it is applicable. For a professional component the technique of another varying professional component is unstable. On the other hand, the implementation of necessary APIs can prove to be risky for technical component. A consequent application of this component leads to the layering of software, whereby the upper layer recognises the external view of the lower layer.
Don't Talk to Strangers
Components should always be independent of other components. In case the interaction with other component is needed, the provided interfaces should be used for this purpose. The realisation of a component should not be allowed to communicate with other components.
Designing Reusable Components
Reusable components are designed according to a certain set of pre-defined criteria and principles. The strict separation of a component’s external view permits the reusability of the external view while also allowing a transparent exchange in the inner workings of a component for the user. This uncoupling allows extending the inner life, without an accommodation of the external view component reuse is prevented only under certain circumstances such as the following:
- Simple entities like Customer or Address are defined only rarely within an undertaking since the attribute, behaviour, and structure of such entities often vary between different projects
- For political reasons, different projects concentrate jointly on the image of their own professionalism, instead of developing a general functionality
- Reusable components demand higher quality of code, allocation of test scenarios, good documentation, and a person who will attend to the adherence of these demands. In the real world, this task is very unpopular
- The functional demands are rarely defined. It is not uncommon to see an employer who is unaware of what exactly an application does, even though the delivery timeline of the software is not far away. The external view of the component must also be accommodated by vast changes
- Developers are not always enthused by the idea of designing a software with the aid of patterns, interfaces and layers (their typical response is that, "we'll refactorise later"). Instead, major parts of the software are reused with the help of drag-and-drop. This is responsible for high redundancies, increased susceptibility to errors, and also for the bad serviceability of the software
The inner structure of a component is not of prime importance for its reuse. Well structured software can be easily understood, extended, and tested. Reusage really depends on the component's task. If the task is simple and fairly self-sufficient, it can be reused by other participants in the process. A component, which is responsible for the image of such tasks, is potentially reusable.
Conclusion
The principles meant for the design of POJO also apply to the design of the components. The main difference lies in the granularity of the public interfaces. The functionality of POJO is very simple compared to the components. Components consist of powerful interfaces that offers users a genuine additional benefit. Delicate and highly reusable POJOs work within a component to provide compelling functionalities. The GRASP pattern helps to combine the POJOs with each other, without damaging the principles of architecture and software development.
Adam Bien is a freelance Consultant, Asst. Professor and the co-author of Stress Enterprise Architecture, Frameworks and J2EE. He has worked on Java since JDK 1.0, and
Related Links
None
