1 Hardware Component Model: The Component Model Of Hardware in Software Haluk A. Guner [email protected]Technical Report BBKCS-05-04 School of Computer Science and Information Systems Birkbeck College, University of London, Malet Street, London, WC1E 7HX, UK Abstract. Achieving a degree of reuse commonly associated with hardware components is an elusive, yet conceivable goal in the object-oriented reuse community. There is considerable merit and potential advantage to be gained in identifying features of the hardware model that can be transferred successfully to a software architecture. In this paper, we describe a high-level, abstract software definition of a hardware model; the resulting component model is independent of any language or platform. The model also provides an alternative to common distributed component architectures such as Enterprise Java Beans. We describe our prototype implementation of the model using a common application and demonstrate how that model can provide concrete reuse benefits. Keywords: software reuse, software component model, component-based software development.
Transcript
1
Hardware Component Model: The Component Model Of Hardware in Software
School of Computer Science and Information Systems Birkbeck College, University of London, Malet Street, London, WC1E 7HX, UK
Abstract. Achieving a degree of reuse commonly associated with hardware components is an elusive, yet conceivable goal in the object-oriented reuse community. There is considerable merit and potential advantage to be gained in identifying features of the hardware model that can be transferred successfully to a software architecture. In this paper, we describe a high-level, abstract software definition of a hardware model; the resulting component model is independent of any language or platform. The model also provides an alternative to common distributed component architectures such as Enterprise Java Beans. We describe our prototype implementation of the model using a common application and demonstrate how that model can provide concrete reuse benefits. Keywords: software reuse, software component model, component-based software development.
2
Contents 1 Introduction 2 The Argument 3 The Reference Model 4 Hardware Component Model (HCM)
4.1 Elements of HCM 4.2 The Type System 4.3 Construction of an Example HCM Component 4.4 HCM Markup Language (HML)
5 The Implementation 5.1 Implementation of the Prototype HCM system 5.2 Implementation of the Reference Application
6 Comparison of HCM & EJB Models 6.1 High Level Comparison of the Models in General 6.1.1 Component Types 6.1.2 Elements (Building blocks) 6.1.3 Construction of Stateless Components 6.1.4 Construction of Stateful Components 6.1.5 Client Usage
6.2 Structural Differences of the EJB and the HCM Models and their respective Advantages and Disadvantages 6.3 Comparison with the Java Data Objects (JDO) as an Alternative Persistence Mechanism 6.4 Comparison in terms of the Reference Application Implementations
7 Evaluation of the Results 8 Related Work 8.1 Distributed Component Architectures 8.2 Data Flow Computing 9 Conclusion References Appendix A - xPetStore Appendix B - Generic System Process (Sys-Proc) and HCM Composition Language (HCL) Appendix C - The High Level Specification of hPetStore
3
1 Introduction The existence of the software crisis that we are still trying to overcome has been recognised as early as 1968 [NR69]. 1968 was also the year since which, with the publication of Douglas McIlroy's classic paper [McI68], software components became the silver bullet for software engineering [Bro87]. It is generally agreed that in order to overcome this crisis, software construction would need to be treated as a genuine engineering discipline [PS96, Szy02]. In any mature engineering discipline, new products are rarely developed from scratch. Instead, products are composed out of readily available components. Reuse was effectively born with the invention of subroutines in order to allow programmers to execute repeating code segments more than once with different parameters [Cle95]. Hence, libraries of generally-useful subroutines was the first real attempt at reuse. The concept of module, as introduced by the modular languages Modula-2 [Wir82] and Ada [TD97] was the next attempt to improve reuse. In Ada, modules are called packages, but the concepts are almost identical [Szy00]. Since the term module is overloaded, we take the example of [BDW03] and follow the definitions of Modular Smalltalk [WW88] and Szyperski [Szy92]. A module is a program unit (capsule) that;
• contains (definitions of) items • manages the visibility and accessibility of items • draws a strong boundary between items defined inside it and items defined outside in other
modules • supports separate compilation and type-checking across boundaries
While modules gave us the ability to partition systems into independent units which can be developed and tested separately, it was very hard to customise them [WD02]. For instance calling a function from a library is easy, but it's very hard to customise them when a slightly different version is needed. This was due to the fact that a form of delegation is the only composition mechanism that is supported by the module mechanism [WD02]. Since other modules are referred to by name, hard-wired module dependencies was also a problem, which makes it impossible to plug in a module with a different name but a compatible specification [Zen02]. With its new composition mechanisms, such as aggregation and inheritance, object-oriented programming represented the next serious attempt in solving the reuse problem[WD02]. These new mechanisms made it more easy to reuse existing code without rewriting it. Despite the improvements, object orientation isn't without its own set of problems. It has been argued [PS96] that focusing on individual objects is misleading and often results in software that cannot be used as components. Nierstrasz [Nie93] traces the main shortcomings of the object-oriented programming languages to two phenomena: (i) the lack of general support for composition, and (ii) the semantic interference between the operational and compositional aspects of the object-oriented programming. Other composition mechanisms made important contributions in improving the existing Object Oriented technology; such as Subject Oriented Programming [Har93], Adaptive programming [Cza00], Generative Programming [Cza00], Aspect-Oriented Programming [KLM97] and multi-dimensional separation of concerns [TOH99]. Generally speaking, despite all these valuable contributions, it was clear that OOP was not the silver bullet [Nie04] and it didn't completely live up to its promise to deliver general reusability [WD02]. Worse, OOP has a much steeper learning
4
curve than conventional procedural programming and achieving reuse with OOP is much harder than with simple libraries of procedures [Lov93]. Component-based software development, which promises to be the enabling technology for the on-time development of high-quality and reliable systems by the composition of pre-built software components, has now been recognised as the next general solution for the reuse problem [HC01, LS00, NM95, TC03]. For a common understanding of what a component is (and more appropriately, is not) we shall adopt Szyperski’s definition [Szy00]: 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. In 1986, Leveson made the following observation regarding software safety [Lev86]: "A fair conclusion might be that why is well understood, what is still subject to debate, and how is completely up in the air". Today, the state of component-oriented programming is summarised accurately by the following observation [FF01], which draws parallels with the above observation: “There is broad agreement that component-oriented programming is good, but there is much less agreement on what component-oriented programming is and certainly none on how to do component-oriented programming.” There are two main aspects of component based development [LSS02, TC03]: (i) the specification and implementation of the components and (ii) the composition of these components into composite solutions or applications. So far, much of the research has focused on the first category resulting in a diverse set of component models (JavaBeans [Sun97], Enterprise JavaBeans (EJB) [EJB01], CORBA Component Model (CCM) [CCM02], COM [Com95] and .NET [Net99]). However, much less effort is spent in investigating appropriate techniques that allow application developers to express applications flexibly as compositions of components. More recently, research has progressed towards the development of composition approaches resulting in a number of composition languages (Piccola [AN99, ALS01], QSoul [WD02]) and architecture description languages (Aesop, Darwin, Rapide, UniCon [SEI, MT97]). The position taken by this research is that these two aspects of components, treated separately so far, are in fact highly interlinked. The ultimate decision of exactly what a software component is and how it should be defined, will invariably have an effect on the ways that it can be composed to create new solutions. The argument is also valid from the point of view of composition. A really flexible and effective composition mechanism is very likely to impose some restrictions on the way these components are defined and built. Hence, we believe that there are considerable advantages to be gained from treating the component model as an inseparable whole. In order to treat our discipline as a genuine engineering discipline as has been suggested [PS96, Szy02], first, we must understand these more established engineering disciplines. Especially, we need to appreciate the essence of their proven component models. This is exactly the approach followed in this research. We chose the hardware engineering discipline and its component model as our target. First we identified the distinguishing features and important qualities of the hardware component model as a whole, and then tried to replicate it in software.
5
The remainder of the paper is organized as follows. The next section presents the main argument of this research. This is followed in section 3 by the presentation of the abstract reference model and its characteristic qualities that are identified to be important. Section 4 introduces the actual model itself. It starts with a high level overview of the main elements (building blocks) of the system. This is followed by the detailed introduction of the type system. Another subsection demonstrates the step by step construction of an example Hardware Component Model (HCM) component and the section concludes with the formal definition of the HCM markup language which allows for the description and definition of all system and user data in the model. Section 5 discusses the implementation of the prototype HCM system and the subsequent implementation of the chosen reference application that is implemented using this prototype. Section 6 presents a detailed comparison of the EJB and HCM component models. We start with a high level comparison of the models in general and continue with the detailed analysis of the structural differences of the respective computing models. The section is completed with the comparison of the models in terms of their implementation of the reference application, which is Sun Microsystem’s Java PetStore [Sun01] J2EE reference and demonstration application. Section 7 presents an evaluation of the overall results of the research so far and the verification of the HCMs computing model by comparison with the findings of other related work. A summary of the wide range of related work in the area of software components and software composition by pointing out the similarities and differences with HCM is the subject of section 8, which is followed by the concluding section that notes the overall implications of the results of this research, in terms of the research itself and other related work. 2 The Argument Anyone with enough interest can build their own personal computer by simply assembling the required components together. For the following reasons, this simple example from the hardware world has a special importance for the software reuse community.
• the individual here doesn't need to be a hardware professional • the individual doesn't produce any of the components himself or herself, and finally • most of the parts are produced by different vendors.
Direct translation of this example into the software world reads as follows; anyone who is not a software professional can build the application of their choice by composing the software components that provided by different vendors, without doing any (low level) programming. There is no reason why we shouldn't be able to achieve this level of reuse in software: this is the main argument of this research. This argument is based on the following assumption. Ignoring the execution speed factor, in terms of flexibility (in other words in terms of the ability, ease and speed of doing things with), software is much more powerful than hardware. The main reason for this is that the hardware is a physical entity that has rigid boundaries. In the world of hardware, it is not possible to effect the internal workings of another component. Physical components have to interact via their interfaces and via their input and output pins. Software is much more flexible. The things that we can easily do with software, would either take an awfully long amount of time or resources, or, would simply be impossible to do it with hardware. In fact Brooks counts the changeability of software as one of its inherent properties that is responsible for the difficulties that we are facing:
6
In part it is because software can be changed more easily, it is pure thought-stuff, infinitely malleable. [Bro87] Following this reasoning, we argue that with the more powerful and flexible system, which is software, we must be able to reproduce, replicate or emulate the more rigid and less flexible system, which is hardware. 3 The Reference Model It was essential to choose the correct granularity and right level of abstraction for our reference model. Hardware operates at more primitive levels than that at which we care to emulate in software; transmitting electrons down the wire, manipulating the state of individual bits with the correct level of voltage and dealing with individual clock cycles. Our reference model is very similar to the mother board of a personal computer (PC) which provided the starting point for the previous section. The important difference is that in our reference model, the end user can also design the mother board itself and produce different mother boards or products. Likewise, our mother boards have slots to plug the pre-built components in. Each slot contains the input and output interfaces of the component and the pins of these interfaces are connected (similar to printed circuit boards) to produce the overall solution or the product. Our chosen reference model has the following consequences.
• When we have the set of essential pre-built components, we can produce any solution that we need by just designing the required mother board and plugging the existing components on to it.
• Additionally, we can effortlessly replace the components on our mother board with a new one, as long as they are interface/pin compatible.
Perhaps the most important stage of our work was the identification and definition of the important properties of the hardware systems that are responsible for the success of the model. We employed two simple methods in order to achieve our objective. (i) Pure observation, inspection and reasoning about the working principles of various electronic parts, integrated circuits and mother boards of PCs. (ii) Talking to electronic engineers and technicians and asking them questions about the working principles of these electronic parts and the qualities of the hardware components that are responsible for the success of their discipline. Eventually, we have identified the following qualities and principles as the properties that are responsible for delivering these elusive qualities of hardware systems. 1 - The physical, rigid and restrictive nature of hardware is in fact a blessing in disguise. With hardware components, we are unable to create the mess that we can easily create with extremely flexible software. There is no way of getting pointers to other components in order to manipulate them directly. As a result of which, we can not create undesirable coupling and side effects between the components. 2 - Hardware components can only interact with their own input and output pins. They get the data from their own input pins, manipulate it as required and send it to their own output pins. 3 - Hardware components don't know anything about the components that they are indirectly interacting with. The information about the connections of the interacting components are only
7
known by the containing (parent) component, not by the components that are connected. The mother board of our PC not only acts as a container, but also provides the connections in between the components that ultimately will be plugged on to it. 4 - Interaction between components and the mother board is through their input/output interfaces. A component gets its input from its input pins, does its processing asynchronously without stopping or interacting with any other component, and when finished, sets its own output pins. There is no concept of returning back something through their input pins. This one way data flow between the input/output interfaces of the components promotes a very simple, intuitive and effective plugability. 5 - Since components can only get the data from their input pins and put the manipulated data to their output pins, the only thing that they can effect (in a positive or negative way) is the output data that travels between these components. They simply don't know anything about and don't have any access to other components which ensures that they can not effect, change or corrupt each other. This quality ensures that there is no side effect between components (see Figure 4.1). As the direct consequence of above mentioned properties, there is no reusability issue in hardware. Because of minimum coupling and one way asynchronous data flow between input/output pins, every component that does something useful is automatically and fully reusable. There is no concept of increasing or reducing the reusability of a component. The only problem is producing something useful. The most important task in designing the model itself was making sure that these qualities are preserved as much as possible and transferred into an equivalent software model without any compromise. 4 Hardware Component Model (HCM) Hardware Component Model is an abstract component model that is created as the result of our attempt to replicate the component model of the hardware systems in software. Since the model includes only the essential qualities of the hardware systems that were identified previously, we ended up with a very light weight and abstract computing model that is completely independent of any language, platform or environment. The type system of HCM, which is based entirely on the HCM Markup Language (HML), is chiefly responsible for this achievement. Our introduction of the model will proceed in a top down fashion. We will start with the high level overview of the main elements (building blocks) of the system and continue with the investigation of the type system. This will be followed by the step by step construction of an example HCM component to illustrate the model. Finally the section will conclude with the formal definition of HML. 4.1 Elements of HCM HCM is a software component model that consists of number of high level elements (building blocks) and set of rules to ensure that the previously identified properties of the reference model are replicated in software. As outlined in Figure 4.1, HCM consists of ten elements. Following is the brief description and the role of these individual elements inside the overall model.
8
Pin. Pins are the message entry and exit points of the components. A pin is a set of properties (data elements) that correspond to input/output parameters of the functions. They are defined by the pinset records. When we set the required number of input pins of a component with the valid data, the processing that is connected to these pin(s) is triggered. Eventually the corresponding output pin of the component is set with the result of the function. Pinset. A pinset is a group of input (socket) and output (plug) pins that is used by the interfaces in order to define functions. Pinsets don’t define the functions on their own, they just provide the input/output parameters that will eventually be used to define the functions. Pinsets provide an extra layer or dimension in terms of reusability. The same pinset record can be shared by multiple interface records.
Figure 4.1 Elements of Hardware Component Model (HCM). Interface. Interfaces are the definitions of a set of logically related functions that represent the required behaviour of a component. They use one or more pinset records to define their functions. A function is the mapping of the set of input pins (domain) of an interface on to the corresponding (single) output pin (range) of the interface. Interface records use the list (collection) type to define the domain of the function in order to obviate the need to specify the range of the function separately. The corresponding output pin (with the same name) of the first input pin of the domain list is implied to be the range of the function. Interfaces are mandatory and immutable. There is no way of specifying an operation (function) on a component without creating the required interface first. Definition record. Definition records define the external properties of the components in terms of their behaviour (set of interfaces) and their state (database record). They specify the set of
9
interfaces that the component needs to implement and the database record (if the component is persistent) that contains the persistent fields of this component. Another important functionality of the definition records is to specify, using the extends property, the set of components that are extended by the component. There is no implementation inheritance. Type (component) extension is realised by pure composition without breaking the encapsulation. Process. A process is the only element of this model that manipulates the data directly. In other words, it is the only element that requires programming in order to convert the received input messages into completed output messages. There are two types of processes, component process and system process (sys-proc), both of which are specified by the implementation record. Component processes are implemented by the components using the host language of the system, which is the language (e.g. Java, C, Pascal) that is used to implement the HCM runtime system. The host language is also referred to as the component implementation language since it is also used to implement the HCM components. System processes on the other hand are defined in HML inside the implementation record and interpreted by the runtime system, which makes them independent of any host language or runtime system. Processes are triggered automatically (similar to event-based programming) when the required number of input pins are set. They start running on their own thread and eventually set a number of output pins, which asynchronously trigger further processing, before stopping. Implementation Record. Implementation records are the detailed definition of how the components are implemented. Similar to integrated circuits or printed-circuit boards, they specify the complete data flow via their connections property. This property defines all the processes, components and their input/output messages between the input/output pins of a component. The system processes (sys-procs) that are required by the component are also defined by the implementation record. With the combined functionality of its connections and sys-procs definitions, the implementation record effectively constitutes the composition language of HCM, HCM Composition Language (HCL). HCL is flexible enough to build complete solutions using only the pre-built system components. See Appendix B for a detailed description of sys-proc and HCL. Component. A component is the actual implementation of the component definition. Unlike pinset, interface, component and sys-proc definitions, which are specified as HML records in the system database, they are specified as a source code in the host language of the system. Components provide the actual implementation of the component processes. They need to provide a method for every component process that is specified (visited by the data flow) by the connections property of the implementation record. These methods will be called by the runtime system in an event based programming style with the list of input and output messages provided as the parameters. These methods get their input data from the parameters of the input messages and put the result of their processing into the parameters of the output messages. The rest of the functionality is provided by the runtime system. Runtime system. A component's job is extremely simplified by the runtime system, which provides most of the difficult and complicated functionality using the information obtained from the system database (definition and implementation records, interfaces etc.). It provides the complete mother board functionality that is required by the components. With the help of the repository, it also maintains the state that is required by the requests until they are completed. Repository. As suggested by its name, acts as a repository for the data that is processed by the components which are completely stateless. The second important functionality of the repository
10
is to act as the message router for the messages that are sent between the clients and servers of the system. In other words it acts as a messaging server/bus similar to the servers used in message queuing systems. The HCM system generates a unique session id for every user connected to the system and uses this id to track down the state of each request. This enables us to keep the entire state of a component outside the component and move it to the repository. By moving the complete responsibility of state maintenance on to the repository, we only need a single copy of each (stateless) component in the memory. As the direct result of this architecture, we can build very flexible and scaleable systems. Connection. Connections are the data flow lines that provide (very much like the printed-circuit boards) the links between the building blocks of the components. All the elements of HCM components, which are strictly controlled by version numbers, are immutable. Even the smallest change that alters the behaviour of an element requires the creation of a new element with a different version number. 4.2 The Type System HCM uses its own markup language, HCM Markup Language (HML), to represent the data. HML, the formal definition of which will be presented at the end of this section, is very similar to and compatible with XML (Extended Markup Language). Without exception, every piece of data that is used, stored or processed in HCM is represented as a HML property. HML's property, which is abbreviated to pro, is the exact counterpart of the XML element. Apart from being used to define the system data (pins, interfaces, components etc.), HML is also used to define the application domain (user) data that is stored in the database tables. Properties can be atomic or composite (collection) and optionally contain attributes. Attribute is the meta data that is used to describe the property further. The HCM system comes with the following small set of predefined property (data) types.
# Generic properties pro # Generic property type that represents any property null # Specifies the absence of a value (data) for any property # Simple/Atomic properties int # 64 bit 2's complement integer value real # 64-bit IEEE floating-point value date # Date as 'DD-MM-CCYY' time # Time with milliseconds as 'HH:MM:SS.sss' dtime # Date time as 'DD-MM-CCYY HH:MM:SS.sss' str # String data type (array of unicode characters) bool # Boolean type ( 'true' or 'false' ) # Composite properties/Collections set # Single-instance un-ordered collection of properties list # Multi-instance ordered collection of properties (sequence) bag # Multi-instance un-ordered collection of properties Composite properties are based on mathematical sets. All three collection types ({sets}, [lists] and <bags>) have their own separate delimiters to mark the beginning and end of the collection. While
11
atomic properties can only have one of the simple property types as its value, composite properties can contain zero or more properties which themselves can be atomic or (recursively) composite. The following example demonstrates the three collection types (set, list and bag), all of which contain atomic properties only. The bag collection uses the count attribute to keep track of the instance count of the properties that it contains. subjects-studied_{ subject_Maths subject_Physics subject_Logic } software-life-cycle_[ activity_Analysis activity_Design activity_Programming ] films-seen_<
film_count_2_"Gandhi" film_count_1_"Jaws"
film_count_3_"ET" > The underscore character is the separator which is used to separate the names and values of the properties and their attributes. As demonstrated in the bag example, attributes are defined (similar to XML syntax) between the name of the property that it belongs to and its value. If the value of the attributes or properties contain space or underscore (the separator) character, they need to be delimited by single or double quotes. Record and Table Type. Record and table property types, which are described in detail by the following type definition extract, play a very important role in delivering a unified persistence mechanism that is very instrumental in the increased reusability. With the exception of some predefined type definitions, every other persistent system and user data in the system is consistently defined and stored as records in their corresponding tables. # Record & Table type definitions # Table is the container for the records of its own type. # 'Person-record' is contained by the 'Person-table'. # table_type_set_of_record # Record is the fixed set of properties (id & fields). It is the base type # for all persistent system and user data that is stored in the database # tables of the same type. # record_{ id_type_ list_of_pro fields_type_set_of_pro } Message (msg) Type. Since asynchronous message passing is the only form of communication in HCM, the message type itself is very important. The following example demonstrates two messages, the first one of which is the request message (input) that is sent to the Person component and the second one is the response (output) message that is received as the result.
name_"Von" surname_"Neumann" grade_"6" }}}} status_[] } While the first four properties of these messages are reasonably self explanatory, specifying the Record_01_get-pin pin of the get function of the Record_01 interface that is implemented by the Person_01 component, the params property may need more explanation. Params property of HCM messages corresponds to the Pin element of the components that is described in section 4.1. Hence, the params property is a set of properties (data elements) that correspond to input/output parameters of conventional functions. Params property of a request (input) message corresponds to the input parameters of ordinary methods or functions. Accordingly, the params property of a response (output) message contains all the output parameters. In our example we have two input parameters, both of which are of type string. The first one (fields) of these parameters is a comma separated list of the requested data fields of a set of Persons that are identified by the predicate provided by the second input parameter (where). The one and only output parameter (table) is a set of Person records that match the specified criteria. The reason for using the same params name for both input and output messages without qualifying with input/output prefixes is to prevent the confusion when the output (message) of one component is connected as the input of another component, in which case the output message becomes the input message. Finally the last property of a message is the status property which is a list of error messages that may occur during the processing of the message.
13
Shorthand Notation. With the help of previous example messages, we will demonstrate the short hand notation, which is a convenient way of referencing the HCM messages, that is used throughout this paper. The following is the full name of the request message given above, the length of which should make it clear why a shorter notation would be more suitable. Person_01/Record_01/get/Record_01_get-pin | | | | | | | | | Pin | | | Pinset | | Function | Interface Component The first thing that can easily be eliminated is the version numbers. When we omit the version numbers, the runtime system can easily look up the default version number of a given component from the configuration table (config-table). In the absence of the default version number record, the version number '01' is assumed. We also don't need to specify the 'pin' extension of the pin name. As a result we obtain the following name for the same message. Person/Record/get/Record_get | | | | | | | | | Pin | | | Pinset | | Function | Interface Component Since the interface and pinset names are the same, we can omit the pinset name. We can also omit the pin name and just use the function name since the function and pin names are also the same. Finally we obtain the following name for the same message that can not be shortened further without any loss of information. Person/Record/get | | | | | Function | Interface Component The important point is that when given this short name, the runtime system can build the full version of the name by making use of the system tables and the naming convention. Of course there is one more step that can be taken if the component and interface names were also the same. In that case we can just use the component and the function name, omitting the interface name as well. For instance the message name Person/promote is the short name of the message that has the following full name (assuming the '01' as the default version number). Person_01/Person_01/promote/Person_01_promote-pin | | | | | | | | | Pin | | | Pinset | | Function | Interface Component
14
4.3 Example HCM Component Here we will illustrate the model with a running example of how to create a component. This example will also demonstrate the necessary steps in building a component. For this purpose we have chosen the Integer component that provides a single function add via its Integer interface. 1 - Pinset record: Creation of the pinset record is generally the first step; especially if we are defining a new operation for our component. As mentioned previously, the pinset records provide an extra layer of reuse which means that, if the parameters of our operation is already defined by an existing pinset record, we can skip this step and use this existing pinset record in our components interface record. In this example, our component (Integer_01) needs a pinset definition record to define the parameters of the add function which will be defined in the interface record later. pinset-record_{ id_[ name_"Integer" version_"01" ] fields_{ pins_{ add-pin_{ input_{ operand1_type_"int" operand2_type_"int" } output_{ result_type_"int" }}}}} 2 - Interface record: Our component needs an interface definition record which makes use of the previously defined pinset record in order to define the required operation.
pin_"Integer_01_add-pin" ]]}}} 3 - Definition record: The definition record is the most important system record that brings our component into life. According to the following definition record, our Integer_01 component implements the Integer_01 interface via the Integer_01_Hcm_01_01 Java class that resides in the hcm.test package. While the first part of the class name (Integer_01) is the name of the component, the second part (Hcm_01_01) specifies the implementation name of the component together with the version and revision numbers of the implementation. Here we can see the extent of the flexibility that is provided by the model. The implementation class of any component can be changed dynamically at runtime by updating the implementation property of this component.
15
definition-record_{ id_[
name_"Integer" version_"01" ] fields_{ interfaces_{ interface_"Integer_01" } implementation_"hcm.test.Integer_01_Hcm_01_01" }} 4 - Implementation record: Since there is only one function (add), the result of which is not connected to any other component or process, we don't need to define an implementation record for our example. By default, the runtime system will execute the function and return the result without any need for an implementation record. Instead, here, we present a simple example of how to create a new solution without writing any code. Creation of new solutions by composing the existing components is the most important feature of HCM. In the following example, when we send a message to our Integer/add function, the result of this function will be fed into the Sys/Integer/double function twice before eventually being returned back to us. implementation-record_{ id_[ component_[ name_"Integer" version_"01" ] implementation_[ name_"Hcm" version_"01" revision_"01" ]] fields_{ connections_{ from_pin_"@self/Integer_01/add/Integer_01_add-pin"_{ to_pin_"Sys_01/Integer_01/double/Integer_01_double-pin"_{ to_pin_"Sys_01/Integer_01/double/Integer_01_double-pin"_{}}}}}} 5 - Implementation class: Here is the Java class (Integer_01_Sys_01_01) that provides the add function of the Integer interface of our component. public class Integer_01_Hcm_01_01 { public void Integer_add ( MsgList input, MsgList output ) { // int op1, op2; // op1 = input.msg( 0 ).param( "operand1" ).asInt(); op2 = input.msg( 0 ).param( "operand2" ).asInt(); output.msg( 0 ).param( "result" ).setValue( op1 + op2 ); }} 6 - HCM module: Finally, we need to create the HCM module for the server side deployment which archives the following elements. - Integer pinset record - Integer interface record - Integer definition record - Integer_01_Sys_01_01.class
16
4.4 HCM Markup Language (HML) We will close this section with the formal definition of the HCM's markup language. We use the Extended Backus-Naur Form (EBNF) notation for this purpose. HCM Markup Language (HML) is very similar to and compatible with XML. HML’s property is the exact counterpart of XML element. Likewise, HML document has to have a single (root) property that may optionally have more properties. Document [1] <document> ::= (<comment>)* <property> Properties [2] <property> ::= <atomic-property> | <collection> [3] <atomic-property> ::= <base-property> '_' <value> [4] <base-property> ::= <identifier> (<attribute>)* [5] <attribute> ::= '_' <identifier> '_' <value> [6] <collection> ::= <set> | <list> | <bag> [7] <set> ::= <base-property> '_' '{' <space>? (<property>)* <space>? '}' [8] <list> ::= <base-property> '_' '[' <space>? (<property>)* <space>? ']' [9] <bag> ::= <base-property> '_' '<' <space>? (<property>)* <space>? '>' Identifier [10] <identifier> ::= <letter> (<letter-digit> | '-' | '.')* [11] <letter> ::= [A-Za-z] [12] <digit> ::= [0-9] [13] <letter-digit> ::= <letter> | <digit> Values Any standalone data item that doesn't contain any space in it, or any delimited data item with single, double or single back quote that doesn't contain the delimiter character. [14] <value> ::= <data> | '"' ([^"] | <data>) '"' | "'" ([^'] | <data>) "'" | '`' ([^`] | <data>) '`' [15] <data> ::= <null> | <integer> | <real> | <date> | <time> | <string> | <boolean> [16] <null> ::= 'null' [17] <integer> ::= (<sign>) <digit-sequence> [18] <sign> ::= '+' | '-' [19] <digit-sequence> ::= <digit> (<digit>)* [20] <real> ::= (<sign>) <digit-sequence> '.' (<digit-sequence>)
5 The Implementation This section introduces the current implementation of the model; first, in terms of the initial implementation of the prototype HCM system; and than, using this prototype, the implementation of the chosen reference application. The initial implementation of the prototype HCM system has been realised as a distributed Java application. After finishing our prototype HCM system, we have chosen Sun Microsystem’s Java PetStore [Sun01], a J2EE reference and demonstration application provided by the J2EE Blueprints program, as the reference application. Using our prototype HCM system we have implemented this reference application, which is named as hPetStore. Rather than using Sun's own implementation of the PetStore application, we have chosen the xPetStore implementation for comparison with hPetStore. xPetstore [XPet] is the re-
18
implementation of the PetStore application using the xDoclet [XDoc] code generation engine. Please see Appendix A for a brief introduction to the xPetStore implementation and the underlying xDoclet technology. Our reasons for the preference of the xPetStore implementation as opposed to Sun's own implementation are as follows;
• Sun's original implementation (PetStore) is too big and complicated for our purposes of high level comparison. xPetStore on the other hand is smaller and more manageable.
• Since most of the application is generated by the xDoclet engine, it follows a strict naming conventions for the class and package names which makes the identification and counting of a certain category of classes, for the purposes of comparison, much easier.
• Finally, since the most important benefit of xDoclet is to cut down the redundant repetitive work, xPetStore is also a valuable tool to indicate (roughly) the amount of redundant repetition in the whole application that should otherwise (ideally) be hidden from the developer.
5.1 Implementation of the Prototype HCM system The model is implemented as a distributed Java application, the overall architecture of which is illustrated in Figure 5.1. The architecture is very similar to point to point message queuing systems. The Repository sits between the clients and the servers of the system and acts as the messaging server (router). The system is very similar to classic 3 tier distributed architectures. The main difference is that the repository, apart from being the message router, also encapsulates the entire state (user and system data) of the system. That is the reason why there is no separate database tier. The only mode of communication is asynchronous message passing. The clients and servers of the system can not talk to each other directly. The following is the step by step analysis of the typical interaction between the clients and the servers of the system:
1. Each server connects to the repository, reports (publishes) the interfaces of the components that it can service, and waits (blocked) for a suitable message.
2. One of the client programs creates a message for one of the components in the system, which also contains the message sequence number and the sender’s id, and sends it to the repository. As soon as the repository receives the message the client program returns and is free to do any other processing.
3. Each message received by the repository is handed over to any suitable server that is waiting (blocked) for a message. The server starts the processing of the message by feeding the message as the input of the target component.
4. In order to get the result of the message back, the client program has to ask the repository if the response of the message is ready. At that point it will be blocked until the response message is delivered by the server program.
5. The server eventually gets the result of the message as the output of the target component and puts this response message back into the repository addressing it back to the original sender of the request message.
6. Finally, when the repository receives the response of the original request message from the server, it hands it back to the client program if the client program is already waiting for it. Otherwise it will be kept in the repository until the client program asks for it.
19
Figure 5.1 High level architecture of the prototype HCM implementation and the stages of a typical interaction between the clients and the servers of the system. The Object Management Group (CORBA governing body) has defined 13 services for CORBA compliant Object Request Brokers. The latest EJB specification [EJB01] requires seven of these services, which are also called primary services, to be completed in order to be a compliant EJB platform. These services are concurrency, transactions, security, asynchronous messaging, distributed objects, naming and persistence. Our implementation includes all but two of these services. For the following reasons we excluded the transactions and security services from our prototype HCM implementation.
• Implementations of these services by the EJB model are already good enough. They are handled by the container and don't need any programming by the developers. Developers or administrators can define the transactional and security requirements of the components using the deployment descriptors, which are high level declarative XML documents. HCM doesn't offer any improvements as far as these services are concerned.
• The measures and the criteria that we use in the comparison of the models are not, in any
way, dependent on the implementation of these services. Of course the implementation of these services increases the complexity of the EJB containers, but it doesn't have any positive or negative effect on the quality of the services that we are comparing with HCM. Equally, when we include these services, it will be very much like the EJB implementation, being completely hidden from the user and implemented by the HCM runtime system in a declarative fashion. Most importantly, although it will certainly increase the complexity of the HCM implementation, it won't have any negative or positive effect on the qualities and properties of the system that we are comparing with EJB.
20
• Finally, by excluding these services that wouldn't have any effect on the comparison and the demonstration of the benefits of the HCM, we shortened the time that is required to complete our HCM implementation.
5.2 Implementation of the Reference Application with HCM (hPetStore) The main reason for our selection of the PetStore as the reference application is the fact that it is provided by the J2EE Blueprints program as a J2EE reference and demonstration application. It is also a well known reference application that is used both in academia and industry [CKF02, LHP04, MPet, OPet]. Another reason is the fact that it is created for similar objectives and criteria that we are targeting with our implementation; demonstration of good design patterns, principles and practice. The emphasis is entirely on flexibility, maintainability and overall quality of the design rather than the speed or efficiency of the final application. Similarly, our implementation and comparison ignores the speed and efficiency issues completely and concentrates solely on the following aspects; speed and ease of producing the solution and the amount of mental (cognitive) and physical effort needed to achieve that. The page flow diagram in Figure 5.2 provides a high level overview of the PetStore web application.
Figure 5.2 High level page flow of the PetStore web application. In our implementation we have chosen a non-trivial subset of the reference application. The user of the hPetStore web application can:
• login to the system as a new or an existing user • manage their account details (address, email, credit card number etc.) • browse different products and items that belong to different categories • add the required items into his/her order which reduces the stock level of that item
immediately
21
• check-out and complete the purchase which triggers the following sub-tasks; closing the order, charging the credit card account and sending an acknowledgement email.
In order to increase the validity of our comparison of the hPetStore and xPetStore implementations, we made sure, as much as possible, that the functionality of our implementation covers the full set of functionality that is provided by xPetStore. The functionality of the xPetStore implementation is provided on the specification page of their web site [XPet]. Please see Appendix C for a more detailed specification of the hPetStore implementation. For the sole purpose of making the implementation more practical, charging the credit card and sending the acknowledgement message tasks are simulated as an internal component (table) that is updated accordingly. The client program of our implementation provides a simple character based command line user interface that emulates the web browser. Any data or options that can be selected by the user is numbered sequentially and enclosed in square brackets. The user selects the option by typing the number next to his/her selection which triggers the relevant link page in our text based browser. The following examples demonstrate two screen shots from our character based browser. o----------------------------------------------------------------------------o | Products hPetStore | o----------------------------------------------------------------------------o [0] User login User Id: [1] Order status Order Id: Id Name Description ======== ==================== =================================== [2] K9-BD-01 Bulldog Friendly dog from England [3] K9-PO-02 Poodle Cute dog from France [4] K9-DL-01 Dalmation Great dog for a fire station [5] K9-RT-01 Golden Retriever Great family dog [6] K9-RT-02 Labrador Retriever Great hunting dog [7] K9-CW-01 Chihuahua Great companion dog o----------------------------------------------------------------------------o >> page 2
o----------------------------------------------------------------------------o | Order hPetStore | o----------------------------------------------------------------------------o [0] User login User Id: haluk Order Id: 6 Item ID Description Unit Cost Quantity Sub Total ======= =========== ========= ======== ========= EST-1 Large 16.5 2 33.0 EST-9 Spotless Male Puppy 28.5 2 57.0 Total: 90.0 [1] Check out o----------------------------------------------------------------------------o >> page 0
22
6 Comparison of HCM & EJB Component Models The design and structure of HCM makes it suitable to be used as a distributed component model. Common component models (COM, .NET, CORBA, CCM and EJB) and their relevant advantages and disadvantages are discussed in section 8. Out of these technologies, we have chosen the EJB model as the most relevant one for the comparison and evaluation of HCM. The following are the reasons for this selection.
• EJB is a pure specification which can be picked up by any individual or organisation and implemented (vendor independence) in its entirety.
• EJB is a more complete specification than other alternatives. It aims to hide the implementation of the persistence and also to provide a seamless view with the object model. .NET, for instance, presents a relational view and associated tools provided by the framework. Although these tools make it really easy to talk to relational databases, nevertheless, developers are forced to change their conceptual view from objects to relational tables.
• Although it is language specific, it is the closest solution we can practically get in terms of platform independence.
• Finally, due to being much simpler and practical than CORBA, its adaptation by the industry has, so far, been impressive. As a direct result of this, the latest CORBA component model (CCM) is designed to be fully compatible with the existing EJB components [Szy02]. A growing number of Open Source EJB containers (JonAs, OpenEJB, JBoss and Apache Geronimo), together with the wide range of commercial offerings, could also be interpreted as an indication of this popularity.
Our comparison will start with the high level comparison of the models in general. Than we will analyse the structural differences of the EJB and HCM component models and highlight the respective advantages and disadvantages that is caused by these differences. Finally our comparison will be completed with the comparison of the models in terms of the reference application implementations. 6.1 High Level Comparison of the Models in General The level of abstraction provided by HCM is much higher than EJB, which is also the main reason why the model is much cleaner and simpler. This in turn enables us to raise the abstraction level of our comparison and avoid any low level detailed comparisons, such as the number of lines of code, and concentrate on the higher level more abstract qualities of the models. Accordingly, our comparisons are based on the following high level criteria; component types, elements (building blocks) of the components, construction of stateless and stateful components and the client usage. 6.1.1 Component Types Here we compare the models according to different types of components that they provide. EJB. Provides 5 different types of components that are classified under 2 types of communication modes. Each component type is governed by different rules and regulations in order to cooperate
23
with its environment (the EJB container) properly and needs to provide a number of methods (even though most of these are not used) in order to comply with the standard [EJB01]. Enterprise Java Beans (EJB) Synchronous communication Session Beans 1 - Stateless (SLSB) 2 - Stateful (SFSB) Entity Beans 3 - Bean Managed Persistence (BMP) 4 - Container Managed Persistence (CMP) Asynchronous communication 5 - Message Driven Beans (MDB) An EJB developer has to obey many design rules and idioms that are not enforced and can not be checked by the compiler. For example, the EJB specification defines 17 programming restrictions [POM03, EJB01] for the bean developers, such as "an EJB must not attempt to manage threads" or "an EJB must not use read/write static fields". These rules and exceptions have to be appreciated fully for the proper use of the model [Szy02, Mon01]. HCM. Asynchronous communication is the only mode of communication (synchronous calls are emulated via asynchronous calls) and has only one type of component; Integrated Software Component (ISC). By default HCM components are stateless, but they can optionally have state, in which case they become stateful ISC (SISC). The important difference is that the SISC is not a different type of component. It is a standard HCM component that extends (inherits from) the Table system component, which is the component that handles the persistence requirements of all the components. Of course SISCs do also have to declare their persistent fields (the state) in their definition records. By default this state is persistent and stored in the component's own table. HCM components can not interact with their environment (no need for EJB's call-back methods) and there is no difference between the ISC and SISC in terms of their definition and usage. Asynchronous communication 1 - Integrated Software Component (ISC/SISC) As we can see from this comparison, HCM provides a much simpler and cleaner model. The single component type of HCM (ISC) provides all the features that is provided by the five different types of components in the EJB model. Stateful components of HCM are implemented as a normal component that inherits the required functionality with a high level HML declaration without even any need for programming or compilation. There is also no need for additional component types for the different mode of communication, since asynchronous ISCs can easily emulate the synchronous mode of communication.
6.1.2 Elements (Building blocks) In this category we compare the models in terms of the number and types of different elements that have to be created for each type of component that they provide.
24
EJB. Element Session
Bean Entity Bean Message
Driven Bean Type
Local/Remote Business Interface
yes yes - Source code
Local/Remote Home Interface
yes yes - ''
Implementation class yes yes yes ''
Primary Key class - yes - ''
Helper classes (Auxiliary Support classes)
[yes] yes [yes] ''
Deployment Descriptor yes yes yes High level XML definition
[*] Optional elements Table 6.1 Elements of the different types of EJB components. The fact that the component (business) and the home interfaces can be local and/or remote creates additional complexity and undermines the location transparency completely. If a component is implemented as a local component for speed and efficiency reasons, it can not be taken and dropped into another EJB container to be used remotely. Some vendors have even objected to the addition of the local interfaces into the specification, claiming that the local interfaces only added extra complexity without providing any real benefits [Mon01]. One well known good EJB practice is to use the local interfaces for the entity beans (not to introduce heavy remote protocol penalty for the local clients) and wrap these entity beans with the session beans that acts as a facade (well known design pattern [GHJ94]) for them. These facade session beans make all the required operations of the entity beans available on their remote interface and implement them locally with the actual entity beans. Another important observation is that, apart from the main (business) interface and the implementation class of the component, there are a number of additional interfaces and helper classes that are necessary (home interface, primary key class and other helper classes) for the normal functioning of the system. In a better structured component model that makes proper use of abstraction, these helper classes and interfaces shouldn't be needed. The last but probably the most important point is, apart from the deployment descriptors, the type of all the elements is source code. The smallest changes in these elements will require the recompilation, re-packaging and re-deployment of the module that contains the relevant component. HCM. The simplicity and cleanness of the model is evident from the table itself (Table 6.2). As far as the type of elements are concerned, HCM components are mostly defined with high level (declarative) definition records. The only exception is the implementation class itself which is the only element that needs to be compiled and executed by the model. All other aspects of the system can be changed dynamically in runtime.
25
Element ISC Type
Definition record yes High level HML definition
Pinset record [yes] ''
Interface record [yes] ''
Implementation record [yes] ''
Implementation class [yes] Source code
[*] Optional elements Table 6.2 Elements of the HCM component. The other important point is the number of optional elements. The optional elements are only needed when the component defines its own functions (operations). In the case of stateful components (SISCs) the only element that needs to be defined is the definition record. This comparison highlights probably the most important difference between the models. While most of the (5 out of 6) elements of the EJB components are low level elements (source code elements as Java Classes or Interfaces) that require programming, most of the (4 out of 5) elements of the HCM components are high level elements (declarative HML definitions). As investigated by [POM03], use of high level declarative notation in handling the infrastructural aspects of enterprise computing, as opposed to hard coding these aspects in the source code, has significant positive effects on the understandability, maintainability and reusability of the system. 6.1.3 Construction of Stateless Components In this category we compare the models in terms of the number of steps (tasks) that need to be completed in order to create a stateless component (SLSB and ISC). We will start from scratch with the first step and eventually end up with the completed component that is ready for deployment at the end of the last step. Our Hello component has (obviously) no state and provides only one method; sayHello. EJB: 1 - Creation of the remote home interface. public interface HelloRemoteHome extends EJBHome { public HelloRemote create() throws CreateException, RemoteException; } 2 - Creation of the remote (business) interface. public interface HelloRemote extends EJBObject { public String sayHello( String name ) throws RemoteException; }
26
3 - Creation of the implementation class. public class HelloBean implements SessionBean { // EJB Session bean methods public void setSessionContext( SessionContext context ); public void HelloEJB(); public void ejbCreate(); public void ejbRemove(); public void ejbActivate(); public void ejbPassivate(); // Business method public String sayHello( String name ) throws RemoteException; } 4 - Creation of the deployment descriptor. <ejb-jar> <display-name>HelloJAR</display-name> <enterprise-beans> <session> <display-name>Hello</display-name> <ejb-name>HelloRemote</ejb-name> <home> HelloRemoteHome </home> <remote> HelloRemote </remote> <ejb-class>HelloBean</ejb-class> <session-type>Stateless</session-type> </session> </enterprise-beans> </ejb-jar> 5 - Creation of the ejb-server.jar file for the server side deployment which contains the following elements. - HelloRemoteHome.class - HelloRemote.class - HelloBean.class - ejb-jar.xml 6 - Creation of the ejb-client.jar file for the client side deployment which contains the following elements. - HelloRemoteHome.class - HelloRemote.class
27
HCM: 1 - Creation of the Hello pinset record. pinset-record_{ id_[ name_"Hello" version_"01" ] fields_{ pins_{ sayHello-pin_{ input_{ name_type_"str" } output_{ result_type_"str" }}}}} 2 - Creation of the Hello interface record. interface-record_{ id_[ name_"Hello" version_"01" ] fields_{ functions_{ function_{ name_"sayHello" domain_[ pin_"Hello_01_sayHello-pin" ]}}}} 3 - Creation of the Hello (component) definition record. definition-record_{ id_[ component_[ name_"Hello" version_"01" ]] fields_{ interfaces_{ interface_"Hello_01" } implementation_"hcm.sys.Hello_01_Sys_01_01" }} 4 - Creation of the Hello_01_Sys_01_01 implementation class. public class Hello_01_Sys_01_01 { public void Hello_sayHello( MsgList input, MsgList output ); }
28
5 - Creation of the hcm module for the server side deployment with the following content. - Hello pinset record - Hello interface record - Hello definition record - Hello_01_Sys_01_01.class There isn't much difference in terms of number of required steps between EJB and HCM when developing a stateless component. The main difference is that with EJB the HelloBean implementation class needs to define 6 extra EJB SessionBean methods that have nothing to do with its business functionality. As mentioned before, the business and the home interface of our bean have to be hardwired to be local or remote. In this example it is chosen to be remote; which means that in order to use this bean locally (on the same JVM) we need to create the local interfaces as well. In EJB we also need the client side jar file (ejb-client.jar) for the deployment which is not needed in HCM. Finally, as mentioned in the previous category (section 6.1.2), all the elements of the HCM component, with the exception of the implementation class, are high level HML definition records. The situation is exactly the opposite with the EJB component, since everything except the deployment descriptor is Java source code. 6.1.4 Construction of Stateful Components This comparison is the same as the previous one with the only difference that instead of creating a stateless component, we will create a component with state (CMP and SISC). In this case our example component represents the Product domain entity which has three persistent fields; name, description and status. EJB: 1 - Creation of the local home interface. public interface ProductLocalHome extends EJBHome { public ProductLocal create(String id ) throws CreateException; public ProductLocal findByPrimaryKey( String id ) throws FinderException; } 2 - Creation of the local (business) interface. public interface ProductLocal extends EJBLocalObject { public String getId(); public void setId(String id ); public String getName(); public void setName( String name ); public String getDescription(); public void setDescription ( String description );
29
public String getStatus (); public void setStatus ( String status ); public ProductValue getProductValue(); public void getProductValue(ProductValue productValue ); } 3 - Creation of the implementation class. public abstract class ProductEJB implements EntityBean { // EJB Session bean methods public void ejbCreate( Integer id ); public void ejbPostCreate( Integer id ); public void setEntityContext( SessionContext context ); public void unsetEntityContext(); public void HelloEJB(); public void ejbActivate(); public void ejbPassivate(); public void ejbLoad(); public void ejbStore(); public void ejbRemove(); // Business methods public String getId(); public void setId(String id ); public String getName(); public void setName( String name ); public String getDescription(); public void setDescription ( String description ); public String getStatus(); public void setStatus ( String status ); public ProductValue getProductValue(); public void getProductValue(ProductValue productValue ); 4 - Creation of the deployment descriptor. <ejb-jar> <enterprise-beans> <entity> <display-name>Product</display-name> <ejb-name> ProductLocal</ejb-name> <home> ProductLocalHome</home> <remote> ProductLocal</remote> <ejb-class> ProductEJB</ejb-class> <persistence-type>Container</ persistence-type> <prim-key-class>java.lang.String</ prim-key-class> <reentrant>False</ reentrant> <abstract-schema-name>Product</ abstract-schema-name> <cmp-field><field-name>id</field-name></cmp-field> <cmp-field><field-name>name</field-name></cmp-field> <cmp-field><field-name>description</field-name></cmp-field> <cmp-field><field-name>status</field-name></cmp-field> <prim-key-field>id</prim-key-field> </entity> </enterprise-beans> </ejb-jar>
30
5 - Creation of the ejb-server.jar file for the server side deployment with the following content. - ProductLocalHome.class - ProductLocal.class - ProductEJB.class - ejb-jar.xml 6 - Creation of the ejb-client.jar file for the client side deployment which contains the following elements. - ProductLocalHome.class - ProductLocal.class HCM: 1 - Creation of the Product definition record. definition-record_{ id_[ component_[ name_"Product" version_"01" ]] fields_{ extends_{ component_"Table_01" } record_{ id_[ id_type_"str" ] fields_{ name_type_"str"_"" description_type_"str"_"" status_type_"str"_"" }}}} 2 - Creation of the HCM module for the server side deployment which contains the definition record. - Product definition record There is a big difference in terms of the amount of effort that is required to create an EJB entity bean and the equivalent HCM component with state (SISC). The ProductEJB implementation class has to define 10 EJB EntityBean methods that are mostly redundant (left empty) and have no relation to its business functionality. For each data field of the EJB component, we need to define two methods (getter and setter methods) which are redundantly repeated in 3 different places; interface class, implementation class and the deployment descriptor. On the other hand, the only step that is required for the HCM implementation is, apart from the packaging of the module for the server side deployment, the creation of the definition record that contains the details of the
31
persistent fields of the component. We inherit everything that we need from the Table system component, with a single HML definition record without any need for programming or compilation. Considering the fact that most of the components in any real world application have to maintain some sort of state, high level declarative implementation of the stateful components in HCM provides significant benefits in terms of flexibility, maintainability and reusability. We identified the combined effect of the Persistence and Component extension mechanisms of HCM as being especially responsible for this level of increase in productivity. The following is a brief description of these properties. Persistence mechanism. The same table and record structure is used to handle the entire persistence requirements in the model. Components have no state. A single instance of the component operates on the set of individual records (instances) of the entity that is being modelled. Similar to the relational query language SQL, the HCM runtime system operates on the whole set (or any sub set) of the individual records specified/identified by the where parameter of the message. Most importantly, both the user and the HCM system use the same persistent database id of the instance. In the EJB model, or more generally in the OO model, the user has to handle the individual object instances themselves by invoking the required methods. They have to obtain a reference, which is the memory address of the object instance that has no relation to the original persistent database id of the object. If we also want to apply the operation on any set of objects, we have to create a separate method, either in the same class (as a static method) or in a different class, and use SQL via JDBC [JDB98] or the EJB Query Language (EJB QL) in order to achieve that. In HCM, we don't need to create and destroy individual instances of the components (records) and obtain memory references for them via the naming system (as we do in EJB) in order to interact with them. All we need to do is to create the message that targets the required subset of the records of the component and send this message to the repository. This aspect of the client usage will be discussed further in the following section. Component extension (reuse) mechanism. HCM manages to capture the high level reuse characteristics of hardware systems. Existing components can be (re)used without any change, using a high level declarative notation. As demonstrated in the definition record of the Product component, all we need to do is to specify the id of the component that we want to extend in the extends property of the definition record. We don't need to write any code or do any compilation in order to use or extend an existing component. Of course this is only true if we don't want to change the behaviour of the extended component with pre or post processing, in which case we need to define the other elements of the component. The advantage of the stateful components in HCM is that, apart from declaring their persistent fields in their definition record, they also extend the predefined system component; Table. The Table component implements the Record interface which includes the necessary functions (get, set, add, delete and update) to handle almost all the persistence requirements of a component. In fact the Table component, together with its Record interface, encapsulates the functionality of SQL as an HCM component which provides a seamless persistence mechanism. At this point we need to further clarify the type extension mechanism of HCM. The extends property of the definition record is in fact just a high level functionality that is provided by the HCM implementation. The core HCM system doesn't have the concept of type extension or inheritance. In order to extend a component, we need to implement the interfaces of that component by using the component (delegation) itself. In order to do that, we first need to list the
32
interfaces of that component in the interfaces property of our definition record. Finally, in the implementation record, we connect each input pin of these interfaces with the input pin of this component and take the output pins of the component and connect to the out pins of our interfaces. This process is illustrated visually and more clearly in Figure 6.1. In this example the Product_01 component extends the Table_01 component. This is a straight forward extension. We connect our input pins into the extended component and take its output pins and connect to our output pins, which makes our component behave exactly like the extended component. This is what the HCM implementation does automatically when we use the extends property of the definition record, which is to update the definition and implementation records as described above. There is also an example of another type of extension in the same figure. In that case the behaviour of the XMLTable_01 component is changed with pre and post processing. In this imaginary example, our Product component receives the get request in HML, converts the request into XML with preGet process, performs the actual get operation via XMLTable component, and finally converts the result back to HML with postGet process. This example demonstrates how we can change or overwrite the behaviour of the extended component. Although this type of extension mechanism implemented explicitly by the user may initially seem primitive, especially when compared with the implicit type extension mechanisms of popular OO languages, it has two important advantages:
• Type extension is realised by pure composition without breaking the encapsulation, which is the most essential quality of hardware components.
• Since the input pin of our interface is connected explicitly into the input pin of one of the extended components, the ambiguities that may arise when extending multiple components with the common ancestor are avoided.
Figure 6.1 Component Extension mechanism of HCM. The amount of increase in the level of abstraction delivered by the HCM model warrants more detailed analysis which shall be provided in section 6.2.
33
6.1.5 Client Usage Here we compare the models in terms of the number of tasks that any client application needs to perform in order to connect and use the services of any predefined component in the system. The very first step (step 0) in the EJB example is not really counted since it needs to be performed only once per client application. EJB. 0 - Set up the initial context for JNDI (Java Naming and Directory Interface) - once per client
InitialContext oJndiContext = new InitialContext();
1 - Import the necessary Home and Component (Business) interfaces - per component
2 - Process the created message (send and receive the response) - per message
Msg oProducts = oMsg.process()
34
As demonstrated clearly by this simple comparison, the level of abstraction provided by HCM is considerably higher. The difference is mainly caused by the fact that HCM manages to hide more infrastructural detail from the user. A good example is the naming system. Although the HCM system makes use of a naming system in order to find the target components of messages, it is completely hidden from the user. Let alone using it, the user doesn't even know the fact that there is a naming system operating behind the scene. The other important factor that makes a big difference is that in HCM, components communicate via asynchronous message passing. This mechanism de-couples the sender (the client) and the receiver (the component) of the message completely. Hence, we don't need to obtain any handle or a reference for a component that we want to send a message to. The situation is exactly the opposite with the EJB model. We not only need to obtain a separate home interface for different EJB components, but we also need to create different instances of the same component in order to execute their methods individually. 6.2 Structural Differences of the EJB and the HCM Models and their respective Advantages and Disadvantages The difference between the level of productivity and abstraction that is provided by these models warrants more detailed analysis, so that we can gain better understanding of these computing structures and the reasons for their respective advantages and disadvantages. The main reason for the inefficiencies of the EJB model is caused by the computing structure that is inherited from object orientation. The following properties of the object-oriented model of computing is mainly responsible for these problems. 1) In object-orientation the emphasis is on the individual object instances which are the individual instances of the entity that is being modelled (represented) by the class. Classes represent the individual object instances and provide the blueprint for the set of objects that share the same state and behaviour. Accordingly, the methods that specified by the class operate on the state of the individual object instance, not any (required) set of these instances. 2) The mode of communication is synchronous method call, which means that before invoking any of the methods of the required object instance, we have to obtain some kind of reference for the required instance. This reference could be local (address of the actual object) or remote (via stub and skeleton proxy objects). As analysed in detail by [WWW94], syntactic and semantic differences of the method invocations via these local and remote references create serious obstacles for the successful abstraction of the local and distributed computation. As follows, this situation is exactly the opposite in HCM. 1) Stateless components encapsulate the set of functions (via interfaces) that, very much like in SQL, operate on the whole set (or any required subset) of the records (instances) of the entity that is being modelled by the component. 2) The only mode of communication is asynchronous message passing, which means that the sender and the receiver of the message are completely and cleanly de-coupled. The same message
35
can operate on a single record or any subset of the records, which is specified by the where parameter (identical to the where clause of SQL) of the message. These opposing properties/qualities of these models create big differences in terms of the usability of the components that they create. More accurately, the EJB components require the use of the following utility (helper) classes that, firstly, have got nothing to do with their business functionality; secondly and most importantly, are not required at all by the corresponding HCM components. 1 - Home Interface Before using the services of any entity or session bean, we need to obtain a local or remote reference for the required bean. This is the sole purpose of the home interface which contains the methods that either create a new instance of the bean, or find the previously created existing bean via unique id. Finding the home interface requires an extra step involving the use of JNDI. 2 - Home Interface Factory A utility class that reduces the code replication by encapsulating the code that accesses and caches the initial instance of the home interface. It uses JNDI to locate the home interface, which could be local or remote, and stores it in a local variable (the cache) in order to avoid the expensive JNDI lookups with the subsequent requests. It is named as <name>Util class and is automatically generated by xDoclet for every session and entity bean. This class is not an absolute necessity like the Home interface that we can not do without. It is an accepted EJB good practice that prevents redundant code replication. 3 - Value Objects Serialised Java objects that capture the state of entity beans by aggregating the individual fields of the bean in order to provide efficient remote access (get & set) methods. They are used together with the facade session beans. 4 - Facade Session Bean Wrapper classes that implement the facade pattern for the entity beans that are not suitable for direct use in distributed applications. They wrap the entity beans and provide, with the help of Value objects, efficient remote operations for them. The main reason that makes the use of facade session beans a necessity is the latency that is introduced by the remote method invocation. Remote method calls are realised via stub and skeleton proxy objects that are located on different nodes of the physical network layer. This introduces significant delay when compared with the local method calls and can not be avoided. Thus, it is no longer practical, for example, to create a Customer entity bean and make three method calls to obtain its Name, Surname and Initials fields. Something which would not be much of a problem with local method calls. The most practical solution, which is also a well known good practice, is to create a serialisable Java object (Value object) that encapsulates the individual fields of the entity bean and use this object as the parameter in the get/set methods of the bean itself. Since we need to use the local interfaces of the entity beans in order to communicate with the local clients efficiently (without the remote protocol penalty), we need the facade session beans in order to make these get/set methods available for the remote clients via their remote interfaces. In any non-trivial application, we often need to operate on the set of object instances that belong to a class. Although it is not a necessity, facade session beans can also be used as a higher level class that represents and operates on the set of objects of the original class. A simple example from the
36
PetStore application is the requirement to return the attributes of the set of products that match certain criteria. The facade session bean suits this role perfectly. By making this (search) operation available on its remote interface, it fulfils the requirement locally with the help of data access objects and value objects of the entity bean. Of course it is possible to implement this operation as a static method in the original class without creating a new class, but it is conceptually much cleaner and intuitive to have, for example, the CustomerTable class modelling and operating on the set of instances of the Customer class. The ironic part is that, the EJB model violates the encapsulation by splitting the operations of a single entity into multiple beans because of this model's inability to support distributed computing properly. HCM on the other hand, does fully preserve the encapsulation. Any HCM component, which may or may not have any state, is fully immune against the above mentioned anomalies and fully encapsulates all the operations that belong to itself. There is no need for any auxiliary class or a component. 5 - Data Access Objects (DAO) These are the helper classes for the complex database queries that can't be resolved by the finder methods. As mentioned before, the functionality of the finder methods included in the home interfaces are restricted and can not deal with complex queries. In that case we need the Data Access Objects that locate and return the required set of objects using SQL (over a JDBC connection) or the EJB Query Language. One example of the DAO object from the xPetStore implementation is the ProductDAO which returns the set of value objects of the products that have similar id, name or description field (using the LIKE function of SQL) with the given search word. 6 - Primary Key Classes The primary key class is an object that uniquely identifies an entity bean. A primary key can be any serializable type, including the Java wrapper classes for the primitive types (e.g. Integer, Long Double) or any custom class defined by the developer, but they can not be primitive types since they need to be treated as Object by a number of EJB interfaces. We will use an example task from the PetStore application in order to put everything that is presented in this section into perspective and consolidate our argument further. As depicted in Figure 6.2, our example task is made up of two sub-tasks. a) Getting the properties (id, name, description and status) of the set of Products that contain the search key-word "red" in its description field. b) Updating (setting) the value of the "status" field of the same set of Products with the value "ON". Note that in Figure 6.2 the name of the domain entity Product is abbreviated to Prod in order to simplify the diagram. The comparison of the models will be done according to the following criteria.
• Excluding the main domain entity (Product) component, the number of additional helper (support) classes that are necessary for the required functionality.
• Number of distinct programming steps that has to be completed by the user. What we mean by a distinct programming step is any piece of coding requirement that either makes use of a new helper class (in EJB) or creates and sets the parameters of a message (in HCM).
37
One important point about the comparison and the diagram (Figure 6.2) is that the plumbing that has to be provided by the respective technologies is completely ignored. The comparison is solely from the users' point of view: what they see and what they need to do in order to complete the tasks. Number of steps required with the EJB solution: 1) The first step is to obtain the home interface (ProdSBHome) of the ProdSB facade session bean that encapsulate the services of the original entity bean (ProdEB). We use the home interface factory class (ProdSBUtil) and the JNDI lookup service in order to get an instance of the home interface. 2) Using the ProdSBHome home interface we create an instance of the ProdSB facade session bean. 3) We make the searchProducts method call on the remote interface of the ProdSB facade session bean and pass the search criteria as the argument. 4) We are now in the EJB container and performing the searchProducts method of the ProdSB session bean. The first task of this method is to obtain the required properties (fields) of the set of products that match the search criteria. We need the product data access object to perform this task. We create the ProdDAO object and call its method that finds and returns the details of the set of products that match the given criteria. 5) Inside the ProdDAO, using the SQL query and the JDBC connection, we perform the first task which is to obtain the details of the set of products that match the given criteria. 6) We complete the first part of the task by creating a list of product value objects (ProdValue), to be returned to the EJB Client program, and populating them with the details of the products that were obtained in the previous step. The first part of our example task is completed in six steps. We continue with the second part of the task. 7) We use the existing ProdSB session bean and call its method to update the details of the set of products, passing the list of value objects of the products as the argument. 8) Using the ProdEBUtil factory class, we need to get the home interface (ProdEBHome) of the product entity bean (ProdEB). 9) Using the home interface we create/find the actual entity bean instances (ProdEB) for each product in the list. 10) As the final step, we update/set the value of each entity bean by calling the required method. The actual task of updating the product table doesn't concern the user since it is taken care of by the EJB container.
38
Figure 6.2 Comparison of the models in terms of the handling of the example task. Number of steps required with the HCM solution: 1) The first step is to create the message for the get function of the Record interface of the Product component (Product/Record/get) and set its parameters. As we can see from the following get message, the first parameter of the message (fields) is used to specify the names of the fields that we are interested in. The second parameter (where) is used to narrow down the number of records with the required predicate (our search criteria).
2) The second and final step to complete the first part of the task is to process the message. Internally, processing the message translates into two actions. Sending the message to the Repository and requesting the answer back. As the result of processing this message, we receive the response message that contains the set of partial records of the products that match the criteria.
We continue with the second part of the task which is also completed in two steps. 3) We create the message for the update function of the Record interface of the Product component (Product/Record/update) and set its parameters. Which properties of which records should be set to what values are all specified in this message.
4) Again, the second and final step is to process the message. The response of this message is the status of the update function that contains the error messages if there are any.
Table 6.3 compares the models in terms of the example Product Search/Update task. As we can see from the table, HCM requires 4 simple steps, without any need for the creation of additional (helper) components or classes, in order to complete the request that requires 10 distinct steps and 5 different types of 7 additional (helper) classes to complete with the EJB model. The important point that should be emphasised about this comparison is the fact that it is only measuring the comparative complexity of the models faced by the users. How much mental and physical work do the users of the model have to perform in order to accomplish the tasks? Hence, the speed and efficiency issues and how long each step may take by the respective technologies are ignored. Criteria EJB HCM
Number of required distinct steps
10 4
Number of additional helper class types
5 -
Number of required additional helper classes
7 -
Total number of classes (Including the Product EJB)
10 -
Total number of XML/HML definition records
1 1
Table 6.3 Comparison of the EJB and HCM models for the Product Search/Update tasks. The computing structure of the HCM model obviates the need for the 6 different types of additional helper classes that are essential for the acceptable functioning of the EJB components. The main domain entity in this example is the Product component. All we do in this simple example is to get the properties of the set of products that match certain criteria and subsequently update the status property of the same set of products. In correctly structured systems, as demonstrated by HCM, we shouldn't need the help of any additional classes apart from the Product component itself. The additional number of classes and the extra programmatic steps that have to be performed on behalf of the user are strong indications of the anomalies that have been created by the poor support that is provided by the computing model of EJB for the distributed processing and persistence. Of course we should re-emphasise the fact that EJB inherits these problems from the object-oriented model. Hence, any technology that is based on the object oriented model, .NET or CORBA Component Model (CCM) for example, will equally suffer from these problems. The bottom of Table 6.3 presents the total number of classes, which also includes the main domain entity (ProdEB) bean and its (home and remote) interfaces. While we don't need to create even a single class (source code) for the HCM solution, EJB requires 10 different classes to provide the same functionality. All that is required by the HCM component is the HML definition record that declares its persistent fields and extends the predefined system component Table that handles the persistence requirements.
41
We complete our analysis by looking at the models from a different perspective in order to highlight the different aspects of their advantages and disadvantages. We will do this by analysing the following semi-pseudo source code that we need to produce on the client side in order to complete the first part of our example task.
• With the EJB model we need to use two additional auxiliary classes before we can make the actual call for the search method, which is itself provided by the third auxiliary class, not the original entity bean. On the other hand, the first line of the HCM example creates the actual message that will eventually be processed by the original entity (Product_01 component). Full understanding of the nature and consequences of this first line of the source code will clarify the advantages and disadvantages of the HCM model. The most important point is that this message is created off line. Because of the proper message passing mechanism, we are completely de-coupled from the component which is the receiver of the message. Let alone getting some kind of reference or a handle for the component, we don't even care whether or not this component exists. This mechanism, the main advantage of which is to eliminate the first two types of helper classes (home interface and home interface factory) automatically, is not without its disadvantages. We will discuss these disadvantages later in this section.
• The second and third line of HCM example, while setting the parameters of the message,
also provides evidence of why we don't need another two helper classes that are required by the EJB model. Since the persistence mechanism of HCM, very much like SQL, is based on set operations, we can naturally specify multiple fields of the component as well as we can specify any sub-set of the records (via the where parameter) that we are interested in. HCM borrows the power of SQL and obviates the need for Value objects and Data Access objects.
Disadvantages of HCM Of course, there must be some price to pay for these significant advantages. While the structural changes that are introduced by the model provide significant benefits, they also introduce certain disadvantages that need to be taken into account. We will discuss these points with the help of the same source code examples given above.
42
Complete De-coupling. The level of independence and de-coupling achieved among the elements of the system does also introduce certain level of inefficiency in terms of the handling speed of the messages. In the EJB example, by the time we come to line 3, we will have the reference for the object that we need to invoke the method of. Especially, if this is a local reference, it means that we have the address of the object and we can jump straight into the method to be executed (ignoring the search time if the method is inherited from a parent class). When we reach line 4 with HCM on the other hand, we have got nothing but our message, which has to go through the following journey. 1) The message has to be deposited into the message queue (local or remote). 2) It then needs to be picked up by a free thread which locates the target component via the internal naming system that is completely hidden from the user. Upon finding the component we execute the method and put the result back into the queue to be picked up by the sender. 3) Eventually the system hands the response message back to the original sender. This mechanism doesn't have any problem with distributed processing and still compares fairly with EJB when the processing is local; especially when we take the processing done by the user in order to locate the product session bean (first 2 lines) into account. But what it can not compete against is the GenVoca components [SB98, Bat98] that break the encapsulation deliberately in order to compete with hand written Fortran and C++ libraries that are developed for scientific calculations. When we consider the fact that HCM's natural application domain is distributed multi-user application servers that are designed to handle hundreds of concurrent users, its inability to compete with component models designed for very efficient local computation shouldn't be considered as a serious disadvantage. Runtime Type Checking. Another reason for the HCM's flexibility and the source of its advantages is the fact that there is no compile time type checking. Type checking is delayed as much as possible and done at runtime. This enables us to delay the tasks as much as possible and do it later internally by the HCM runtime system. As a result HCM manages to hide more complexity from the user and performs more tasks internally which are required to be done by the user in EJB. The downside of this mechanism is that we can not detect the faults at compile time. Any syntactical mistake that we make while building up the message (first 3 lines of the example source code) can not be caught during the compilation. We have to wait until we process the message (line 4) at runtime in order to discover the syntax errors. But again this is a design decision which delivers huge advantages that makes this disadvantage relatively insignificant. The recent increase of the popularity of the languages with dynamic type checking (e.g., Python, Ruby) also supports our decision that the advantages provided by the dynamic runtime type checking are (or becoming) more important than their disadvantages. 6.3 Comparison with the Java Data Objects (JDO) as an Alternative Persistence Mechanism In this section we will evaluate an alternative persistence mechanism for Java objects, Java Data Objects (JDO) [JDO02], and compare it with the persistence mechanism of HCM. JDO is an emerging new standard that is designed to allow the developers to concentrate on the business solution transparently, without worrying about the infrastructure code to map between objects and databases. Although it is relatively a new standard, there are already a number of implementations available and the number of vendors is growing fast. The main objective is to provide a more
43
transparent and natural persistence for Java objects. It differentiates itself from Object-Relational mapping tools by targeting Object databases and other type of data stores as well as the relational databases. Similar to JDBC, the JDO API is a standard API that a developer can learn once and use everywhere. The ultimate objective of the standard, while making the data base access more transparent and seamless, is to provide vendor and database independence. The same application should be able to use different vendor's JDO solutions and target different databases without any change. There is no built-in remote behaviour with the JDO classes. All of the transaction and security policies are based on the single Persistence manager that manages all of the persistent instances of our model. This means that JDO persistent classes can be used in any tier of a distributed application and the remote behaviour is implemented either by the container or by the developer (via RMI), not by the JDO implementation. Developing a JDO based implementation consists of the following steps [SF02]:
• Creation of the mapping file to specify which tables and columns belong to which Java classes and attributes.
• Implementation of the persistent capable classes. • Implementation of the persistent aware classes (classes that use the persistent capable
classes). • Using the enhancer tool to modify the byte code of our persistent capable classes so that
the data in the data store is read and modified according to the methods called by the application.
JDO persistent classes are suitable for modelling both coarse-grained and fine-grained persistent instances with (in a container) or without (as stand-alone) an application server. While it provides more transparent persistence than the JDBC alternative, they are very similar to EJB/CMP solution in terms of the functionality and usage. They are typically used behind (facade) session beans. However, there are also a number of problems with the JDO model. 1 - Query Language Issues: As stated by [Raj03], the JDO Query Language (JDOQL), which is totally different from EJBQL, requires additional parsing processes during query execution that makes it more resource intensive. Additionally, the use of String filters presents another problem, since the potential typing errors in the query strings can only be detected at runtime. JDOQL consists of Java boolean expressions and Java field traversals. Boolean expressions are used to form the equivalent of SQL's WHERE and HAVING clauses. Field traversals are used to form the equivalent of SQL's SELECT, GROUP BY, and ORDER BY clauses. Basically, in an effort to make it more transparent, the query language is moved away from SQL and brought closer to the Java language and OO databases. Of course this feature could be regarded as an advantage as well as a disadvantage. 2 - Byte-code Enhancement: Persistence classes need to be enhanced after the compilation in order to insert the code that will provide the required functionality. Byte code enhancement is the most severely criticised feature of JDO [KM03]. Rightly so, people don't like things being done to their code which they can't see in the source code. However, the JDO specification itself does not prescribe how the modifications are to be made; only the contract that is to be supported. JDO implementations that provide
44
source-code enhancement address these concerns effectively. Unfortunately this solution does also introduces the problem of dealing with multiple source codes, one for the development and the other one for debugging (after the enhancement). 3 - Backward step in Encapsulation and the Implementation of Transactional and Security Requirements: Despite its well known problems, EJB does one thing very well. It enforces strong encapsulation through managing component state, transactions, and security from within an insulated layer that is protected from the client by the component interface. While failing to address any of the problems of the EJB/CMP persistence mechanism, JDO introduces even further problems by breaking this encapsulation. The problems with JDO centres around the relationship between two entities: an instance of the component (class) itself and the instance of a Persistence manager. The client of the persistent object uses the methods of the Persistence manager to ensure that the data is being moved appropriately between the object and the data store as well as managing the transactional and security requirements. All this functionality that is implemented by declaration without any programming by EJB, now has to be implemented programmatically by the client (persistence aware class) code. The most important disadvantage is the reduced productivity, since we have to write, compile and test the necessary code instead of simply declaring the required attributes of these services in an XML document.
Many of the methods of the persistence manager, like getObjectByID, are harmless. But there are other methods that are not so innocuous. The persistence manager also includes methods that disable transactions, flush caches, and delete objects (data) from the database. This feature defeats the whole purpose of Object and/or Component oriented programming, which is hiding the implementation details from clients. The most practical solution for this problem is to hide the details of JDO, and at least not allow the persistence manager to be visible to the outside world, which is similar to the approach taken to remedy the architectural problems with EJB entity beans: hide them behind facade session beans that provide the remote business interface while hiding the local implementation details from external clients.
4 - Multiple İdentity types: JDO specification defines four identity types; data store identity, application identity, simple identity and non durable identity. We can easily ignore the last two types since the simple identity is just a special case of the application identity in which there is only one primary key field, and non durable identity is an optional part of the specification that is meant to support persistent objects that doesn't need unique identities (things like persistent log messages). Nevertheless, we are still left with two different identity types. Out of these, application identity, is the identity value that is required/managed by the application (i.e. primary key fields) and can not be avoided. Data store identity on the other hand is the identity that is required/managed by the persistence service and could be avoided by more transparent and abstract persistence mechanisms. Ideally, as is the case with HCM, there should be only one identity type in order to provide a more transparent and cleaner persistence mechanism.
45
Example Task to Compare HCM and RMI/JDO alternatives. In this example we will compare the programmatic steps required by the HCM and RMI/JDO solutions in order to implement the debit functionality of a remote Credit card component. RMI/JDO solution. Steps implemented by the client. 1) Obtain a remote reference for the Credit card remote object from the Credit card server (Naming service for the RMI). 2) Invoke the debit method of the Credit card remote object. Steps implemented by the Credit card persistent object on the server. 3) Obtain a configured Persistence Manager Factory (PMF) from the JDO Adapter; obtainPMF(). 4) Get a Persistence Manager using the configured PMF; getPersistenceManager(). 5) Use the Persistence Manager to obtain a Transaction object; currentTransaction(). 6) Begin a new Transaction using the Transaction object; begin(). 7) Invoke its own debit method; debit(). 8) Commit the transaction by invoking the method in the Transaction object; commit(). 9) Close the Persistence Manager; close(). 10) Close the JDO Adapter; close(). In this example the Credit card class assumes both of the roles of persistence capable and persistence aware classes of the JDO model. HCM solution. 1) Create the message for the debit function of the Credit card component. 2) Execute the message (send and receive the response). As demonstrated by this simple example, HCM provides a cleaner solution that operates on a higher level of abstraction. All the infrastructure code and unnecessary detail is hidden from the user. The RMI/JDO solution on the other hand needs a lot of programmatic steps for the implementation of the services provided declaratively by the HCM and EJB models. When we consider the fact that relieving the application developers from the low level details of RMI programming was one of the main objectives of the EJB model, the RMI/JDO solution could be considered as a backward step. As analysed by [KM03], JDO appears to be the best technological approach to be combined with stateless session beans in a J2EE/EJB environment. It is the direct alternative or replacement for the EJB/CMP persistence mechanism. Finally, the paper by Schiefer and Fecht [SF02] evaluates the several established standards for accessing data in the Java community: JDBC [JDB98], SQLJ [SQLJ99], JDO [jdo], EJB/CMP [EJB01]. In fact, the paper reflects the experience gained at SAP in their effort to provide a single consistent model of accessing the data that satisfies the following qualities; portable (database-independent), elegant and seamless data access, efficient bulk data operations and conformance to the Java standards.
46
In summary, none of these technologies alone seems to be able to provide the basis for the development of large enterprise systems. While the paper discusses the reasons for this, it also outlines the approach taken at SAP which was the development of a J2EE compliant application server that offers amongst other needed services, a combination of all the described persistence strategies. As far as this research is concerned, another important point that is raised by Schiefer and Fecht is that both transparent persistence strategies (CMP and JDO) have a conceptual problem when updating many data records. When we consider the example of increasing the salary of all employees by 3%, transparent persistence follows the record-oriented (instance-oriented) programming paradigm of the Java language. Therefore one record after another has to be read from the database, updated in memory and written out at commit time, which is an extremely inefficient solution for this task. As discussed in section 6.2 in detail, this point is also identified as one of the fundamental problems with not only the Java language itself, but the object-oriented model of computing in general. Efficient bulk data operations are an unavoidable part of any real world application, and the working model of SQL, which is based on set-oriented query and update operations, is much more suitable to deal with these operations when compared to the instance (record) oriented computing model of object orientation. Schiefer and Fech conclude that the combined and complex approach that is taken by SAP is far from being the optimal solution and the research and standardisation efforts have a long way to go in order to create a single consistent technology that is completely transparent and seamless. Due to its database model which is based on set-oriented get, set and update operations, HCM provides a promising candidate for this ideal persistence mechanism. This vendors’ well established experience and reputation in delivering scaleable multi-tier Enterprise Resource Planning (ERP) applications adds extra weight to their findings and increases our confidence regarding the direction taken with the persistence mechanism and the database model of HCM. 6.4 Comparison in terms of the Reference Application Implementations In this section we present a high level comparison of the hPetStore and xPetstore implementations. As mentioned before, xPetstore [XPet] is the re-implementation of the PetStore reference application using the xDoclet [XDoc] code generation technology. Appendix A provides a brief introduction to the xPetStore implementation and the xDoclet technology. The important point that we need to clarify is the fact that xDoclet technology doesn't take part in any of the comparisons here. We are not comparing the HCM model or the hPetStore implementation with the xDoclet technology. It is just a convenient tool to generate the EJB applications. The thing that is compared with the hPetStore implementation is the EJB application (xPetStore) that is ultimately generated by the tool. As far as this comparison is concerned, there would be no difference whatsoever if the xPetStore implantation were programmed completely manually, without the help of any code generation technology. Another fact is that the original PetStore implementation and the xPetStore implementations don't use the same domain components (objects), nor do these components map to the same database schema. But the overall functionality of these implementations are more or less the same. In order to increase the validity and accuracy of our comparison with xPetStore, we used the same database
47
schema and provided the same functionality as much as possible. This functionality is provided on the specification page of their web site [XPet]. Of course, despite the same database schema and similar functionality there are differences between the domain specific components that are used by these implementations. This was also one of the reasons why we didn't include any low level comparison of these implementations, such as the number of lines of source code, and concentrated on the higher level abstract properties. Table 6.4 provides the mapping between the database tables and the domain components of each implementation and the domain entities of the reference application. Domain Entity xPetStore Table EJB Entity
Table 6.4 The mapping of the domain entities and the corresponding tables and the components of the xPetStore and hPetStore implementations. The Login table of hPetStore is merged into the User table since it contains only one field (password) and shares the same id. There is also no need for a separate Order item table with the hPetStore implementation. Since the HCM data model can handle multi-dimensional repeating data elements, the Order table maintains the required number of references to the individual Order items. Finally, in order to make the implementation more practical, hPetStore uses two additional tables (Card and Mail) that simulate the required functionality of updating the credit card account and sending an acknowledgement email. Apart from these, there is not much difference between the implementations; both models use their respective stateful component types (CMP and SISC) to implement the application domain entities. Both implementations use more or less similar domain specific components (entities), in terms of their type and number. We are not interested in detailed comparison of these domain components. Our main comparison point will be the amount of additional elements (supplementary helper classes and interfaces) that have to be created in order to support the domain specific components of each implementation. These support elements are not related to the application domain. Their whole purpose is to provide additional infrastructural support for the normal (acceptable) functionality of the applications. They remedy the anomalies that are introduced by the weaknesses of the technologies. The point is that, with better structured technologies there should be no need for these elements.
48
As analysed in section 6.2 in detail, the above listed entity beans of the xPetStore implementation can not be used directly in a realistic application. They need the helper classes that are listed in the following table (Table 6.5). Element Count Method
Count Funtion
Facade Session Beans
3 47 Wrapper classes that implement the facade pattern for the entity beans that are not suitable for distributed processing. They wrap the entity beans that provide only local interfaces and, with the help of Value objects, provide efficient remote operations for the remote clients.
Message Driven Beans
1
10
They provide similar functionality as facade session beans with the only difference that they are activated with asynchronous message passing
Value Object classes
7
196
Serialisable Java objects that capture the state of entity beans by aggregating the individual fields of the entity beans in order to provide efficient remote access (get & set) methods. They are used together with the session beans that implement the facade pattern for the entity beans.
Local/Remote Home interfaces
11
22
Interfaces that provide methods for the creation and finding of the individual bean instances. They are required for both session and entity beans.
Home Interface factory (Util) classes
11
11
Reduces code replication by encapsulating the code that is necessary for accessing and caching the Local/Remote Home interfaces of session and entity beans.
Data Access Objects
1
3
Classes for complex DB queries that can't be resolved by finders in the Home interface.
Counter & UID Generator classes
4
25
Classes used to generate unique identifiers for the entity beans. They also use an entity bean to maintain the state of running ids.
Totals
38
314
Table 6.5 The auxiliary support classes and their method counts that are required for the normal functioning of the xPetStore implementation. The most important metrics in this comparison are the 38 support classes, together with their 314 methods, that are necessary for the normal functioning of the 7 entity beans of the xPetStrore implementation. Like HCM, in better structured computing models there is absolutely no need for these classes. They are simply redundant additions in order to support the technology, not the business functionality.
49
The second important metrics reflect the total amount of effort (total number of source code elements, number of methods and XML/HML definition elements) that is required by the respective implementations. Table 6.6 and Table 6.7 provide these details for the xPetStore and hPetStore implementations respectively. The final table (Table 6.8) compares the totals of both implementations in the same table. Element Category Count Method
Count Type
Business Interface 11 60 Source code
Home Interface 11 22 ''
Implementation classes 34 268 ''
Helper classes 23 235 ''
Deployment Descriptor 11 - High level XML definition
Totals 90 585
Table 6.6 Element and method count metrics and element types for the xPetStore implementation. Note that in Table 6.6 class and method count totals for the Helper classes element category are reduced (see Table 6.5) in order to take the overlapping classes (Home interface classes for instance) that belong to more than one category into account. Additionally, the Implementation classes category of Table 6.6 includes the remainder of the classes of the xPetStore implementation that don't belong to any other category in that table. Element Category Count Method
Count Type
Pinset record 2 - High level HML definition
Interface record 2 - ''
Definition record 7 - ''
Implementation record 2 10 ''
Implementation class - - Source code
Totals 13 10
Table 6.7 Element and method count metrics and element types for the hPetStore implementation.
50
Property xPetStore hPetStore
Number of low level elements (Source code elements as Java Classes or Interfaces)
79 -
Number of high level elements (Declarative XML/HML definitions)
11 13
Total number of elements
90 13
Percentage of the low level elements to total number of elements
87% 0%
Total number of methods/sys-procs
585
10
Table 6.8 Comparison of the xPetStore and hPetStore implementations in terms of the element totals and the percentage of the source code elements to total number of elements. As expected, there is a significant difference between implementations. In terms of the total number of elements that are needed, xPetStore requires almost 7 times the number of elements (90) that is required by hPetStore (13). Even more significant is the percentage of the low level elements to total number of elements. While 87% of the xPetStore implementation is low level elements, there is no need (0%) for low level elements in hPetStore. In other words, we not only need to produce a much reduced number of elements (building blocks) with the HCM solution, but also, all of these elements are high level declarative HML definition records (the composition language of HCM) that don't require any serious effort or specialised skill. That is why 5 out of 7 domain components of hPetStore are implemented by pure composition using only the component definition record (as demonstrated in section 6.2). Only 2 of the domain components (Order and Mail) of hPetStore require some programming which is implemented entirely with HCL without requiring any low level programming with the host language (Java). As presented in the Method Count column of Table 6.7, only 10 sys-procs were used to implement the entire programming requirement of the hPetStore implementation. The following extract from the implementation record of the Order component, presents 4 of these sys-procs in order to demonstrate the level of abstraction provided; especially when compared to the methods of a Java class. Appendix B provides a detailed introduction to sys-proc and the composition language of HCM. sys-procs_{ Order-status_{ # Set the where property of the output msg 0 with the "id = '@'" string and than # insert the value of the order-id property of the input msg 0 inplace of '@' character set_value-of_"pro.o0.where"_with_"str.id = '@'"_insert-value_"pro.i0.order-id" } Order-close_{ # Set the parameters of the output msg 0 with the parameters of input msg 0 set_params-of_"msg.o0"_with_"msg.i0" set_value-of_"pro.o1.where"_with_"str.id = '@'"_insert-value_"pro.i0.order-id" set_value-of_"pro.o2.where"_with_"str.id = '@'"_insert-value_"pro.i0.user-id" }
51
Order-close3_{ set_params-of_"msg.o0"_with_"msg.i0" } Order-close4_{ # Set the to property of the output msg 0 with the value of the # table/record/fields/user-id property of the input msg 0 set_value-of_"pro.o0.to"_with_"pro.i0.table/record/fields/user-id" # Add the table/record property of the input msg 0 # to the data property of the output msg 0 add_pro_"pro.i0.table/record"_to_"pro.o0.data" }} The very significant difference between the implementations confirms the fact that in EJB, due to the model's failure to hide the infrastructural details of the computation from developers, significant amount of additional programming, which should otherwise be redundant, has to be done. Secondly and equally importantly, there is no separation between the language in which components are built and the language to compose them. Java is the only language that is used for both tasks. We have to edit and compile Java code even for the simplest compositional tasks. The situation is almost exactly the opposite with HCM. Firstly, as supported by the results provided in the tables of this section, structural changes of the HCM computing model mean it is better suited to distributed computing and handles the persistence in a seamless way. Secondly, not only is there a difference between the languages for the implementation and composition of the HCM components, but also the composition language (HCL) is designed to be a high level, declarative, interpreted language that is defined in HML, which is why the amount of programming is minimised by realising most of the work in this language. Most importantly, the entire application is built with the composition language, using only the existing system components without having to create any new components specifically for the application. From these comparisons, it should be obvious that we are not comparing like with like. These are two technologies that are operating at completely different levels of abstraction. In fact, the comparison of the EJB and HCM is very much like the comparison of the following single line of SQL query with the equivalent Java program that accomplishes the same task in 15-20 lines of procedural code.
SELECT id, name, description, status FROM Product WHERE description LIKE 'red' While the SQL query states declaratively what is required, the Java program procedurally states how the task should be performed: get a database connection, open the table, read all the records, check every record for the condition, put the requested columns of the selected records in a list, and finally return the result. Of course we are not cutting any corners here. The processing that is required by the Java program doesn't simply disappear into thin air. In the case of the SQL query, the very same processing is done by the system program that interprets the query. The responsibility of doing the actual job is shifted from the user to the technology or the tool itself. By encapsulating the full functionality of SQL as an HCM component and providing a declarative type extension mechanism that doesn't require any programming, HCM effectively manages to raise the abstraction level from 3rd generation imperative programming to the next level of declarative programming. This generation gap does also explain the big difference between the amount of programming that is required by these technologies. Instead of programming in detail
52
how a task should be performed, the developers simply declare what the task should accomplish and leave the rest to the HCM runtime system. As discussed at length by [Llo94, POM03], declarative programming has a substantial positive effect on the overall productivity by having a significant positive effect on the understandability and maintainability of the systems. 7 Summary of the Results This section presents a summary of the overall results and the verification of the HCM's computing model by comparison with the results, proposals and findings of other related work. We have identified the different structure of the computing model of HCM as the chief reason for these successful results. This structure is based entirely on our reference model and strict adherence to this model means that the model deviates from the conventional model of computing, which is mostly object oriented, considerably. The following is a brief summary of the main characteristics of the HCM model.
• Strictly one way asynchronous message passing; which means that we can not make synchronous method calls nor can we return anything back.
• Built in persistence mechanism that is based on the stateless components which represent and operate on the whole or any required subset of the records (instances) of the entity that is being modelled.
• Delayed runtime type checking. • All system and user data in the system is uniformly represented with HML. • Clean composition and type extension mechanism that, while preserving the encapsulation
strictly, only requires the use of the high level declarative HML notation without any need for low level programming.
The effect of these properties are twofold. Firstly, the combined effect of these properties was very effective in eliminating the problems that require extra effort, which is mostly in terms of programming, in other technologies. Secondly and equally importantly, these properties enabled us to bury most of the complexities and unnecessary details into the HCM runtime system and hide them completely from the users (the developers). Because of the combined effect of these properties, we can hide considerably more infrastructural detail than other technologies. The result is a simple and clean component model that doesn't require any more physical or mental effort than is absolutely necessary. One interesting and equally important consequence of this is the fact that almost the entire responsibility for delivering these concrete benefits rest on the model itself. In other words, the tool or the technology takes the full responsibility in delivering the benefits and relieves the developer from this responsibility. Implications of this important quality will be discussed further in the conclusion section. We have to emphasise the fact that we are not getting something (all these advantages) out of nothing. One important, but not so obvious consequence of pushing the abstraction level of the technology from 3rd generation languages to the level of declarative programming, and burying all these complexities and difficulties into the runtime system is, the considerable increase in the complexity of the tool itself. While making the lives of the users of the tool much easier, we equally made the lives of the people that make the tool much more difficult. Thus, it is much more
53
difficult to built an HCM runtime system than it is to create an EJB container. But this is a deliberate design decision rather than a disadvantage. Since the component model software and system tools are developed by relatively few experienced developers with highly specialised skills, this should not be a disadvantage. The significant advantages delivered by the technology for the much higher number of application developers more than compensate for this disadvantage. Finally, the conformance of the results of this research with the following technologies, definitions and proposals, have further increased our confidence in the approach taken by the research. Difference between the Component Development and Component Composition Languages. According to Wuyts and Ducasse [WD02], composition mechanisms for black-box components should be the major focus for newly emerging pure component languages. Most importantly, they specifically propose having a difference between the language in which components are implemented and the composition languages to compose them. In HCM, not only is there a difference between the language to develop the components and the language to compose them, but also this difference turned out to be very important factor in enabling the non-professionals to produce solutions by the composition of components produced by (professional) developers. The main advantage of this separation is that we can choose (as happened in HCM) a high level declarative notation for the composition language, making it possible to be learned and practiced easily by any domain professional who knows little about programming. Important Characteristics of the Component and the Principle of Independent Extensibility. Szyperski's definition [Szy00, Szy02] of the characteristic properties of a component are;
• it is a unit of independent deployment; • it is a unit of third-party composition; • it has no (externally) observable state.
While the first two of these characteristics are widely appreciated, the last one, which in our opinion hasn't received the attention that it deserves, also turned out to be one of the important characteristics of the components in HCM. Szyperski also stated that one important implication of this characteristic is that the component can not be distinguished from copies of its own and makes little sense to have multiple copies of the same component. In a way our experience confirms and consolidates this definition, but also carries important implications for other research efforts trying to create better software component models based entirely on (naturally) stateful objects. A system is independently extensible if it is extensible and if independently developed extensions can be combined [Szy96]. The independent extensibility principle, which is defined to be the principle function of component orientation [Szy02], was at the heart of HCM right from the beginning. As emphasised previously, selection of a higher level composition language which is different from the language used to develop the components played a major role in achieving this objective. The Law of Demeter (LoD). As paraphrased by [Smy98], the Law of Demeter [LR89] can be stated as; Any method must operate only on the object's existing state and the arguments to the method; no data shall be required from any other source during the execution of the method.
54
One important implication of this law is that no method should be allowed to return any value (one-way asynchronous data flow), otherwise the caller can not obey the law. But above all, the most important observation made by Smyth [Smy98] is the fact that the law simply formulates the principles of data-flow computation in the context of objects. The importance of this observation from this research's point of view is that the computation model of HCM is also the formulation of the same principles in the context of components. Since our main objective was to capture and replicate the component model of hardware, the conformance of the principles of HCM to data flow computing or more specifically to data flow machines shouldn't be surprising. As discussed in the related work section in more detail, the data flow machines are computers (hardware) that are optimised for fine-grained data-driven parallel computation. The close connections between HCM, data flow machines and functional languages are evaluated further in the relevant work section. Achieving the same results and principles with two independent research efforts can be interpreted as the confirmation of the validity of these results. The Law of Demeter, which was formulated 15 years ago, is now an established technology that is also the foundation for the Adaptive programming and Demeter/Java technologies. The results with Demeter/Java have been very encouraging and successful in several commercial projects [Dem]. 8 Related Work Although there is broad agreement [FF01] that software component technology will eventually provide the answers for our problems, there is almost no agreement on exactly what a software component is nor any agreement on how components should be produced. The number of approaches and technologies that have been proposed for software components so far provide more than enough evidence of this. That is the reason why it is almost impossible to do full justice covering the whole range of related work. Our approach is to divide the related work into two broad categories and evaluate each related technology under one of these headings; Distributed Component Architectures and Data Flow Computing. 8.1 Distributed Component Architectures The relevance of this category of related work is that HCM and these technologies (COM, .NET, EJB, CCM and Web Services) are designed to solve the same type of problems and applications. HCM naturally positioned itself as an alternative for these technologies in terms of the target application domains, but doesn't share much similarity regarding the structure and methods employed by these technologies. While these technologies are mostly based on object-orientation, HCM deviates from this popular approach in its attempt to emulate the hardware systems and uses different computational structures that it shares with other related work that mainly falls under the Data Flow computing category. CORBA [Cor95] is one of the oldest technologies in this category. It was released in 1991 in its initial version 1.1 [Szy02]. The currently known and successful standard is CORBA 2 (version 2.0) released in July 1995. CORBA started mainly as a remote method invocation protocol for distributed objects, supporting multiple languages and platforms. Over the years the specification included more services and became excessively complex. The OMG (Object Management Group)
55
has defined 13 services for CORBA compliant implementations. EJB specification includes only 7 of these services. CORBA 3 is the latest incarnation of the suite of CORBA standards. The most important contribution in this new release is the latest CORBA Component Model (CCM) which is effectively an ambitious logical extension of EJB [Szy02]. While promising to be fully compatible with existing EJB solutions, it aims to extend the EJB by maintaining CORBA's original advantage of being both platform and language independent. In our opinion, although notoriously complicated, COM [Com95] was a better component model than .NET [Net99]. In COM, before you can talk to any component, you have to define the interfaces (using the interface definition language) that must be implemented by the component, which was a better design since the interface and the implementation of the component are cleanly separated. Like HCM, COM interfaces are mandatory and immutable and most importantly there is no implementation inheritance. Letting the developers bypass the interfaces and talk to components (classes) directly and allowing the implementation inheritance in .NET can be considered as a backward step. Improving the deficiencies of COM and simplifying it as much as possible were among the important objectives of .NET [Cha02]. It uses the Common Language Runtime (CLR) technology in order to extend the language independence mechanism of COM. Because of the level of the common type system, which is effectively defined below the level of languages, .NET languages need to be syntactically and semantically moulded in to .NET's common object model [BS02]. With the exception of C#, every .NET language needs syntactic changes and additional reserved words in order to support the common object model. The .NET languages are first compiled into generic (virtual) machine code (Intermediate Language) and later further compiled into native code at runtime [Lid02]. This means each language needs a new compiler for this initial compilation process in to the common intermediate language. The level of the common type system of HCM is positioned above the languages. This means you can use the language of your choice and simply implement the model. Languages and their compilers don't need any change, nor there is any need for additional compilers, which is why the language independence mechanism is much simpler and cleaner. On the other hand, due to being first compiled into Intermediate Language and later further compiled into native code at runtime [Lid02], the .NET model does have two advantages. The native code will obviously run faster at runtime, but even more importantly, components developed with different .NET languages will be able to run side by side in the same container or process. The language and platform independence mechanism of HCM is very similar to the evolving Web Services model. Although the two models are structurally very similar, their initial purpose and objectives are (or at least were) completely different. While web services started as the Internet integration technology (glue) between the above mentioned common component models and other legacy applications, HCM was designed from scratch as the replacement of these component models. The most attractive feature of web services is the simple and effective language and platform independence mechanism (which it shares with HCM) that, together with its fire-wall friendly transport mechanism (HTTP), makes it an ideal business to business (B2B) integration tool. A framework for components on the Web requires more advanced features than the Web services framework or distributed computing models for objects can deliver [PW02]. The extension from Web Services to Web Components has already been investigated by [CMW01] and their work is carried further by [PW02].
56
8.2 Data Flow Computing In general there are two varieties of data flow computation [Sha92].
• Data-driven: Operations are executed in an order determined by the availability of input data.
• Demand-driven: Operations are executed in an order determined by the requirements (need) for data.
The data flow approach is often associated solely with data-driven computation. The general way of representing computations in the data flow model is based on a graphical notation for programs with nodes representing operations and arcs representing data dependencies. To understand what kind of language is suitable to support the data flow paradigm, we have to take into account the following properties of the data flow model [BG94].
• The model includes (named) values only; there are no variables. • There can be no side effects. Each process sees only its own input values and can only
effect its own output values. • There is no global memory; the only memory exists in the interfaces between the
processors. • Values can be given names, but there can only be one such definition of a given name. • Since there is no central program control to do error handling, each process must terminate
and yield a result value. This requires an explicit error value for each data type. The important observation is the exact match of the above listed properties of the data flow model and the properties of HCM's computing model. When we evaluate the available programming languages in terms of these properties, we can immediately see that one language type fulfils the above requirements perfectly: functional languages. They use no variables, they have no side-effects, they have no global memory, they are single definition and many of them have error values. As a result, functional languages are ideal languages to program data flow machines [BG94]. This observation underlines the close relationship between HCM, data-flow computing and functional languages. Data Flow Machines. Data flow machines are computers (hardware) that are optimised for fine-grained data-driven parallel computation. Considering that with HCM we are trying to capture the qualities of hardware systems, this (almost) exact match of the properties of HCM and Data Flow computing shouldn't be surprising. First implementations of data-driven execution (introduced in the 1950s) was in the form of asynchronously operating in/out channels which communicated according to ready/acknowledge protocol [Veen86]. There are a wide range of data flow machines with different architectures, different emphasis, using different terminology and illustrations. Despite the similarities between data flow machines and HCM in terms of structure, the overall objectives of these models are completely different. Data flow machines are optimised for fine-grain data-driven parallel computation. The main objective is to increase parallelism and exploit the full potential of hardware resources [Veen86]. This parallelism has to be fine-grain which means that processes that run in parallel are more or less equal to the size of the machine code instructions. As far as HCM is concerned, increased level of implicit parallelism is only the side effect of our efforts to capture the compositional and
57
reuse characteristic of hardware systems, which was our main objective in this research. As far as granularity is concerned, the HCM processes that run in parallel can only be classified as coarse-grain. Flow Based Programming (FBP). In FBP computing model, a network of processes, which are connected with via intelligent connections and ports, execute in parallel and communicate asynchronously [Mor94]. Data that travels between these nodes, which are called Information Packets (IP), are sent (write) and received (read) explicitly by the processes. Because of this feature FBP is demand-driven rather than data-driven like data flow machines and HCM. Connections provide intelligent buffering/storage with capacity for number of IPs. HCM has no intelligent connections (buffering or any processing between sockets & plugs). FBP is more suitable for batch processing because of the intelligent buffering provided by the connections. IPs contain information or switches which may change the traversing/selection between processes provide part of the logic. They have a control aspect as well as a data aspect. In HCM the entire logic is provided by the processes inside the components. Data that are processed are pure data that do not contain any logic or selection criteria. Despite these differences with HCM, FBP is a good commercial example to demonstrate the effective reusability delivered by the combined effect of data flow computing and de-coupling that is provided by the connection ports. 9 Conclusion The results obtained from this research, apart from being very encouraging and promising for the research itself, has important implications for the research efforts with which it shares the common objective of creating a better software component technology. One important implication is that almost the entire responsibility in achieving our objectives rests on the tool or the technology itself, it has got nothing to do with any process, method or required skills of the practitioner. This ought to be a strong indication for the efforts that concentrate mainly or entirely on the processes, methods and the learned skills of the practitioner. The tool takes care of the difficult part of creating components and makes sure that everyone, regardless of their level of skill, knowledge or experience, produces reusable components. This result is in line with the problem and its suggested solution presented by Brooks decades ago: The gap between the best software engineering practice and the average practice is very wide, perhaps wider than in any other engineering discipline. A tool that disseminates good practice would be important. [Bro87] Another implication is that these encouraging results were mainly caused by the structural changes introduced into the classical object oriented model of computing on which most research efforts are based. We demonstrated that there are significant benefits to be gained from shifting the emphasis from individual objects with state to stateless components that operate on sets of objects. As a welcoming side effect, HCM does also highlights the fact that data flow computing and functional programming models could provide very effective mechanisms in our search for a better software component model.
58
Ultimately, the results obtained so far support the main argument of the research; if we identify the important properties of hardware component model and transfer them successfully into an equivalent software model, we can achieve the same levels of reuse that are normally attributed to other more mature engineering disciplines. References [ALS01] F. Achermann, M. Lumpe, J.-G. Schneider, O. Nierstrasz. Piccola – a
small composition language. In H. Bowman and J. Derrick., editors, Formal Methods for Distributed Processing, an Object Oriented Approach. Cambridge University Press., 2001.
[AN99] F. Achermann, O. Nierstrasz. Applications = Components + Scripts – A Tour of
Piccola. In M. Aksit, editor, Software Architectures and Component Technology. Kluwer, 2001. to appear. Separation of Concerns. In Proceedings of ICSE’99, pages 107–119, Los Angeles CA, USA, 1999.
[Bat98] D. Batory, Product-Line Architectures, October 1998. [BG94] H E Bal, D Grune. (1994) Programming Language Essentials.
Addison-Wesley Publishing Company. [BDW03] A. Bergel, S. Ducasse, R. Wuyts, Classboxes: A Minimal Module Model
Supporting Local Rebinding, In Proceedings of JMLC 2003 (Joint Modular Languages Conference), LNCS, Volume 2789, Springer-Verlag, pp. 122--131.
[Bro87] F. P. Brooks. (1987) No Silver Bullet: Essence and Accidents of Software
Engineering, IEEE Computer, April, 1987. [BS02] D. Box, C. Sells. Essential .Net Volume 1. Addison Wesley (November 13,
2002). [Cha02] D. Chappell. Understanding .NET: A Tutorial and Analysis (Independent
Technology Guides). Addison Wesley (February 26, 2002). [CKF02] M. Y. Chen, E. Kıcıman, E. Fratkin, A. Fox, E. Brewer. Pinpoint: Problem
Determination in Large, Dynamic Internet Services. Proceedings of the 2002 International Conference on Dependable Systems and Networks, p.595-604, June 23-26, 2002
[Cle95] Paul C. Clements, From Subroutines to Subsystems: Component-Based Software
Development, American Programmer, Vol. 8, No. 11, Nov. 1995. [Com95] Microsoft Corporation. The Component Object Model (Version 0.9), Oct. 1995. [Cor95] Common Object Request Broker Architecture (CORBA). Version 2.0. Object
Management Group (OMG) 1995. (www.omg.org).
59
[CCM02] CORBA Component Model (CCM). Object Management Group (OMG) 2002. (www.omg.org/ccm).
[CMW01] F. Curbera, N. Mukhi, S. Weerawarana. On the Emergence of a Web Services
Component Model. In Proc. 6th Int. Workshop on Component-Oriented Programming WCOP2001.
[Cza00] K. Czarnecki and U. Eisenecker. Generative Programming. Methods, Tools, and Applications. Addison-Wesley, 2000. [Dem] Demeter Research Group. Online material on Adaptive Programming,
Demeter/Java, and APPCs. http://www.ccs.neu.edu/research/demeter/ [EJB01] Enterprise Java Beans Specification, Final Version, Version 2.0, Sun
Microsystems Inc., (2001). [FF01] P. H. Frohlich, M. Franz. On Certain Basic Properties of Component Oriented
Programming Languages, Proceedings of the First OOPSLA Workshop on Language Mechanisms for Programming Software Components (2001).
[GHJ94] E. Gamma, R. Helm, R. Johnson, and J. Vlissides. Design Patterns. Addisson-
Wesley, 1994. [Har93] W. Harrison and H. Ossher. Subject-oriented programming (A critique of pure
[HC01] G. T. Heineman, William T. Councill. Component-based Software Engineering.
Addison-Wesley Publishing Company, Reading, Massachusetts, 2001. [JDB98] Java Database Connectivity (JDBC) API 2.0, Sun Microsystems Inc., (1998). [JDO02] Java Data Objects (JDO), JSR 112, Version 1.0, Sun Microsystems Inc., (2002). [KLM97] G. Kiczales, J. Lamping, A. Mendhekar, C. Maeda, C. Lopes, J. Loingtier, and J.
Irwin. Aspect-oriented programming. In Proceedings of ECOOP’97, pages 220–242. Springer Verlag, 1997. LNCS 1241.
[KM03] A. Korthaus, M. Merz. A Critical Analysis of JDO in the Context of J2EE. In:
Proceedings of the 2003 International Conference on Software Engineering Research and Practice (SERP '03). Las Vegas, Nevada, USA: CSREA Press, 2003, S. 34-40, (SERP'03)
[LHP04] W. Li, W. Hsiung, O. Po, K. Hino, K.S. Candan, D. Agrawal. Challenges and
Practices in Deploying Web Acceleration Solutions for Distributed Enterprise Systems. NEC Laboratories America, Inc. (2004).
[LS00] G. T. Leavens, M. Sitaraman. Foundations of Component based Systems.
Cambridge University Press (2000).
60
[Lev86] N. G. Leveson. Software Safety: Why, What, and How. ACM Computing Surveys, 18(2):125{163, June 1986.
[Lid02] S. Lidin. Inside .NET IL Assembler. Microsoft Press,U.S (February 28, 2002). [LR89] K. J. Lieberherr, A. J. Riel. Contributions to teaching object-oriented design and
programming. In Object-Oriented Programming Systems, Languages and Applications Conference, in Special Issue of SIGPLAN Notices, pages 11-22, October 1989.
[Llo94] J. Lloyd, Practical Advantages of Declarative Programming, GULP-PRODE '94,
Peñiscola (Spain), September 1994 [Lov93] T. Love. Object Lessons – Lessons Learned in Object-Oriented Development
Projects. SIGS Books, New York, 1993. [LSS02] M. Lumpe, J. Schneider, B. Schonhage, T. Genssler. Composition Languages.
Overview of the Second International Workshop on Composition Languages (WCL 2002) [McI68] M. D. McIlroy. Mass-Produced Software Components. In Proceedings of the
NATO Software Engineering Conference, pages 138-155, Brussels, Belgium, Oct. 1968.
[MT97] N. Medvidovic, R. N. Taylor. A Classification and Comparison Framework
for Software Architecture Description Languages. Technical Report. University of Southern California and University of California, Irvine (1997).
[MPet] Microsoft's re-implementation (PetShop) of Sun Microsystems Java PetStore
Reference application. http://www.gotdotnet.com/team/compare/petshop.aspx. [Mon01] R. Monson-Haefel. (2001) Enterprise Java Beans. O'Reilly & Associates. [Mor94] P. J. Morrison (1994) Flow Based Programming – A New Approach To
Application Development. Van Nostrand ReinHold – An International Thomson Publishing Company.
[NR69] P. Naur, B. Randell, Eds, NATO Conference on Software Engineering, Garmisch,
Germany, October, 1968 NATO Science Committee, Brussels, 1969. [Net99] Microsoft Corporation. .NET Framework (Version 1.0), 1999. [Nie93] O. Nierstrasz. Composing Active Objects. In G. Agha, P.Wegner and A.
Yonezawa, editor, Research Directions in Concurrent Object-Oriented Programming. MIT Press, 1993.
[Nie04] O. Nierstrasz. Software Evolution as the Key to Productivity? Lecture Notes in
[PS96] C. Pfister, C. Szyperski. Why Objects Are Not Enough - (CUC96) Component-
Based Software Engineering. SIGS - Cambridge University Press (1998). [POM03] R. Pichler, K. Ostermann, M. Mezini. On aspectualizing component models.
957-974 Software - Practice and Experience (SPE), Volume 33, 2003. John Wiley and Sons, Ltd.
[PW02] C. Pahl., D. Ward. Towards a Component Composition and Interaction
Architecture for the Web. Electronic Notes in Theoretical Computer Science 65 No. 4 (2002). School of Computer Applications, Dublin City University, Dublin 9, Ireland.
[Raj03] G. Suresh Raj (2003). Java Data Objects.
http://my.execpc.com/~gopalan/java/jdo/jdo.html [SF02] B. Schiefer, C. Fecht. Persistence for Large Enterprise Systems in the Java World.
[Sha92] A. J. Sharp. (1992) Data Flow Computing. Theory and Practice. Ablex
Publishing Corporation. [SB98] Y. Smaragdakis, D. Batory. Implementing Layered Designs with Mixin-Layers. In
Proceedings of ECOOP '98. [Smy98] D. E. Smyth. (1998) Faster, Better, and Cheaper at JPL - (CUC96) Component- Based Software Engineering. SIGS - Cambridge University Press. [SEI] The Software Engineering Institute (SEI). Online material on Architecture
description languages (ADLs). ttp://www.sei.cmu.edu/architecture/adl.html. Carnegie Mellon University.
[SQLJ99] SQLJ - Part 1: SQL Routines using the Java. ANSI NCITS 331-1:1999, (1999). [Sun97] Sun Microsystems. Javabeans Specification, Version 1.0. 1997. [Sun01] Sun Microsystems. Java PetStore 1.1.2 Blueprint Application, 2001.
[Szy92] C. A. Szyperski. Import is not inheritance — why we need both: Modules and
classes. In Proceedings ECOOP ’92, volume 615 of LNCS, 19–32, June 1992. Springer-Verlag.
62
[Szy96] C. Szyperski (1996) Independently Extensible Systems - software engineering
potential and challenges. Proceedings, 19th Australasian Computer Science Conference. Australian Computer Science Communications 18(1) 203-212.
[Szy00] C. Szyperski. Component Software and the Way Ahead. Microsoft Research. In G.
T. Leavens, M. Sitaraman. Foundations of Component based Systems. Cambridge University Press (2000).
[Szy02] C. Szyperski with D. Gruntz and S. Murer, (2002). Component Software - Beyond
Object Oriented Programming. Second Edition. Addison-Wesley, ACM Press, New York.
[TD97] S. T. Taft and R. A. Duff. Ada 95 Reference Manual: Language and Standard
Libraries. Lecture Notes in Computer Science. Springer Verlag, 1997. ISBN 3-540-63144-5.
[TC03] N. Tansalarak, K. T. Claypool. XCompose: An XML-Based Component
Composition Framework, Third International Workshop on Composition Languages, Darmstadts, Germany, July 22, 2003.
[TOH99] P. Tarr, H. Ossher, W. Harrison, and S. M. Sutton, Jr. N Degrees of Separation:
Multi- dimensional Separation of Concerns. In Proceedings of ICSE’99, pages 107–119, Los Angeles CA, USA, 1999.
[Veen86] A. H. Veen. (1986) Dataflow Machine architecture. ACM Computing Surveys,
Vol. 18, No. 4, December 1986. [WWW94] J. Waldo, G. Wyant, A. Wollrath, S. Kendall . A Note on Distributed Computing.
Sun Microsystems Laboratories, Mountain View, CA , 1994. [WD02] R. Wuyts, S. Ducasse. Composition Languages for Black-Box Components,
Software Composition Group. University of Bern, Switzerland. First OOPSLA Workshop on Language Mechanisms for Programming Software Components (2002).
[WW88] A. Wirfs-Brock and B. Wilkerson. An overview of modular Smalltalk.
In Proceedings OOPSLA ’88, 123–134, Nov. 1988. [Wir82] N. Wirth (1982) Programming in Modula-2. 4th edn1989. Springer-Verlag,
Berlin. [XDoc] xDoclet is a code generation engine that enables Attribute-Oriented Programming
for Java. http://xdoclet.sourceforge.net/. [XPet] xPetstore is the re-implementation of Sun Microsystems Java PetStore J2EE
Reference application with xDoclet [XDoc]. http://xpetstore.sourceforge.net/. [Zen02] M. Zenger. Extensibility in the Large. Programming Methods
Laboratory Swiss Federal Institute of Technology Lausanne (2002).
63
Appendix A xPetStore xPetstore [XPet] is the re-implementation of Sun Microsystems PetStore application which is the blueprint application for the J2EE/EJB technology. The important characteristic of this implementation is that it uses the xDoclet [XDoc] code generation engine. xDoclet is a code generation engine that enables Attribute-Oriented Programming for Java. It works by adding meta-data (attributes) to Java source code via the use of special JavaDoc tags. xDoclet engine parses the Java source files and generate many artefacts such as XML deployment descriptors and/or necessary Java source code (Home & Business interfaces) from it. These files are generated from templates that use the information provided in the source code and its JavaDoc tags. The most important benefit of xDoclet is that it cuts down the redundant repetitive work. We enter the information in one place and everything else that is required for the EJB component is generated for us. Following is the complete list of all Java packages (and their content) that include all the domain specific objects (components) of the application located in the middle tier. Other aspects of the application (mainly user interface components that are located in the Web tier) are excluded. We also excluded the Deployment descriptors from this list. To avoid clutter and redundant repetition, we excluded the top level package name (xpetstore) from all package names and used the following short-hand notation; cls (class), int (interface) and gen (generated). Totals for the whole list are; 28 Hand written classes 29 Generated classes 22 Generated interfaces ----------------------------------- 79 Classes & interfaces 51 of which are generated
Contents of the xPetStore Packages for the Middle-Tier Components domain.catalog.dao cls: ProductDAO domain.catalog.ejb
cls: CategoryEJB, ItemEJB, ProductEJB gen cls: CategoryCMP, ItemCMP, ProductCMP domain.catalog.interfaces
gen int: CategoryLocal, CategoryLocalHome, ItemLocal, ItemLocalHome, ProductLocal, ProductLocalHome domain.catalog.model gen cls: CategoryValue, ItemValue, ProductValue domain.catalog.util gen cls: CategoryUtil, ItemUtil, ProductUtil domain.customer.ejb cls: CustomerEJB gen cls: CustomerCMP domain.customer.interfaces gen int: CustomerLocal, CustomerLocalHome
64
domain.customer.model gen cls: CustomerValue domain.customer.util gen cls: CustomerUtil domain.order.ejb cls: OrderEJB, OrderItemEJB gen cls: OrderCMP, OrderItemCMP domain.order.interfaces gen int: OrderItemLocal, OrderItemLocalHome, OrderLocal, OrderLocalHome domain.order.model cls: OrderStatus gen cls: OrderItemValue, OrderValue domain.order.util gen cls: OrderItemUtil, OrderUtil domain.signon.ejb cls: AccountEJB gen cls: AccountCMP domain.signon.interfaces gen int: AccountLocal, AccountLocalHome domain.signon.model gen cls: AccountValue domain.signon.util gen cls: AccountUtil services.cart.ejb cls: CartEJB gen cls: CartSession services.cart.interfaces gen int: CartLocal, CartLocalHome services.cart.model cls: CartItem services.cart.util gen cls: CartUtil services.mail.ejb cls: MailerMDB services.mail.model cls: Email services.order.ejb cls: OrderProcessorMDB services.order.exceptions cls: CreditCardException services.petstore.ejb cls: PetstoreEJB gen cls: PetstoreSession services.petstore.exceptions cls: CartEmptyOrderException, DuplicateAccountException, DuplicateEmailException services.petstore.interfaces gen int: PetstoreLocal, PetstoreLocalHome
65
services.petstore.util gen cls: PetstoreUtil util cls: ChainedException, ChainedRuntimeException, CreditCardNames, Debug, JMSUtil, Page, JNDINames util.uidgen.ejb cls: CounterEJB, UIDGeneratorEJB gen cls: CounterCMP, UIDGeneratorSession util.uidgen.interfaces gen int: CounterLocal, CounterLocalHome, UIDGeneratorLocal, UIDGeneratorLocalHome util.uidgen.util gen cls: CounterUtil, UIDGeneratorUtil
Appendix B Generic System Process (Sys-Proc) and HCM Composition Language (HCL) Sys-proc plays a very important role in minimising the amount of programming, while raising the level of abstraction, that is required for the development of non-trivial real world applications in HCM. Together with the connections property of the implementation record, which specifies the data (message) flow, required components and processes and their input/output messages in detail, they effectively form the composition language of HCM; HCM Composition Language (HCL). Sys-proc is the generic system process that interprets the following small set of high level operations which are specified in HML.
• Getting and setting the properties/parameters of input and output messages • Creation, deletion and addition of properties • Conditional programming using simple if-then-else construct • Simple looping on the elements of any set of properties • Stack based arithmetic • Application of small set of functions which returns the current date, time and time stamp
values and extracts the certain parts (head, tail, rest, front) of delimited strings. The following small extract from the implementation record of the Order component of the hPetStore implementation demonstrates the use of sys-proc. fields_{ connections_{ from_pin_"@self/Order_01/add/Order_01_add-pin"_{ to_proc_"sys.Order-add"_{ to_proc_"sys.Order-add2"_size_"2"_id_"add2"_{ to_proc_"sys.Order-add3"_size_"2"_id_"add3"_{ to_pin_"Order_01/Record_01/set/Record_01_set-pin"_size_"1"_{}} to_pin_"Order_01/Record_01/get/Record_01_get-pin"_size_"1"_{ to_"@add3" }} to_pin_"Item_01/Record_01/update/Record_01_update-pin"_size_"1"_{ to_"@add2" }}}}
66
sys-procs_{ Order-add3_{ # Set the Order record property with the property index 0/0 of input msg 1 set_pro_"pro.recOrder"_with_"pro.i1.0/0" # Set the Order items property with the items field of the Order record property set_pro_"pro.items"_with_"pro.recOrder/fields/items" if_value-of_"pro.recOrder/fields/status"_is-equal-to_"open"_{ then_{ # Order is OK, update the order details # Set the date field of the Order record with current date set_value-of_"pro.recOrder/fields/date"_with_"fun.date" # Set the last-update field of the Order record with time stamp value set_value-of_"pro.recOrder/fields/last-update"_with_"fun.timeStamp" # Add the new item into the items bag add_pro_"pro.item"_to-bag_"pro.items"_id_"id"_count_"qty" # Loop for each item in items property; initialise the stack with a double value 0.0; # Pop the end result and assign it to the total field of the Order record for_each_"pro.items"_dbl_"str.0.0"_pop_"pro.recOrder/fields/total"_{
# Set the total field of each item by multiplying the # integer Quantity field and double Price fields
mul_int_"/qty"_dbl_"/price"_pop_"/total" # Add the totals of each item on the stack add_dbl_"/total" } # Set the parameters of the output msg 0 with the parameters of input msg 1 set_params-of_"msg.o0"_with_"msg.i1" } else_{ # Order is not open, probably cancelled, create an error message err_id_"ORDER_EXPIRED"_param1_"pro.recOrder/id/id" }}}}} As we can see from this example, sys-procs and connections properties are defined inside the same HML record. The set of operations supported by the sys-proc is very small when compared to other compiled or interpreted languages (Java, Java Script, C or Pascal). The Order-add3 sys-proc, each operation of which is commented with the explanation of the operation, demonstrates almost all the functionality provided by sys-proc. Sys-proc obviates the need to drop down to the level of the host language, which invariably requires the editing and compilation of a separate source file. Instead, we can specify the required high level operations inside the same HML record and execute them without any need for compilation. Of course there is one obvious disadvantage of sys-proc. Their execution speed can not be as good as the component processes coded in the host language of the system. But this only disadvantage is more than outweighed by the following list of advantages. 1 - The set of operations supported by the sys-proc is very small and high level. Hence, they are very easy to learn and use, especially by non-programmers, without much room for errors.
67
2 - Reducing the possibility of errors with a very small, simple language and avoiding the editing and compilation of any separate source file in the host language has a significant positive effect on productivity. 3 - Since complete systems can be built by domain experts due to the previous advantages, the need for professional programmers is reduced considerably. 4 - Due to being independent of the host languages of the runtime systems, applications built with sys-procs don't need any change when ported on different HCM runtime systems. Despite its size and simplicity, sys-proc is powerful enough to build applications entirely with the composition language. As we can see from the connections property of the above example, addition of an Item into an Order record is a complex operation. The complexity of the operation should be appreciated fully with the following diagram. +-->[Item/update]-->+ +-->[Order/get]-->+ | | | | | | | | | | | | | v | v o>--(add)-->+---------------->(add2)-->+-------------->(add3)-->[Order/set]-->o
In this diagram, while the names of the sys-procs are shortened as add, add2 and add3 and enclosed in round brackets, component/function names are enclosed inside the square brackets. When a user selects to add any required quantity of an item into his/her order, the Order/add message that is created for the operation is sent to our add process. This process updates the parameters of the Item/update message in order to reduce the specified quantity from the stock field of the required Item. The original Order/add message is also sent to add2 sys-proc without any change. If the reduction of the Item is not successful, which is mainly due to not having the required amount in stock, the entire operation (Order/add) is terminated with a suitable error message. Otherwise the details of the Item is sent to add2 process as the result. The add2 process updates the parameters of the Order/get message from its input messages and also sends its other input message containing the Item details to add3 process. Eventually the add3 process updates the received order record with the details of the new Item and outputs the Order/set message, the result of which is returned to user as the result of our Order/add operation. Our discussion of the system processes will be completed with the most complicated operation of the hPetStore implementation; Order/close. As depicted by the diagram, this operation is completed with 4 sys-procs and 5 messages to 4 different components. +-->[Order/get]-->+ +->[Card/update]-->+ | | | | | | | | | | | | | v | v o>-(close)->+------------>(close2)-->+------------->(close3)--->[Order/set]-->> | ^ | | | | | | +-->[User/get]--->+ >>-->(close4)--->[Mail/send]-->o
68
The first system process (close) updates the parameters of the messages to obtain the details of the User and the current Order. The second process (close2) prepares the message to debit the credit card account. If there are enough funds and the Card/update is successful, the close3 process prepares and sends the message to set the Order record. The result of this message is received by close4 process which finalises the operation by sending the Mail/send message. Another interesting point about this operation is that, while it's last message looks like a simple send message to the Mail component, the Mail/send operation itself is a reasonably complex operation that, as depicted by the following diagram, is implemented with 2 sys-procs and 3 messages to the required components. +-->[Mail/new]--->+ | | | | | | | v o>--(send)-->+------------->(send2)--->[Mail/set]-->o | ^ | | | | | | +-->[User/get]--->+
As demonstrated in these examples, the composition language of HCM is powerful enough to build complete solutions without doing any low level programming in the component implementation (host) language of the system. Appendix C The High Level Specification of hPetStore The objective of this appendix is to demonstrate that the hPetStore implementation of the reference application is far from being a trivial application and embodies most of the qualities that are required by real world applications. That is why the following is only a high level specification that lists the important qualities/features of the application. 1 - The users can log-in as a new or existing user and edit their details (name, address, e-mail address, credit card type and number etc.). 2 - The user can browse all the items of the number of products that belong to five different categories. 3 - Only products that have items in stock are displayed to the user. 4 - The user can add one or more quantities of the same or different items into his/her order. If the user adds the same item into his/her order more than once, the system only increases the quantity of the item instead of adding the same item multiple times. 5 - When the user selects to add the certain quantity of an Item in to the order, the system sends a message to the item component in order to reduce the required quantity from stock. If this
69
operation fails, which means that there aren't enough items in the stock (taken out by another user browsing concurrently), the operation terminates with a suitable error message. 6 - Each update of the Order record is time stamped. The orders which are not updated in the last 20 minutes (the amount is specified in a configuration file) are cancelled by a background process and the items of the order are returned back (by increasing the stock) to the Item component. 7 - If the user tries to add an item into a cancelled order or tries to check out with a cancelled order, the user is informed with a suitable error message and requested to reset their order in order to start with a new order. 8 - The system checks that the user has enough amount of credit before closing the order. Otherwise the user is informed with a suitable error message and is prevented from proceeding to check out. 9 - The user can create an order and add items into his/her order before logging-in, but check out is prevented and the user is requested to log-in in order to proceed with the check-out. 10 - The user can do key-word search on all products, which returns the list of all products that contain the provided word (string) in their name or description fields.
