PATTERNS FOR ENTERPRISE APPLICATION
DESIGN AND DEVELOPMENT
by
Ruslan Rubis
A Dissertation Submitted to the Faculty of
The College of Engineering and Computer Science
In Partial Fulfillment of the Requirements for the Degree of
Doctor of Philosophy
Florida Atlantic University
Boca Raton, FL
December 2017
Copyright by Ruslan Rubis 2017
ii
ACKNOWLEDGEMENTS
I would like to thank from the bottom of my heart my advisor, Dr. Ionut Cardei, for his persistent guidance, patience and countless advice. Without his continuous support and encouragement this project would not have been possible. I would also like to express my deepest gratitude to my committee members, Dr. Mihaela Cardei, Dr. Eduardo B.
Fernandez, and Dr. Daniel Raviv. Your continuous feedback, knowledge sharing, and advice has been invaluable and immensely appreciated.
iv ABSTRACT
Author: Ruslan Rubis
Title: Patterns for Enterprise Application Design and Development
Institution: Florida Atlantic University
Dissertation Advisor: Ionut Cardei, Ph.D.
Degree: Doctor of Philosophy
Year: 2017
Designing and developing enterprise applications is a complex and resource intensive process, as it often must address thousands of requirements. At the same time, the software architecture of most enterprise applications at their core have many features and structures in common. Designers from different teams do not normally share design elements because of the competitive and proprietary nature of development, and enterprise applications design and development teams end up re-inventing the wheel when tackling a new product.
My objective is to formulate new design patterns for enterprise application architectures that assist software architects with reusable solutions to improve design quality and productivity. I achieve this by presenting seven patterns, each providing a solution to a specific challenge or a problem that is common to many enterprise applications.
The Business Object Pattern provides a generic approach to design extensible
Business Objects and their frameworks for enterprise applications. The pattern covers a
v number of concepts, including the Dynamic business object, the Static business object, constraints for validity, editability, and attribute visibility, as well as the mechanisms for workflow.
The Business Object Life Cycle Pattern introduces the concept of stages which comprise a business object’s life cycle, and their relation to the business object’s integrity during that life cycle.
The Simple Change History Pattern provides a concept of enforcing record keeping of the owner and date of the last change performed on a given business data object. The
Business Data Object Versioning Pattern offers a solution by introducing a new version of a given business data object which allows for preservation of the original data. The Change
History Record Pattern defines a solution for cases when there is a need to capture detailed information about the changes performed on a given business object, such as who made the changes, when, and what changes were made.
The Permission Based Granular Access Control Pattern offers a basic approach for access control to objects and their attributes.
Finally, the Money Object Pattern offers a language neutral approach to internationalization and globalization of business applications which require multi- currency capability.
It is hoped that applying these patterns will provide many advantages, ranging from quicker delivery times to a more reliable software, and ultimately help achieve a systematic approach to designing and building complex enterprise applications.
vi DEDICATION
This manuscript is dedicated to my family. My wife, Gloria, who unconditionally supported me over the many years of research, and would not let me quit. My daughters,
Sabrina and Oksana, who encouraged me throughout this process, and who continue to compete with me in their own academic achievements. My mother, Sofia Rubis, who has always believed in me. I will forever be grateful for all their sacrifice and support.
PATTERNS FOR ENTERPRISE APPLICATION
DESIGN AND DEVELOPMENT
TABLES ...... xv
FIGURES ...... xvi
1. INTRODUCTION ...... 1
1.1 Overview of Enterprise Applications ...... 1
1.2 Motivation ...... 5
1.3 Contributions ...... 9
1.4 Goals...... 19
2. RELATED TECHNOLOGIES ...... 22
2.1 The Pattern Language...... 22
2.2 The Unified Modeling Language (UML)...... 25
2.2.1 Structure Diagrams ...... 26
2.2.2 Behavior Diagrams ...... 31
2.2.3 Interaction Diagrams ...... 33
2.3 Extensible Markup Language (XML) ...... 37
2.4 XML Schema Definition (XSD) ...... 38
2.5 Extensible Stylesheet Language Transformation (XSLT) ...... 38
2.6 XML Path Language (XPath) ...... 38
3. RELATED WORK ...... 39
3.1 The San Francisco Project ...... 39
viii 3.2 The Object Management Group Business Object Domain Task Force ...... 39
3.3 Analysis Patterns: Reusable Object Models...... 40
3.4 Business Modeling with UML – Business Patterns at Work ...... 41
3.5 Patterns for Data and Metadata Evolution in Adaptive Object-Models...... 41
3.6 Patterns for e-business – A strategy for reuse ...... 42
3.7 SOA and the Enterprise Service Bus ...... 43
3.8 Patterns for Enterprise Integration via Message Passing ...... 45
3.9 Reusing the Design Rationale ...... 46
3.10 Microservices as an Alternative to SOA ...... 47
4. THE BUSINESS OBJECT PATTERN ...... 50
4.1 Introduction ...... 50
4.2 Intent...... 50
4.3 Example ...... 51
4.4 Context ...... 52
4.5 Problem ...... 53
4.6 Forces ...... 53
4.7 Solution ...... 54
4.7.1 The BusinessObject class ...... 55
4.7.2 The DynamicDataObject (DDO) Class ...... 56
4.7.3 The StaticDocument (SD) Class ...... 57
4.7.4 Constraints ...... 58
4.7.5 The Workflow Class ...... 60
4.8 Consequences ...... 61
ix 4.9 Known Uses ...... 61
4.10 Related Patterns and Frameworks ...... 62
4.10.1 The Document-View-Presentation (DVP) Pattern...... 62
4.10.2 The Presentation-Abstraction-Control (PAC) Pattern ...... 63
4.10.3 The Common Business Objects Framework (CBOF) ...... 64
4.10.4 Web Business Objects...... 64
4.11 Conclusions ...... 65
5. THE BUSINESS OBJECT LIFE CYCLE PATTERN ...... 66
5.1 Introduction ...... 66
5.2 Intent...... 66
5.3 Example ...... 66
5.4 Context ...... 67
5.5 Problem ...... 68
5.6 Forces ...... 68
5.7 Solution ...... 68
5.8 Consequences ...... 74
5.9 Known uses ...... 75
5.10 Related Patterns and Frameworks ...... 75
5.10.1 The Document-View-Presentation (DVP) Pattern...... 75
5.10.2 The Model-View-Controller (MVC) Pattern ...... 76
5.10.3 The Presentation-Abstraction-Control (PAC) Pattern ...... 76
5.10.4 Workflow Patterns ...... 77
5.11 Conclusions ...... 77
x 6. THE SIMPLE CHANGE HISTORY PATTERN...... 78
6.1 Introduction ...... 78
6.2 Intent...... 79
6.3 Example ...... 79
6.4 Context ...... 79
6.5 Problem ...... 79
6.6 Forces ...... 80
6.7 Solution ...... 80
6.8 Consequences ...... 81
6.9 Known uses ...... 82
6.10 Conclusions ...... 82
7. THE BUSINESS DATA OBJECT VERSIONING PATTERN ...... 83
7.1 Introduction ...... 83
7.2 Intent...... 83
7.3 Example ...... 83
7.4 Context ...... 84
7.5 Problem ...... 84
7.6 Forces ...... 84
7.7 Solution ...... 85
7.8 Consequences ...... 88
7.9 Known uses ...... 89
7.10 Conclusions ...... 90
8. THE CHANGE HISTORY RECORD PATTERN...... 91
xi 8.1 Introduction ...... 91
8.2 Intent...... 91
8.3 Example ...... 91
8.4 Context ...... 92
8.5 Problem ...... 92
8.6 Forces ...... 92
8.7 Solution ...... 93
8.8 Consequences ...... 95
8.9 Related Patterns ...... 96
8.9.1 Event-Result History Pattern ...... 96
8.10 Known Uses ...... 96
8.11 Conclusions ...... 97
9. THE PERMISSION BASED GRANULAR ACCESS CONTROL PATTERN ...... 98
9.1 Introduction ...... 98
9.2 Intent...... 98
9.3 Example ...... 98
9.4 Context ...... 99
9.5 Problem ...... 100
9.6 Solution ...... 100
9.7 Consequences ...... 103
9.8 Related Patterns and Frameworks ...... 104
9.8.1 Discretionary Access Control (DAC) ...... 104
9.8.2 Mandatory Access Control (MAC) ...... 104
xii 9.8.3 Role Based Access Control (RBAC) ...... 104
9.8.4 Attribute-based Access Control (ABAC) ...... 105
9.8.5 Semantic Access Control (SAC) ...... 105
9.9 Conclusions ...... 105
10. THE MONEY OBJECT PATTERN ...... 107
10.1 Introduction ...... 107
10.2 Intent ...... 107
10.3 Example ...... 108
10.4 Context...... 109
10.5 Problem ...... 109
10.6 Forces...... 109
10.7 Solution ...... 111
10.7.1 Implementation Details ...... 113
10.8 Consequences ...... 120
10.9 Known uses...... 122
10.10 Related Patterns and Frameworks ...... 122
10.10.1 Martin Fowler’s Money Object ...... 122
10.10.2 Money Class, Microsoft .NET ...... 122
10.10.3 JSR 354 (Money & Currency) - Specification ...... 123
10.11 Conclusions ...... 123
11. PATTERNS AND XML ...... 124
12. CONCLUSIONS AND FUTURE WORK ...... 127
13. REFERENCES ...... 132
xiii xiv TABLES
Table 1: Original Order ...... 86
Table 2: Change Order In Progress ...... 86
Table 3: Change Order Completed ...... 87
Table 4: Permission based granular attribute access...... 102
xv FIGURES
Figure 1: Applications within typical ERP system ...... 2
Figure 2: Software Development Life Cycle ...... 6
Figure 3: Logical grouping of the seven patterns ...... 12
Figure 4: Relationships between patterns ...... 12
Figure 5: Example Class Diagram ...... 27
Figure 6: Example Component Diagram ...... 28
Figure 7: Example Composite Structure Diagram ...... 28
Figure 8: Example Deployment Diagram ...... 29
Figure 9: Example Object Diagram ...... 30
Figure 10: Example Package Diagram ...... 31
Figure 11: Example Activity Diagram ...... 32
Figure 12: Example State Machine Diagram ...... 32
Figure 13: Example Use Case Diagram ...... 33
Figure 14: Example Communication Diagram ...... 34
Figure 15: Example Interaction Overview Diagram ...... 35
Figure 16: Example Sequence Diagram ...... 36
Figure 17: Example Timing Diagram ...... 37
Figure 18: Decision flow for using Business Objects Pattern ...... 51
Figure 19: The UML class diagram of a business object ...... 55
xvi Figure 20: Illustration of a Business Object life cycle using the example with the
Vendor business object ...... 69
Figure 21: Example of the three stages of a Business Object’s life cycle for update...... 73
Figure 22: UML class diagram for the BusinessDataObject class, with change history
attributes and associations to a User class ...... 80
Figure 23: UML class diagram for a Business Data Object with new version
attributes ...... 85
Figure 24: UML sequence diagram for the Business Data Object class when a change
is made to the object ...... 87
Figure 25: UML class diagram for a business data object with change history records .. 94
Figure 26: The class diagram for the Permission Based Granular Access Control
pattern ...... 101
Figure 27: The sequence diagram for Permission Based Granular Access Control
pattern ...... 102
Figure 28: The Money Object UML class diagram ...... 114
xvii 1. INTRODUCTION
1.1 Overview of Enterprise Applications
Enterprise applications support day-to-day operations of companies (both large and small) and organizations in healthcare, government, military, and the non-profit domain.
They are large, often mission-critical applications operating with high expectations for uptime and robustness. Enterprise applications contain complex business logic which often require subject matter expertise to build and main these applications. In addition, enterprise applications are expected to be scalable, be able to handle large number of concurrent users, and process large amounts of data. Typical examples of enterprise applications are in the areas of enterprise resource planning (ERP, see Figure 1), customer relationship management, online shopping, billing/order systems, content management, IT service management, and mission planning. Enterprise applications have a complex, component- based distributed design and must scale with a large number of concurrent users.
1
Figure 1: Applications within typical ERP system Just about every business is comprised of multiple organizations and departments, each specializing in their area of function. An accounting department deals with various customers, distributors, and partner accounts, the procurement department handles purchase orders, invoices to procure goods and services for the business, while the warehouse receives and distributes the goods. Each organization or department needs applications specific to their functional area. These applications are implemented on a web- based infrastructure using standard web technologies and rely on “business objects” such as purchase orders, invoices, and accounts. These business objects have a common set of properties at the design level and different implementation solutions [.NET, J2EE, Spring,
2 CORBA, etc.] as well as custom architectures [Ariba, SAP, SmartClient, etc.]. The business objects reveal similarity in the overall approach without a systematic effort to build a reusable specification and infrastructure.
Generally, the new applications or features are requested by an individual department or organization to address a specific need. Depending on the complexity of the proposed effort, enterprises have a number of choices when it comes to design and development of the new applications. These are some of the options available to the enterprises when acquiring new applications:
Use in-house expertise to design and develop.
Fully outsource design and development.
Use combination of in-house expertise and outsourcing.
Purchase commercial off the shelf (COTS) application.
Acquire cloud-based solution.
Each approach has its own strengths and drawbacks. Designing and developing an application in-house allows the owners of the project to maintain full control over the proposed application features. In-house teams are more familiar with the organizational needs, structure and culture, and are therefore more capable of delivering the final product as it was requested. However, depending on the proposed application complexity, an in- house team may not have the necessary expertise to complete the project successfully, in which case organizations may opt to outsource the project entirely. Outsourcing application development has shown both successes and failures in the past. The obvious benefits of outsourcing application development are the control over costs, which are generally negotiated upfront, access to expertise which might not be readily available in-house, and
3 freeing up in-house resources for other projects. At the same time, many organization prefer to have some sort of control over the project to ensure that the final product is built and delivered as originally requested.
An alternative to full outsourcing of the application development is a hybrid approach where the effort is split between in-house and outsourced teams. The main benefits of this approach are that each team can offer expertise where the other may be lacking them, organizations have a better awareness of the project’s progress, and possess more control over the outcome of the final product.
COTS applications have been gaining popularity since the 1990s, and today are widely used just about every medium to large businesses. The main appeal of COTS is their ability to provide a complete solution. Unlike software components or web services, which provide a specific function or feature, COTS applications are large, stand-alone modules which provide end-to-end solution for a particular area or department within the enterprise.
Their main strength is that they can be purchased, configured and up and running in a fraction of a time when compared to developing similar application in-house. COTS applications main weaknesses are that they are often overly complex and are difficult to configure. In addition, COTS applications provide features and processes which are different from what enterprises may have in place or are used to, thereby resulting in the need to customize these applications in order to change some functionalities which are out- of-the-box.
Cloud computing has been gaining tremendous popularity within the enterprises in the last decade. Unlike COTS applications, which are purchased, installed, and run in-house, cloud-based applications are run and maintained by third party providers. Both Oracle and
4 SAP are now offering cloud solutions for their COTS applications, and even in some cases are discontinuing the COTS model altogether, as in the case of Ariba moving all its applications to the cloud, calling it an On Demand solutions, and no longer offering them for sale as a software install. But like COTS, cloud applications are built to address generic business functions and processes, and often require changes or customizations to address individual enterprise’s specific needs.
1.2 Motivation
Most enterprise applications support a specific area of a business, such as purchasing, invoicing, customer relation management, and are considered to be well-established, with commonly accepted attributes, behaviors, and processes. When developing a new application or a component from a problem domain that involves new concepts, it is possible there are no existing software libraries that could be used, the cost of such libraries could be prohibitive, or the libraries are not fully compatible with the problem domain. In this case, and especially when development is done in-house, a new software design (or architecture) must be created from scratch.
A software development process is comprised of multiple iterative stages which are used to plan, design, build, test, and deploy a software product, see Figure 2.
5 Analysis & Design Implementation • UML Diagrams • Coding • Design Patterns • Technical Design
Requirements Testing • Functional Docs • Test Cases • Use Cases • Evaluation
Planning Initial Planning Deployment
Figure 2: Software Development Life Cycle The end of the Planning stage results in the beginning of the Requirements stage, during which requirements are gathered and documented in the form of functional specifications, use cases, and other artifacts. Once Requirements are completed, the Analysis & Design phase begins. This is arguably the most important stage in the software development process as it defines how the final product will be build. During this stage the design documentation is produced, which includes such artifacts as UML diagrams, data structures, and others. Also during this phase the design patterns are researched, reviewed, and selected when found applicable for the problem being solved.
When developing in-house business applications from scratch each and every time one is needed is a resource-intensive, highly repetitive, and unnecessary undertaking. Each time a custom application requires a new functionality, the developers either have to design it themselves, or use some language and/or platform and/or software dependent solution/library which might or might not address the needs of end users. To successfully 6 use a software library, the semantics of the API must match the needs of the remainder of the application and its execution runtime must be compatible with the overall system architecture. At a higher level of abstraction, however there is no systematic mechanisms equivalent to a software or component library that can be easily reused during the design phase. In general companies are reluctant to publish design documents for their proprietary software for competitive reasons. They won’t sell just their designs either without also including the implementation code as a library, which raises the cost and may not be needed, as seen above.
However, across the software industry and the different business domains, application architectures and component designs share many common structural and behavioral elements that are not publicly available to practitioners. This is in contrast with other engineering disciplines, such as mechanical engineering, where common design elements and system architectures in various fields (e.g. automotive) are published in textbooks.
The main motivation of this dissertation is to provide reusable architectural blueprints for common concepts that occur across enterprise application domains. This dissertation presents a set of patterns, each providing a solution to a specific challenge or a problem that is common to many enterprise applications.
During my twenty two year career in enterprise application development and customization my colleagues and I often find ourselves asking the same question over and over again: why didn’t we think of that before? Or: why wasn’t this brought up during the requirements or design review? I have lost count of how many times I was asked by the top management about who made change to this data or that, or when was this change made. After a while, it was becoming increasingly clear to me that many of these questions
7 had one thing in common – they had similar set of answers. The answers ranged from “we didn’t think about it before” to “we didn’t think we needed it” to “we didn’t think we could do it that way”.
There are many reasons for the continuously repeating occurrence of these common issues and challenges. Based on my own experience, having worked as a consultant for government and corporations, I have observed that people who work for corporations tend to move more frequently than those employed by the government. This movement, either from one company to another, or from one department to another, ultimately results in the loss of experience and knowledge which has been acquired over time, and is not easily replaceable. At the same time, the projects which have already been funding and scheduled must be completed. It’s a never ending cycle.
I believe that one of the ways to address these types of common issues and challenges facing enterprise application developers is through the timely use of well-established and proven patterns. In my experience, if the Simple Change History Pattern (Chapter 6) is applied during design or development phase, the top management would never have need to ask who changed the data or when that data was changed.
Patterns provide a simple and clear solution to an otherwise complex problem. For example an audit trail, which is often required to be part of just about any enterprise application, can be implemented with varying degrees of complexity and features. Another example is a life cycle a business object often undergoes in order to maintain data and business integrity. Documented patterns which cover these topics can be invaluable during design and development phase.
8 Enterprise application developers are realizing that using patterns when developing these applications provides many advantages, ranging from quicker delivery times to a more reliable software which is based on proven business practices. [6]
1.3 Contributions
Enterprise applications are unique in that they are not designed for general public consumption, but are rather built to address the needs of a specific business area or function, and for use by a specific set of users. As a result, most enterprise applications have a number of requirements which are common across functional boundaries and business domains:
Business objects address specific functionality or feature required by enterprise
application. At the same time they share many attributes and features. Most
business objects are dynamic in nature because they are data driven. They also
share common constraints which are required by most enterprise applications.
These constraints are validity, editability and visibility. Finally, many business
objects require workflow support as they move through different life cycle
stages.
Life cycle management of data. In addition to audit trail, certain changes to
corporate data require to go through some sort of approval process and/or
workflow, which is not always instantaneous. In the meantime, the data which
is undergoing changes must still be available for use in its original form
Secure access to the application itself. An application which provides specific
functionality should only be accessed by the users and processes which are
approved to do so based on business rules. Otherwise, users should be
9 prevented from accessing explicitly protected parts of data and features, even
when they allowed to access other parts of the same data and features. For
example, a clerk responsible for processing accounts receivables (A/R) in the
A/R application probably does not need the access to accounts payable (A/P)
application.
Selective access to the modules contained within the application. Most
enterprise applications contain one or more modules. For example, a
purchasing application may contain a purchase order module and a vendor
management module. Here to, someone who creates and processes purchase
orders may not necessary need access to create or update vendors.
Selective access to data processed by the modules. Often corporate data may
be deemed sensitive or contain personally identifiable information (PII) access
to which requires protection even within the modules themselves. For example,
an HR clerk may have the need to retrieve an employee’s home telephone, but
only HR manager should have access to an employee’s social security number.
Audit trail of data updates and user activity. Often it is required by laws and
corporate policies to maintain an audit trail of changes performed on corporate
data. The requirements may range from having the need to keep track of who
or what performed a change and when, to necessitating a creation of a new data
record and preserving the old one.
With the explosion of electronic commerce, many enterprise applications
require multi-currency support as governments and corporations increasingly
10 perform transactions in many different currencies. Enterprise applications must
have the capability to process monetary data in a simple and efficient manner.
Advances in XML technologies provide the ability to apply some of the
concepts introduced in this dissertation using language and platform
independent methods. Chapter 11 introduces a concept of Self Validating
Business Object by describing the method of applying validity constraints (see
Chapter 4) via XML Schema.
Designers and developers of enterprise applications must address these common requirements from the very beginning each and every time they embark on building a new business enterprise application. This dissertation introduces seven patterns which together help address the aforementioned basic requirements which almost every enterprise applications must have.
The seven patterns detailed in this dissertation are the result of extensive research into the design of enterprise applications, and work experience in designing and implementing enterprise applications. The patterns can be logically grouped into four categories: security, workflow, audit trail, and common infrastructure, as can be seen in Figure 3.
11
Figure 3: Logical grouping of the seven patterns Each pattern addresses the specific area a design and development team will encounter when building enterprise applications.
The patterns are related as shown in the pattern diagram in Figure 4.
Figure 4: Relationships between patterns 12 Combined, the patterns provide a basic solution for common issues when designing, developing and deploying data-driven enterprise applications:
1. The Business Object Pattern defines an approach for specification and design
of business objects [40].
2. Business Object Life Cycle Pattern introduces the concept of various stages
which comprise a business object’s life cycle, and their relation to the integrity
during that life cycle [93].
3. The Simple Change History Pattern provides a concept that enforces recording
of the owner and date of the last change performed on a given business data
object [94].
4. The Business Data Object Versioning Pattern offers a solution by introducing a
new version of a given business data object which allows for preservation of
the original data [94].
5. The Change History Record Pattern defines a solution for cases when there is a
need to capture detailed information about the changes performed on a given
business object, such as who made the changes, when, and what changes were
made [94].
6. Permission Based Granular Access Control Pattern offers a basic approach for
access control to objects and their attributes [92].
7. The Money Object Pattern offers a language neutral approach to
internationalization and globalization of business applications which require
multi-currency capability [95].
13 The most basic component of any enterprise application is an entity which we call a
Dynamic Business Object. The objective of this pattern is to provide a generic approach to design extensible Business Objects and their frameworks for business applications. A
Dynamic Business Object refers to an abstract generalization of the various application specific objects that provides a uniform and reusable specification. The Dynamic Business
Object Pattern describes a generic and systematic approach to organize the business objects and to describe them. It structures business objects in static documents, workflows, and dynamic data. Business objects have the typical properties of object-oriented systems, such as composition, inheritance, polymorphism, plus they promote reuse at several levels.
The Dynamic Business Object Pattern also describes an architecture to implement and support business objects. For example, a dynamic data object implies that a storage solution is required; it also implies that a custom user interface will be necessary to present the dynamic data object. A static document, on the other hand, is assumed to have a widely accepted form of viewing software (i.e. MS Word, PDF, Notepad, etc.). Finally, a workflow is a process which supports the life cycle of a dynamic business object.
Another benefit of a modularized approach is that each existing module is not static, and can be enhanced over time. For example, the Common Module has three main parts:
Dynamic Data Object, Static Document, and Workflow. If another entity needs to be added to the Common Module in the future, it can be done so safely, without affecting the existing functionality.
Enterprise applications are designed to address specific business needs and are generally run within the internal corporate networks. Access to enterprise applications is controlled by various corporate policies, based on numerous widely accepted patterns and
14 frameworks. There has been a great amount of work performed in the area of Access
Control models, ranging from simple MAC (Mandatory AC) and DAC (Discretionary AC)
[3] models to more elaborate RBAC (Role-based AC) [1], and advanced SAC (Semantic
AC) [2] and ABAC (Attribute-based AC) [4]. These models have been widely used in enterprise applications. One of the shortcomings of the access control models is that they are applied to protected objects as a whole, and do not provide a granular control over individual parts of these objects. Furthermore, most models do not address the type of access control being granted to the subject (or caller). For example, a control access model might provide read, write, and delete access on a protected object, but does not provide a way to protect individual parts of the said object. Often in enterprise applications there is a need to provide access to certain parts of the protected object, and to prevent access to other parts of the same object. In this paper we propose a pattern for permission based granular access control to protected objects within a given business application.
Many Access Control models address global access to protected objects. For example, once an access is granted to a protected object, the subject (user via an application or process via integration) has a full access to the object. A classic example is the bank customer being granted access to his or her bank account. In most models, once the customer has been identified, that customer has full access to his/her account, and is allowed to perform deposits, withdrawals, transfers, etc. The problem with the classic bank customer example is that the customer’s activities are limited in scope and are oversimplified in the context of the example. In reality, enterprise applications are much more complex and require a more dynamic approach to defining the access control for the
15 given user/process, and which parts of the protected object are under the said control and which ones are outside of it.
We address these challenges with a pattern for Permission Based Granular Access
Control to protected objects within a given business application. An enterprise application is comprised of one or more modules, which in turn are a collection of related business objects. For example, a Procurement Module is part of an Enterprise Resource Planning
(ERP) application, and contains a set of business objects which support its features and processes. Following are examples of some of the business objects in a typical ERP procurement module:
Requisition
Purchase Order
Invoice
Vendor
Businesses constantly consume, generate and share data. Without data, a typical business process would come to a halt. But for the data to be useful to businesses, it must be accessible, manageable, and current. The data supporting daily business operations does not just materialize out of thin air. It is constantly created, updated, and shared. There exists a number of patterns dealing with data object presentation, manipulation and storage, among these are the Model-View-Controller (MVC), the Document-View-Presentation
(DVP), and the Presentation-Abstraction-Control (PAC) patterns, just to name a few.
However, the life cycle of a business object is more complex than just its presentation and persistence. In an enterprise environment every business object throughout its life cycle must adhere to certain rules, regulations, approvals, validations, and constraints. The
16 Business Object Life Cycle pattern attempts to address and abstract the various stages which comprise a business object’s life cycle.
Businesses constantly consume, generate and share data. For this data to be useful, it must be accessible, manageable, current, and traceable. Because enterprise applications are designed for multi user environments and must follow legislation and various security policies, an audit trail for tracking data creation, update, and deletion must be part of the solution. At the enterprise level, changes to certain types of business data objects in multi- user applications may require approvals, validations and verifications, which could take time to complete. While business data objects undergo such a process, applications must still offer users a certain level of access to them. We introduce three patterns which can be used for the design of audit trail mechanisms in multi-user enterprise applications required to adhere to legal and corporate record creation and maintenance. The three patterns offer different levels of granularity for tracking changes using object versions and change history that are suitable for increasing level of complexity.
The goal of these patterns is to address the issues of audit trail, such as who updated a business data object and when. Often, businesses require just a minimalistic approach to tracking changes for most of their data. Our first pattern, the Simple Change History
Pattern, addresses this common scenario by proposing a record keeping mechanism of who made changes to a business data object, and when the changes were made. There are times however, when knowing simply who made the change and when is not enough to maintain a proper audit trail from business and/or legal perspective. Scrupulous accounting practices, and in particular manipulation of accounting data, as in Enron in the late 1990s for example, led not only to the collapse of the company, but also to changes in the
17 regulatory requirements, resulting in the introduction and passage in the U.S. Congress of the Sarbanes–Oxley Act of 2002 (Sarbanes-Oxley, 2002). The next two patterns offer an extended approach to tracking changes to business data objects. The Business Data Object
Versioning Pattern introduces versioning for preserving historical data of a business data object that is capable of preserving a chain of object versions. Lastly, the Change History
Record Pattern relies on change history record objects maintained outside of the business data object itself, providing better flexibility in the design and facilitating adoption in legacy systems.
The internationalization and globalization of enterprise applications increases the need for implementation of Money as one entity rather than a collection of disjoined data pieces.
Limited implementations of Money API have been recently introduced (Microsoft in 2011 as part of the Microsoft.Xrm.Sdk Namespace, and Oracle as part of the java.util package in its upcoming Java SE 9 release). One of the earliest references of Money as object or
API can be found in Martin Fowler’s book “Patterns of Enterprise Application
Architecture”, where he introduced the concept of Money as “class data type in any mainstream programming language” [6].
This dissertation builds on Martin Fowler’s original Money class proposal, while adding the missing pieces which are required to support applications in a multi-currency environments such as base and actual currency, date of transaction, arithmetic operations, and other helpful attributes and operations. The pattern offers a simple and flexible solution for handling money type data in enterprise applications which require multi-currency support. The pattern also provides a solution for enterprise applications with single configuration, and offers arithmetic operations on money type data.
18 1.4 Goals
Enterprise application design and development is different from conventional applications development in that it is geared towards a particular set of users with predefined skill sets, cultures, and expectations. In general, enterprise applications are geared towards the power users or subject matter experts (SMEs), who expect these applications to perform specific tasks, with predictable results, and in a timely manner. In addition to enforcing strict business rules and regulations via workflows, enterprise applications are expected to be multi-user based, scalable, secure, both at the global, as well as granular access levels, and have a built-in audit trail with varying levels of granularity which is often driven by business rules, government regulations, and economic conditions.
As such, the enterprise applications require a different approach to their design and development process. Unlike applications designed for general public consumption, enterprise applications require a great deal of subject matter expertise in the functional area which these applications address, as well as in the security and architecture on which the enterprise applications are built.
In addition, enterprise applications tend to be highly compartmentalized, with each serving a specific group of users within the enterprise. Even within the applications themselves access to different parts is restricted based on various business and legal rules.
Changes to the business data must often be tracked and approved, and an audit trail must be maintained. Consequently, designing and developing applications for enterprises presents new and different challenges, when compared to conventional software development.
19 The development teams must take into account the intricacies and complexities of enterprise applications. When designing and building enterprise applications, the teams must address, among other things, the security, both at the application access level, as well as within the application itself, the workflow, life cycle of the business objects within the application, the audit trail requirements, and the internationalization, if one is needed.
There are a number of options available to address these challenges.
One option is to use component-based development (CBD) process, which has gained significant popularity due to the exploding growth in the use of web services and cloud computing.
The strengths of the CBD and web services lies in their ability to address specific area or function within an enterprise application without negatively impacting the rest of the application. For example, a web service can be called to obtain a conversion rate for a foreign currency on a specific date, or a software component executed which generates a
PDF-based report. But software components and web services are generally built to address a very specific function, and are therefore limited to the number of features they provide.
Another option is to apply well established patterns when building enterprise applications. There are numerous advantages to applying patterns during design and development phase. Patterns provide tried and tested solutions to specific problems. They are language independent, and can therefore be applied in just about any system or architecture. Patterns are often object-oriented in nature and offer decomposition, encapsulation, inheritance and polymorphism.
The patterns presented in this dissertation address specific problems that enterprise applications designers and developers may face. Each pattern provides a solution to a
20 problem which is common to most enterprise applications. My main goal is to contribute valuable patterns to the community of enterprise application designers that facilitate a systematic approach to designing and building complex enterprise applications. I also hope that this work will encourage industry practitioners and scholars to publish more patterns in the enterprise application arena.
21 2. RELATED TECHNOLOGIES
2.1 The Pattern Language
A pattern is a prescribed reusable solution to a commonly occurring problem with a given context. Christopher Alexander has pioneered pattern development and the pattern language with his revolutionary book “A Pattern Language” [49] that looked at architecture and urban design. Alexander was the first to show that patterns can be applied to solve just about every problem, and the power of proven patterns lies in their simplicity and wisdom, which have been tested over time.
The groundbreaking work on software design patterns in Erich Gamma et al. in [62] led to an explosion of research in finding patterns not only in design and architecture [54,
29, 38] but also in other areas of computer science, such as cloud computing [66], distributed systems [72], security [76, 59], user interfaces [65] or the software development processes [50]. As defined by Alexander, the formal description of a pattern includes these three parts: a context describing the conditions for which the pattern applies, a system of forces that the pattern aims to resolve, and a solution. The solution is not a complete design that can be directly converted to an architecture or to an implementation in code, but rather it is general template for how to solve the problem that is applicable in different situations that have in common the elements described in the context part. Patterns are not invented from scratch, but rather capture best practices applied commonly in a domain. Therefore, a pattern provides a well-proven solution that has been refined and tested repeatedly and that generally improves the overall system quality and reduces the development effort and
22 cost. Practitioners identify applicable patterns by looking for patterns whose context map best to their particular application context (requirements, environment). To apply a pattern, the practitioner takes the prescribed solution and adapts it to their application context, including the surrounding architecture.
Patterns provide effective means for improving the quality of enterprise applications design and development by capturing the best practices and making them available in a simple and easy to understand format. The pattern language is “is a structured collection of patterns that build on each other to transform needs and constraints into an architecture” [54]. Although the format of patterns is not strictly enforced, most agree that a pattern should include a number of essential elements [85]. The patterns presented in this dissertation follow this widely accepted format with minor exceptions to address enterprise application specific solutions. Each pattern presented in this dissertation therefore is comprised of the following elements:
Name
The pattern name should be short and descriptive, and be specific to the problem which the pattern attempts to address.
Intent
What does the pattern attempt to solve? What is the rationale behind the pattern in the first place?
Example
Present an example from a real system, clarifying the issue(s) at hand.
23 Context
The current state of the application or system for which a solution is desirable, and for which the pattern was written.
Problem
What problem is this pattern attempting to solve?
Forces
What are the reasons for this pattern? What drove or “forced” the author to write the pattern in the first place?
Solution
A detailed explanation of the pattern’s approach to solve the issue or issues described in the Problem section.
Consequences
Has the pattern achieved its objective? Are there any trade-offs to applying this pattern? Does the pattern address all of the forces? Has the Intent of the pattern been satisfied?
Known Uses
What systems or applications has the solution been implemented in? Describe how the solution been implemented.
Related Patterns
Are there patterns that attempt to solve similar problems? Do they share similar forces and context?
Conclusions
What conclusions can be drawn from the pattern?
24 2.2 The Unified Modeling Language (UML)
The Unified Modeling Language (UML) was initially released by the Object
Management Group (OMG) in 1997 [86]. Since then it has arguably become one of the most popular software modeling languages. UML is a standardized general-purpose modeling language which includes a set of graphic notation techniques to create visual models of object-oriented software systems. Practitioners use UML diagrams for two main purposes. First, to record or communicate a design. Second, many UML modeling tools
(e.g. IBM Rhapsody and Rational Rose) can take these diagrams as input and generate code representing the design in a selected programming language for a specific platform. The programmer then only has to fill in the missing details. UML diagrams have a rich graphical syntax that is expandable using the stereotype mechanism, and a textual representation of constraints. The XML Metadata Interchange (XMI) is an Object Management Group
(OMG) standard for an XML representation of UML models that is commonly used for interfacing UML tools with external systems for model transformation and software integration.
A limitation of UML diagrams is the lack of rigorous formal semantics that complicates automated model verification and validation.
There are thirteen diagrams which comprise the UML to support object oriented design and development. These can be grouped into the three main classifications described in the sections below.
25 2.2.1 Structure Diagrams
Structure diagrams define elements of specification which are time independent.
The diagrams included in this group are class, composite structure, component, deployment, object, and package diagrams.
2.2.1.1 Class Diagram
The Class Diagram depicts a collection of classes, their attributes, and the relationship between the classes. Classes are shown in rectangles, with the class name at the top, attributes (i.e. data fields or instance variables) in the center, and methods (operations) in the bottom box. For each attribute, the designer includes the attribute name and may specify visibility – public (+), private (-), or protected (#) – and its type. The specification for an operation includes the formal parameter list and an optional return type. Relationship specifications may include multiplicity and role names. For the purpose of clarity a class diagram can omit some of the details in the attribute and operations boxes.
An association relationship (solid line) between two classes indicates that instances of them may be linked logically, as in the example from Figure 5, where one client object is associated with one account object. The aggregation relationship (solid line with hollow diamond head) between two classes represents a whole/part relationship. In the example below a Client object has one or more (1..*) accounts. A generalization (or inheritance) relationship indicates a binary relation between two classes where one class is a generalization (superclass) of the other, which is the more specific one. Class Account is a superclass of CheckingAccount in the example.
26
Figure 5: Example Class Diagram
2.2.1.2 Component Diagram
The Component Diagram (example in Figure 6) describes components of a given system, the interfaces they provide and the interfaces they require and the relationships between them. Components can be software, hardware, or arbitrary subsystems. The major elements used to draw a Component diagram are artifact, class, component, component realization, connector, dependency, interface, provided interface, required interface, port, and usage.
27
Figure 6: Example Component Diagram
2.2.1.3 Composite Structure Diagram
The Composite Structure Diagram (example in Figure 7) was introduced in UML 2. It depicts an internal structure of a class and its connection points to the system via required and provided interfaces. Components can interact with the environment via ports. A composite structure diagram illustrates runtime objects interconnected using interfaces or other communication mechanisms.
Figure 7: Example Composite Structure Diagram 28 2.2.1.4 Deployment Diagram
The Deployment Diagram (example in Figure 8) is used to show the static view of the system architecture as software artifacts – components, the middleware used, libraries, databases, services – and how they are mapped to deployment targets. These are usually computing nodes or a software runtime environment, such as a virtual machine or interpreter. A communications network must connect the deployment targets using real hardware links or some other means of communication, such as a VPN or software interface.
Figure 8: Example Deployment Diagram
2.2.1.5 Object Diagram
An object diagram (example in Figure 9) is used to show objects and their relationships within a system at a specific point of time. It is different from a Class Diagram in that an
Object Diagram depicts an instance of an object rather than its class. Object instances are shown in rectangles, with the instance name and the class name at the top, and instance variables in the center. Each instance variable includes the variable name, its instance specific value, and may specify visibility – public (+), private (-), or protected (#) – and its type. Object instances are connected with a solid line.
29
Figure 9: Example Object Diagram
2.2.1.6 Package Diagram
Software modules (such as classes, interfaces, functions) that are related are usually organized in named collections, called packages in UML and some programming languages, including Java. The Package Diagram (example in Figure 10) is used to show a logical grouping of system’s elements and the relationship between these groupings. Some relationships modeled are: dependency, usage, importation, merging.
30
Figure 10: Example Package Diagram
2.2.2 Behavior Diagrams
Behavior diagrams define behavior aspects of a system. They include the Activity,
State Machine, and Use Case diagrams.
2.2.2.1 Activity Diagram
The Activity Diagram (example in Figure 11) is used to show a business process or a workflow. It is similar in concept to a flowchart, but unlike flowchart, the Activity Diagram supports parallel behavior. The diagram is comprised of five main components: Action,
Decision, Control Flow, Start Node and End Node. The Action component is a round- edged rectangle containing the name of the action being executed. The Decision node is a conditional branch represented with a diamond, with one input and two or more outputs.
The flow of control is presented by solid lines with the error showing the flow of control.
Each Activity diagram must have a Start Node, which is a solid black circle, and indicates 31 the beginning of the activity, and an End Node, which is represented by an outlined black circle and signifies the end of the activity.
Figure 11: Example Activity Diagram
2.2.2.2 State Machine Diagram
The State Machine Diagram (Figure 12) is used to define the states and state transitions of an object or a system. A state transition may be labeled with a guard defined by the event or the condition that triggers it and with the action taken by the system before it enters the new state. A state diagram normally describes the behavior of a particular class.
Figure 12: Example State Machine Diagram
32 2.2.2.3 Use Case Diagram
The User Case Diagram (Figure 13) is used to describe the scenarios or use cases of a system. A use case is defined to have a sequence of actions performed by an actor and the response (i.e. other actions) performed by the system (application) in discussion. Use cases are written during requirements analysis are read like stories that describe usage scenarios.
Figure 13: Example Use Case Diagram
2.2.3 Interaction Diagrams
The Interaction diagrams are considered to be a subset of the behavior diagrams. These diagrams are used to depict the flow of control and object interactions. There are four
Interaction diagrams: Communication, Interaction Overview, Sequence, and Timing. They can be used to describe the algorithms involved in the system.
33 2.2.3.1 Communication Diagram
The Communication Diagram (example shown in Figure 14) is used to depict instances of classes that send and receive messages. Each message is labeled with a number indicating the order in which it occurs and the name of that message, that typically represents a method call. The Communication Diagram is comprised of the Frame, the
Lifeline, and the Message elements. The Frame element is shown as a rectangle with a compartment in the upper left corner which is used for the interaction name. The Lifeline element is represented as a rectangle with the name of the entity which it represents inside it. It is used to represent a specific element in the interaction. The Message element in the
Communication Diagram is represented by a solid line which connects the lifeline elements. The Message element’s Sequence Expression is shown above the line and includes an error.
Figure 14: Example Communication Diagram
2.2.3.2 Interaction Overview Diagram
The Interaction Overview Diagram (example in Figure 15) is a variant of an Activity
Diagram with emphasis on the control flow within a system or process. These diagrams show the interaction between other diagrams, which may be Activity, Sequence and others.
Like the Communication Diagram, the Interaction Overview Diagram has a Frame element which is used to show interactions. Also like the Communication Diagram Frame element, the Interaction Overview Diagram Frame element is shown as a rectangle with a compartment in the upper left corner which is used for the interaction name. The Frame
34 element may contain other frame elements, as well as the elements of the Activity and
Interaction diagrams.
Figure 15: Example Interaction Overview Diagram
2.2.3.3 Sequence Diagram
The Sequence Diagram (example in Figure 16) is used to depict the flow of logic over time within a system. It shows the sequence of messages between the objects as they are send over time, and provides an indication of the lifespan of those objects. Objects are represented by rectangular boxes and are labeled by a variable name and/or the class name.
An activation bar represents the execution of a method by an object upon receiving a message, which is described by a label on top of a directed arrow. During a method the object may send messages to other objects and to itself.
The Sequence Diagram utilizes a number of elements to help visualize these interactions. The Lifeline element denotes the lifeline of a distinct participant within the diagram. This element is represented as a rectangle with a vertical line connected to its 35 bottom. Usually the rectangle will contain a class name associated with the lifeline. The
Gate element is used to show a message end. The notation for the gate is the message connection points. The Interaction Fragment element is a parent or a superclass of
Occurrence, Execution, State Invariant, Combined Fragment, and Interaction Use elements. The Occurrence element denotes the beginning and end of a message or execution. The Execution element represents an action or execution within a given lifeline.
The State Invariant element is used to specify various constraints which must be satisfied prior to the execution of a given occurrence. Finally the Interaction Use element allows to call another interaction. Employing interactions helps simply large and complex sequence diagrams.
Figure 16: Example Sequence Diagram
2.2.3.4 Timing Diagram
The Timing Diagram (example in Figure 17) was introduced in UML 2, and is used to model the change in state of an object over time. The Timing Diagram employs a number of different elements to show the timing of changes. The Lifeline element is similar to the
Lifeline element in the Sequence Diagram in that it denotes the lifeline of a distinct participant within the diagram. The State or Condition Timeline element is used to
36 represent the changes in the object’s state. The Duration Constraint element can be used to show the time interval in order to determine if a given constraint is met. The Time
Constraint element uses time expression to show if a given constraint is met. The
Destruction Occurrence element signifies the end or destruction of a lifeline element. No other elements may appear after this element.
Figure 17: Example Timing Diagram
2.3 Extensible Markup Language (XML)
The Extensible Markup Language (XML) is an open standards markup language whose specification (XML Specification 1.0) has been created and maintained by the World Wide
Web Consortium (W3C). XML has been widely adopted across most industries as a de facto mechanism for data exchange and storage. Because XML is software and hardware independent, it is ideal for web services and cloud computing. Many web-based technologies, such as RSS, SOAP, XHTML, semantic-web standards (OWL, RFD, SWRL) and others are based on XML in the sense that their vocabulary and semantic constraints are defined with an XML specification.
37 2.4 XML Schema Definition (XSD)
The XML Schema Definition (XSD) is an XML schema language originally published by the W3C in 2001 as XSD 1.0 specification. XSD is used to define data types and data structures within the XML document, and to verify XML document’s validity. XSD’s main advantages over its predecessor, the Document Type Definition (DTD) language, is the addition of namespace awareness and datatypes. As the result, it is possible in XSD to define elements and attributes with specific datatypes, such as dates and integers, and not just text, as is the case with DTD. Most syntax specifications for XML-based data formats used by service-oriented architectures, such as WSDL, BPEL, RDF, are written using XSD documents.
2.5 Extensible Stylesheet Language Transformation (XSLT)
The Extensible Stylesheet Language Transformation (XSLT) is a language used to transform XML documents. It is widely used in web-based applications and is supported by all modern web browsers. XSLT uses XPath to identify the parts of XML document tree it needs to transform, and them performs the transformations.
2.6 XML Path Language (XPath)
The XML Path Language (XPath) is a query language for XML documents, and was defined by the World Wide Web Consortium (W3C). In addition to its query capabilities,
XPath can also be used to compute values from an XML document. It can perform addition, subtraction, multiplication, division, and other operations. XPath popularity has grown tremendously since its introduction in 1999, and it is widely used in web-based applications.
38 3. RELATED WORK
3.1 The San Francisco Project
The San Francisco Project [27] paper presents a comprehensive set of frameworks for designing and building business applications based on proven business practices. The project is comprised of two main layers: the Core Business Processes layer and the
Common Business Objects layer. The latter contains a set of three frameworks for supporting “business objects commonly used in multiple application domains, business object interfaces that provide interoperability between applications, and objects that implement frequently useful design patterns for business applications”. The Core Business
Processes layer is an “architecture and highly extensible objected-oriented implementation for the basic structure and behavior of any solution in the selected domain.” The Core
Business Processes layer covers three enterprise application areas: Business Financials
(accounts payable, accounts receivable, general ledger), Order Management (sales and purchase orders), Warehouse Management (receiving and shipping). The concept of
Business Object introduced in Chapter 4 is similar to the Common Business Object detailed in the San Francisco Project.
3.2 The Object Management Group Business Object Domain Task Force
The Object Management Group Business Object Domain Task Force (OMG Business
Object DTF) has put forth its proposal for a Business Object framework in its Common
Business Object paper [52], in which it details what it calls the Common Business Object
Taxonomy. In this paper OMG describes the Business Object as a parent to Entity Business
39 Object, Process Business Object, and Event Business Object. According to the paper, the
Entity Business Object “describes a person, place, thing or concept.” These could be customers, suppliers, employees, addresses, products, agreements, etc. Our pattern extends on this idea by introducing the concept of Static and Dynamic Business Objects in Chapter
4. The Process Business Object “describes a business process or workflow, is comprised of a specified collection of entity business objects and a pattern of interactions and business events.” OMG’s Event Business Object “describes a business event, which may be an occurrence or may be related to the passage of time or crossing of a boundary in time.”
3.3 Analysis Patterns: Reusable Object Models
“Objects do not just represent objects that exist in the real world; they often represent the memories of objects that once existed but have since disappeared. Using objects to represent memories is perfectly acceptable – memory of existence is often as real to people as the existence itself – but is important to be able to tell the difference.” [5] In his book
Analysis Patterns: Reusable Object Models Fowler proposes a Historic Mapping pattern to address the issue of changes to a given business object which can take place over time. He gives an example of an employee object whose salary may change over time, and the need to keep history of these changes. To address this issue Fowler proposed adding a list of salaries to the Employee object. This approach not only saves every record of an employee’s salary change, but also records the date of each change. This pattern can be applied to other similar scenarios where historical activity needs to be preserved. The
Historic Mapping pattern inspired me to do more research in this area and ultimately define my own Change History Record pattern (Chapter 8).
40 3.4 Business Modeling with UML – Business Patterns at Work
In Business Modeling with UML – Business Patterns at Work [58], the authors cover a wide array of business-related patterns. The patterns presented in their book are grouped into three main areas: Resource and Rule patterns, Goal patterns, and Process patterns. The
Resource and Rule patterns address what authors call business “products and documents”, which includes such patterns as Actor-Role, Business Event-Result History, Document,
Type-Object-Value, and others. Goal patterns address goal modeling, which authors believe is very critical, as they affect the design of the entire system, and how it is used.
The three Goal patterns presented in the book are Goal Allocation, Goal Decomposition, and Goal-Problem. Process patterns deal with business processes and workflow. Basic
Process Structure pattern, Action Workflow pattern, and Resource Use pattern are some of the ten Process patterns detailed in their book.
The Change History Record (Chapter 8) and Business Data Object Versioning (Chapter
7) patterns introduced in this dissertation extend on the ideas of the Business Event-Result
History pattern, and are more applicable at tracking changes at an individual business object level, whereas the Business Event-Result History pattern is better suited when designing business processes.
3.5 Patterns for Data and Metadata Evolution in Adaptive Object-Models
In their paper, Patterns for Data and Metadata Evolution in Adaptive Object-Models
[60], the authors propose the History of Operations pattern. In this pattern the authors introduce allowed Operations over a given object or objects. Each operation is comprised of a set of Commands which are executed when an operation is invoked. A History object can then store a sequence of operations when they are invoked, thereby preserving the
41 History of Operations. The authors believe that their History of Operations pattern can also be adopted outside of Adaptive Object-Models. For business data objects we believe the
Change History Record (Chapter 8) and Business Data Object Versioning (Chapter 7) patterns introduced in this dissertation provide a better approach, and offer a more granular and manageable way of tracking changes and recording history over a period of time.
3.6 Patterns for e-business – A strategy for reuse
In their book, Patterns for e-business – A strategy for reuse [84], the authors propose four major types of patterns: Business, Integration, Application, and Runtime. Business patterns are used to “establish the primary business purpose of any solution” and address three areas of a solution: explain major objectives, identify participants, and understand interactions between the participants. Business patterns offered by the authors are the Self-
Service business pattern, the Collaboration business pattern, the Information Aggregation business pattern, and the Extended Enterprise business pattern. Integration patterns are used to integrate individual Business patterns to achieve complete e-business solution. The two integration patterns put forth by the authors are the Access Integration pattern and the
Application Integration pattern. Application patterns convert Business patterns into computer systems and software solutions. The authors present numerous Application patterns in the following areas: Self-Service, Collaboration, Information Aggregation,
Extended Enterprise, Access Integration, and Application Integration. Finally Runtime patterns specify “the logical middleware structure supporting the Application pattern.” The authors’ logical grouping of patterns have provided the idea of pattern groupings presented in this dissertation.
42 3.7 SOA and the Enterprise Service Bus
Modern enterprise applications are almost universally built using a service-oriented architecture (SOA) [7] that relies heavily on web technologies, such as HTTP servers and web service standards for data representation (JSON, XML), and service integration using
Representational State Transfer (REST) [8,9] and SOAP/WSDL [10,11]. In SOA applications invoke services using a request-reply mechanism. A service is a well-defined function that is either standalone (e.g. query for a stock price) or may depend on other services, for example a trip reservation service using separate service for car rental and for hotel reservation. Within the context of a business application, services coordinate an activity following a workflow defined by business practices, but in general services can be on several levels of granularity [12]:
1. technical functions (e.g. logging, send email notification)
2. business functions (e.g. get stock price, save invoice state)
3. business transactions (e.g. create account)
4. business processes (e.g. reserve business trip)
An essential ingredient to the rapid adoption of SOA in the enterprise software industry is the reliance on widely used industry standards. JSON and XML provide a flexible notation for complex data structures and XML is at the foundation for most other web service specification languages. The Simple Object Access Protocol (SOAP [11]) is a specification for web service message and interface definition defined with XML. The
Business Process Execution Language (BPEL) [13] is an XML-based executable language for specifying actions as part of business process execution with web services. A BPEL
43 program describes how a business process interacts with other external web services and can also manipulate their life cycle with sufficient access rights.
An Enterprise Service Bus (ESB) framework is the middleware that allows multiple
SOA service providers to integrate their web services into a coherent and expandable architecture. Typically, a large organization may rely on a multitude of service providers run by its business units using various platforms and developed independently. The ESB
[14, 12] offers uniform APIs and the mechanisms needed to implement the inter-process messaging required for service invocation and execution. In addition to the synchronous request-reply model common to SOA, ESB also supports asynchronous message delivery, needed by clients that require a long-running service or by clients whose lifetime is shorted than the service execution time. The asynchronous message-based communication paradigm is more general than the client-server model and scales better since no open session must be kept on the server for incoming requests. A drawback of the asynchronous messaging model is, however, the need to restructure software from a traditional blocking service call model to a more complex, event-based, approach, making synchronization and service orchestration more elaborate. In this architecture the message server manages distribution of messages for a subset of service providers and clients with various degrees of reliability semantics and latency guarantees.
As external partners may rely on a business’ services that are also shared internally, its
ESB platform must enforce access control and strict authentication and it should cope with participants belonging to different network domains and located at different sites, following different corporate access policies.
44 For higher scalability, ESBs run message servers on cloud computing environments and may be replicated for increased fault tolerance and high traffic volumes. Commercial
ESB platforms are available from IBM (WebSphere Message Broker [15]), Microsoft
(Biztalk [16]), Oracle [17], and many others. The work in [12] presents in detail architectural fundamentals for application integration and design patterns for the ESB.
3.8 Patterns for Enterprise Integration via Message Passing
Hohpe et al. describe in [18] a set of patterns referring to the architectural elements involved in message passing, Enterprise applications are built on accessing services from multiple providers, possibly using disparate technologies, such as languages and platforms.
Application integration has several styles:
file transfer: data shared between application components via files;
shared database: data shared between application components a shared database;
Remote Method/Procedure Invocation: applications expose object methods or
procedures via a well-defined interface and clients can invoke them remotely, via a
network;
messaging: applications connect to a common messaging system and they call services
and share data using messages.
A key problem for developers of Enterprise Service Bus frameworks is the design of the message passing system. The authors describe a set of patterns organized in several categories addressing:
channel patterns: messages delivery on a message channel
message construction patterns: addressing, form, and content of messages
45 routing patterns: delivery of messages from a sender to a receiver or from one channel
to another;
transformation patterns: changing the content of a message or its format;
endpoint patterns: message production and consumption;
system management patterns: tools involved in support of the message-passing
system.
These patterns are harvested from many ESB and SOA frameworks, such as IBM
WebSphere, Oracle Service Bus, Microsoft BizTalk, or Active MQ, Jboss Fuse.
The message passing design patterns operate at an abstraction layer that is lower on the application stack than the patterns proposed in this dissertation, although the versioning
(Chapters 6-8) and access control patterns (Chapter 9) could be applied to manipulating messages as objects and for managing their lifecycle. This could be an interesting avenue for exploration as future work.
3.9 Reusing the Design Rationale
Patterns are an established mechanism for describing generic solution (e.g. design) elements to commonly occurring problems. However, as a communication device, patterns fail to capture the driving design rationale behind an architecture. The issue is that decision makers miss the decision rationale from earlier projects when identify decisions, take them, and later enforce them. The problem is magnified when the decision making process is distributed and involves many participants.
Zimmermann et al. present in [19] a conceptual framework for proactive decision identification, decision maker collaboration, and decision enforcement. At the core of their framework is a metamodel defining the main concepts discovered during architecture
46 decision making, such as design abstraction levels (conceptual/technology/asset), role
(architect/developer/specialist), design alternatives, outcomes, and architectural decisions, and their attributes.
For the first step in the methodology, decision identification, an initial decision model is instantiated from current requirements models and reusable decision templates. A reference architecture brings terminology and architectural patterns. A decision template provides a checklist for reviewing progress. The second step, decision making, relies on proven techniques suitable for each particular decision in order to defeat biases and external influences, such as vendor interests or potential future needs. This step cannot be fully automated because tradeoffs depend on their specific context.
Decision enforcement is enacted in tradition MDA-driven software development processes using iterative design refinement, leading to code. The issue with this approach is that model transformations are not parameterized for project-specific for project-specific decisions and they require manual adjustments, creating a disconnect between design and development tools. The proposed framework advocates for model transformation and code generation automated by interpreting machine-readable decision models.
This work complements patterns and provides a path towards improving design efficiency and quality. The three-step methodology for the decision process is especially useful for the design of enterprise applications in a product line, where multiple versions are customized for a variety of configurations by disparate teams.
3.10 Microservices as an Alternative to SOA
In the past few years microservices - a new flavor for SOA - has taken shape and gained rapid acceptance in the enterprise application industry. According to Lewis and
47 Fowler in [20], the “microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery.” The services require reduced centralized management and can be developed independently, on different type of platforms and using different languages. The REST approach and the HTTP standard protocol are the glue needed for integration, at the technical level.
Enterprise applications following a traditional SOA have a monolithic style: the application is built as a single unit with three major components (or layers): the client-side web interface, typically build with HTML and Javascript, a database running on the server side, and server-side components implementing various business services. With traditional server-side platforms, such as Java EE, the server-side application is executed as a single executable. Monolithic applications are convenient to design, built, and deploy; they also support horizontal load balancing by replicating the server-side application on the cloud.
Still, the main drawback of the monolithic EA is that changes to one element of a server- side application requires rebuilding and redeploying the whole monolithic executable. This is against good modularity and impedes scaling as the entire server process needs to be replicated, not just the highly-used services.
In a microservice-style architecture the components from which applications are built are services that communicate using web service requests or remote procedure calls and this allows an application component to be developed and deployed independently. Loose coupling is further improved with cohesive service boundaries. The drawback of this
48 approach is the higher overhead involved in remote service calls between components, which can be mitigated by making services more coarse-grained and centered around a business capability.
Proponents of microservice architectures adopt a product-centered development model, in contrast to the project-centered model. This means the development team owns the product over its entire lifetime. They also advocate for development teams that are cross-functional, with all the skills necessary, including user interface, database, and project management. This simplifies design and testing and facilitates early interaction with the customer. As a bonus, it instills the team with a sense of ownership in the product.
In contrast to the Enterprise Service Bus architecture that relies on smart mechanisms for message routing, message transformation, and service choreography, microservice architectures take the opposite approach of “smart endpoints and dumb pipes”.
Applications are more decoupled and behave similar to filters in the Unix sense.
Microservices are choreographed using basic RESTful protocols instead of sophisticated tools, such as BPEL ([21,22]) and rely on HTTP/JSON or a simple message passing platform that has a basic message router – for instance Apache Kafka and NSQ.
EA designers considering a microservice architecture can consult a wide range of patterns published in [23] that address service decomposition, messages and inter-process communication, transactions, designing business logic, and queries.
49 4. THE BUSINESS OBJECT PATTERN
4.1 Introduction
A business object is an object which is used often by business applications and services and is a widely acceptable entity in the running of the business. For example, a purchase order, an invoice, and a customer profile could be considered business objects, as these are parts of day-to-day business activity, but more importantly these have well- established and commonly accepted attributes and behavior. Developing business objects from scratch each and every time one is needed is a resource-intensive, highly repetitive, and unnecessary undertaking. One of the challenges faced by today’s enterprise application developers is the lack of a generic approach for specifying the design, delivery, and processing of business objects. In general, a business object may contain one or more of the following: dynamic data object, static document, and workflow. Each time a custom application requires the use of a business object, the developers either have to design it themselves, or use some language and/or platform and/or software dependent solution/library which might or might not address the needs of their application. This paper proposes a new pattern for specifying Dynamic Business Objects for business applications.
The objective of this pattern is to provide a generic approach to design extensible Business
Objects and their frameworks for business applications.
4.2 Intent
The Business Object Pattern describes an extensible design for business objects used for business applications and a structure for their platform-neutral specification.
50 4.3 Example
The Graduate Program Office (GPO) of a university requested a new web page which will enable the office to create, update, monitor, and track individual graduate student’s progress report. The new web page will need to be accessible by the GPO Administrator, the graduate student of the given progress report, as well as all dissertation committee members. In addition to maintaining graduate student’s relevant information, the application will also allow for relevant document uploads, feedback by dissertation committee members, progress notifications, as well as progress report approval and finalization.
The flow depicted in Figure 18 can be used in determining whether the use of business object patterns would be beneficial in designing and developing the requested application:
Yes Is new web No page read/view only?
Use existing Will user input template/methodology No require validation, Yes to design and develop or will progress static HTML pages report updates require approval or review?
Use existing Use Business Objects template/methodology Pattern to design and to design and develop develop business simple HTML Form application web page pages
Figure 18: Decision flow for using Business Objects Pattern
The requirements of the proposed new web pages can benefit from implementation of
Business Objects pattern as it address many of features and functionalities requested.
51 The GPO Administrator should be the only one who is able to create the individual student’s progress report, as well as edit any data on it. In addition to being able to upload the progress report presentation, the student can only update his or her contact information on the progress report. The committee members must each provide the feedback on the student’s progress, and then each must approve the progress report. Once all committee members provided their feedback and approved the student’s progress report, the report is finalized and notifications are sent out informing all involved of the completion.
4.4 Context
Almost all businesses have a web presence for marketing, education, and sales. Many businesses run (directly or via service providers) enterprise applications that encompass most business processes, such as customer relations, product support, sales, etc. Businesses require flexible solutions and reliable frameworks to support their day-to-day operations.
The object-oriented design methodology is widely used in the software industry to model data and logic for business applications. Business objects should have the flexibility and simplicity to solve diverse business problems.
Businesses also require a unified approach to designing and building business objects.
Developers of commercial application frameworks and custom enterprise applications benefit from a portable and reusable business object specification.
Finally, business applications involve complex distributed operations orchestrated on client and server side. On the client side the enterprise applications must enforce visibility, editability and validity of the data being presented, created and modified. On the server side additional business rules can be applied. Applications rely on a variety of documents with static and dynamic content for presentation and for data storage. Document structure
52 and application behavior require a platform-neutral and reusable specification that can be specialized further for particular business cases.
4.5 Problem
Web applications involve complex distributed operations orchestrated on client and server side. Applications rely on variety of documents with static and dynamic content for presentation and for data storage. Document structure and application behavior require a platform-neutral and reusable specification that can be specialized further for particular business cases. The specification must exhibit object-oriented properties, such as modularization, inheritance, and polymorphism. The object specification must include data, format (presentation), behavior, and various constraints.
Business objects must be based on proven business practices. At the same time, business objects should have the flexibility to alter their behavior based on the changing needs of a business. How do I design and develop a business object which encapsulates proven business practices, and at the same time has the flexibility to alter its behavior based on the changing needs of a business?
4.6 Forces
When designing business objects there needs to be a way to encapsulate proven
business practices and subject matter expertise (SME)
Business objects should be capable of handling static and dynamic data
Business objects should maintain data integrity throughout their life cycle
Business object should be able to encapsulate business processing rules
53 4.7 Solution
The Business Object Pattern presents an approach for specification and design of business objects. A business object is comprised of these main classes (see the class diagram in Figure 19):
5. BusinessObject
6. DynamicDataObject
7. StaticDocument
8. Workflow
A business object specification may include any combination of the above elements. For example, a shopping cart contains items that the user wishes to order
(incidentally, these items are also dynamic data objects). The shopping cart item might have an image of the product (an image being a static document). After the shopping cart is submitted by the user, it is processed by some predefined workflow, which ensures that the shopping cart is filled and the ordered items are shipped to the user.
54
Figure 19: The UML class diagram of a business object
4.7.1 The BusinessObject class
This class defines attributes and methods common to application-specific business objects, such as document name, author, creation time, and operations to display and persist an object, respectively. These attributes are inherited by subclasses used to model dynamic data objects and static documents. BusinessObject and its subclasses implement the
Composite design pattern in order to support representation of complex aggregate objects.
The persist() operation applies recursively to component DynamicDataObject and
StaticDocument instances.
The BusinessObject class refers to a set of constraints to control what access rules and specific behaviors are permitted on the object and how they should be accomplished.
55 4.7.2 The DynamicDataObject (DDO) Class
This class represents the data associated with a Business Object that could change over time as a result of some business process or user input. A good example would be a customer data. New customers are often created, and existing customers are frequently updated (i.e. address, contact, payment terms, etc.). A dynamic data object can be maintained via a user interface, or a business process (i.e. a customer data feed is received nightly). The important distinction of a dynamic data object is that, unlike a static document, its contents can be (and often are) changed, and unlike a workflow, it is not a process, but rather an object (or an entity) representing a specific set of data. For example, a purchase order object contains a set of elements representing the items being purchased, from whom, by whom, and under what terms. A purchase order workflow, on the other hand, is a process which takes place from the time a purchase request is submitted, to the time the purchased items are delivered to the buyer (more on the workflow later). Another distinction of a dynamic data object is that, unlike static document, it requires a custom storage solution (i.e. database), as well as a custom user interface. For example, a purchase order entry screen, with its validations and constraints, is a custom interface linking the purchase order data between the user creating it and the data storage where it will be persisted. Even if the data is not persisted in the database, but in another storage (i.e. file, cloud, etc.), the format of the data record(s) must still be predetermined and agreed upon, thereby making it a custom storage solution.
A DDO object is a composite and may contain other business objects (dynamic data objects and static documents). For example, a shopping cart (a DDO object) contains one
56 or more shopping cart items (a shopping cart item is also a DDO object). A shopping cart item may include an image of the item, where image is a static document.
The DDO employs a set of constraints to control what access rules and specific behaviors are permitted on the object and how they should be accomplished. These constraints must be specified using UML's Object Constraint Language where possible or explicitly, with logic in sequence or other behavioral UML diagrams.
4.7.3 The StaticDocument (SD) Class
A StaticDocument class within the Business Object Pattern models a document whose data cannot be changed by end users (i.e. clients) of the application. An example of a static document could be a report printout or a product image file, which users (clients) can view, but the contents of which cannot be modified by clients. Within the Common
Module, static documents can be generated from the dynamic data objects or can be imported from another system or environment. Because a static document cannot be updated, only the visibility constraint can be applied to it.
Unlike dynamic data objects, static documents are generally associated with a widely accepted client viewers, and do not require custom solutions for client presentation.
For example, MS Word and Excel clients are used to view Word and Excel documents respectively, while Adobe Acrobat is used to view PDF documents. It is noteworthy to point out that even though a MS Word documents may be writable, they are considered
StaticDocument objects from this pattern’s perspective because the data within the Word document is self-contained. For example, when I email a copy of this paper to my reviewer, any changes performed by the reviewer are not automatically applied to my copy of the
57 document. From this point of view, the MS Word is a StaticDocument, and not a
DynamicDataObject.
The static document can be divided into two groups: print media and electronic media. As the physical print is still widely used by businesses, it should not be ignored.
4.7.4 Constraints
The Constraint classes provide a way to limit the access to the dynamic data object, and to some extend to the static data object as well. The Business Object Pattern includes three types of constraints which can be imposed on the object: visibility constraint, validity constraint, and editability constraint.
4.7.4.1 The Visibility Constraint
The VisibilityConstraint (ViC) class contains logic that dictates the visibility of a component or attribute of that object. The ViC is not required for every object or entity; it should only be used when needed by the application logic. For example, a ship-to component of a Shopping Cart business object should always be displayed on the shopping cart UI, as without ship-to, there is no way to learn where the shopping cart items will have to be delivered. Therefore, by default, there is no need for a ViC on a ship-to component.
However, a tax on a shopping cart is not always required, and thus would be an ideal candidate for ViC. In this case, the visibility constraint might contain a logic which states that items shipped to certain states need to collect a tax, therefore the tax field must be displayed on those orders. Similarly, the visibility constraint logic would hide the tax fields on orders which are shipped to states which do not require sales tax collection.
58 4.7.4.2 The Validity Constraint
The ValidityConstraint (VaC) class determines the validity of an element (sub- object or attribute) of a BusinessObject instance. A VaC is not required for every object or entity by default. For example, a shopping cart’s comment field, being optional, is valid whether it is empty or contains a comment text. However, a ship-to is required before the shopping cart can be submitted for processing. Validity constraints should only be used when a more complex logic is required to determine if an object or its entity is valid or not.
The VaCs can also be employed by workflows to perform further validation. For example, a workflow could perform a validation on a field to check for malicious entrees
(i.e. links to spam or inappropriate URL, cross scripting, SQL injections, etc).
VaCs should not be used in cases where the constraint can be expressed using established UML notation.
4.7.4.3 The Editability Constraint
The EditabilityConstraint (EC) class contains logic that determines whether an element (component or attribute) of a BusinessObject instance is editable, i.e. changeable by some user interface. The EC is not required for every object or entity; it should only be used when editability of an element is driven by business logic. For example, a Shopping
Cart comment field should always be editable as it is intended to gather additional information from the user. However, a tax field or a shipping charge field should not be editable because these are derived based on item cost and shipping destination. The EC comes into play when the editability of an object or its entity depends on some additional logic which must be recorded as part of the analysis and design process. Element editability can be qualified (parameterized) with contextual information, such as user role. For
59 example, a clerk at a warehouse could verify the quantity of an item which needs to be shipped, however only a warehouse manager can edit that quantity if needed.
The use of roles can also be extended to the Visibility and Validity constraints by applying Securing Analysis Patterns [24].
It is important to stress that constraint classes do not alter the structure of the object itself or of its entities. If, for example, a Tax element is hidden by ViC, its value remains unchanged and could not be (nor should be) altered by any of the constraints.
4.7.5 The Workflow Class
The Workflow class contains the logic associated with the Business Object, the sequence of operations that the Business Object goes through as part of the business process. A workflow's operations (Operation classes) are distributed on the client and on the server side and can be executed sequentially or concurrently. The runtime for a workflow is platform-neutral, generic, and is interpreted by the various actors subsystems involved in its execution.
A workflow involves the business object's dynamic and static documents, and possibly other business objects, as well as services provided by the infrastructure. For example, the workflow of a Shopping Cart business object begins when customer submits the shopping cart with desired items to be purchased. The workflow then executes logic which verifies customer's payment information, then forwards the shopping cart request to the warehouse for packaging and shipping. Once items are shipped, the workflow will notify customer of completion.
The Workflow class is an essential part of the Business Object Pattern as its main responsibility is to track the status of the business object through its life cycle, and take
60 appropriate action in each stage. For example, when user submits a shopping cart to be processed, it is the shopping cart's workflow logic that determines what needs to occur next. The workflow might first check the billing data of the shopper to ensure that it is valid. If could then check the warehouse inventory to ensure that the ordered items are available, and if they are not, the workflow would then send out an email to the shopper with further instructions. The workflow “moves” the business object from one stage to another, until the process is completed.
4.8 Consequences
This pattern provides the ability to address business objects specific needs of the business applications. The pattern allows for incorporation of business practices and subject matter expertise (SME) without the need to restructure the business object itself.
The pattern also addresses the dynamic vs static nature of business objects, and the different ways in which each needs to be implemented. The integrity of the business object is addressed via Constraints class, which ensures that the object data validity, visibility and editability is enforced. Finally, the Workflow class ensures that the business object can move through various states of a given business process.
4.9 Known Uses
Ariba Inc. (now part of SAP AG [25]) uses similar approach in its architecture and software products [26]. Ariba uses the concept of an Approvable class, which is a representation of a business entity. The Approvable object is similar to the BusinessObject class presented in this paper. Within the Ariba architecture the Approvable object is coupled with the user interface and a storage medium, and its data is expected to be dynamic throughout the object's life cycle. The Ariba architecture also includes a workflow
61 component which manages the Approvable object through the required business processes and events.
The San Francisco Project [27] was started by IBM to develop shareable frameworks in Java which are comprised of “an infrastructure for distributed object applications, business objects that are common across multiple domains, and domain specific frameworks that contain subset of the objects and business logic that are needed to build a commercial application.” It is comprised of three main layers: Base Infrastructure,
Common Business Objects, and Core Business Processes. The Common Business Objects in the San Francisco Project are similar to the Common Module as a collection of Business
Objects presented in this paper. Unlike the workflow introduced in this paper, which is part of a given business object, the San Francisco’s Core Business Processes are separate from the Common Business Objects.
Oracle has introduced the concept of business objects as part of its Oracle
Applications Business Objects offering. Similar to IBM’s approach. Oracle’s solutions was to group the implementation of its business objects into 3 areas: Business Intelligence, Self-
Service Web Applications, and Workflow. The Business Object Pattern introduced in this paper is similar to Oracle’s solution in that Oracle Self-Service Web Applications are processed, or moved through the stages, by Oracle Workflow solution, which is tightly coupled with the Self-Service Web Applications.
4.10 Related Patterns and Frameworks
4.10.1 The Document-View-Presentation (DVP) Pattern
DVP [28] separates an application into three components: document, view, and presentation. The document component holds business logic and data. The view component
62 is responsible for service requests and supplying the data to the document. The presentation component processes the events and provides data to the view component.
The Business Object Pattern differs from the DVP in that it separates the objects into two types: DynamicDataObject and StaticDocument. Unlike DVP, the Business
Object Pattern leaves the retrieval and presentation of data to the DDO. In addition, the presentation of SD is left to the application handling the specific type of document (i.e. MS
Word for .doc and .docx types, Adobe PDF for .pdf type, etc). Finally, the Business Object
Pattern offers a workflow component, which is not available in DVP.
4.10.2 The Presentation-Abstraction-Control (PAC) Pattern
PAC [29] defines a structure for interactive software systems in the form of a hierarchy of cooperating agents. In PAC, every agent is responsible for a specific area of the application's functionality and is comprised of three components: presentation, abstraction, and control. The abstraction component in PAC is similar to MVC’s model component. The presentation component in PAC can be viewed as a combination of view and controller components in MVC pattern. The control component is responsible for facilitation between PAC agents.
The BusinessObject class is similar to PAC’s agent in that it can define a single business object, or a group of business objects comprising a module (or a system in PAC).
In PAC, agents are responsible for data retrieval, presentation and maintenance. The
Business Object Pattern differs here from PAC in that it classifies the data as dynamic or static, and consequently uses different presentation mechanisms for each. In addition, the job of business processes is handled by the workflow component in Business Object
Pattern, whereas in PAC it is the responsibility of the agent itself.
63 4.10.3 The Common Business Objects Framework (CBOF)
The Common Business Objects Framework was proposed by the Object
Management Group (OMG). It is based on OMG’s CORBA and Business Objects
Framework specification, which handles business concepts, processes and events. Like
Business Object Pattern, the Common Business Objects in CBOF represent the business rules, functions and processes. Also like Business Object Pattern, CBOF groups CBOs into different groups (modules in Business Object Pattern), each group specializing in particular business area (i.e. Finance, Health Care, Manufacturing, etc.). Unlike CBOF, the Business
Object Pattern is not bound by any specific technology. CBOF is a particular framework technology, tightly coupled with the Common Object Request Broker Architecture
(CORBA) and relies on many of its feature to make the Common Business Objects work.
There are also several commercial products in the area of Business Objects presentation using XML. Among them are SmartClient [30], Adobe Flex [31], Sencha
GXT [32], Vaadin [33] and Icefaces [34] software products.
4.10.4 Web Business Objects
In recent years the Service Oriented Architecture (SOA) has gain a great amount of popularity, and many business applications have been developed using the SOA. The main attraction of SOA over other frameworks is that, with exception of XML, it is language independent, and is entirely web based. A great example of SOA business application is federal government’s Federal Procurement Data System – Next Generation [35], one of the earlier adapters of SOA.
64 4.11 Conclusions
The Business Object Pattern provides a reusable and flexible approach to address just about any business problem and offer a solution based on proven methods. By isolating different business functions into specific modules, we can narrow our analysis to a specific module, and employ that module’s pattern to solve the business problem at hand. In this pattern we introduced the concepts of Dynamic vs Static business object, and the applicability scenarios for each. This pattern also introduced business object constraints – validity, editability, and visibility, which are essential to maintaining the integrity of a business object. Finally, the pattern introduced a workflow in the context of a business object, and presented it benefits.
65 5. THE BUSINESS OBJECT LIFE CYCLE PATTERN
5.1 Introduction
Business data is arguably the blood line of a typical enterprise. Data is vital to just about every business process, internal or external, and the data management is just as important as the data itself. There are a number of forces which mold the life cycle of the businesses’ data. There are economic forces, which allow businesses to stay competitive by the way they use and maintain their data. There are legal forces, which bind businesses to certain laws. There are privacy and accounting practices businesses must adhere to.
Finally, there's a growing social pressure on the ethics of usage and dissemination of personal data by government agencies and business entities.
The Business Object Life Cycle pattern addresses and abstracts the various stages which comprise a business object’s life cycle.
5.2 Intent
Business objects are constantly created, updated, and shared by different processes and applications. There needs to be a way to ensure the business objects' integrity and availability throughout their life cycle. In this pattern we introduce the concept of various stages which comprise a business object’s life cycle, and during which proper checks, validations, and verifications are possible.
5.3 Example
Within the business environment, every business object that is being created (or updated) must pass certain scrutiny before it becomes available for general consumption.
66 Consider, for example, a process of adding a new vendor to the system. It is not just a matter of entering the new vendor information in the vendor database. After the new vendor data has been entered in the system, it must first pass certain approvals and validations before it can be made available for consumption by other processes. The new vendor must first be approved by the buying organization of the business, who signs off on such things as who asked for the new vendor, and why is the new vendor being added to the system.
Then there is legal department approval and validation which must take place before the new vendor can be made available system-wide. Are there any obstacles to doing business with the new vendor? Has the background check been completed? Has the vendor's tax payer ID been verified? There could be, and often are, other approvals, checks, validations and verifications which must take place before the new vendor business object can be made available for general usage. Only after the new vendor business object has gone through and completed all the required checks, can it be then made available for consumption within the business application.
5.4 Context
Often changes to business objects could have legal as well as economic consequences, and must therefore follow strict corporate and at times government procedures and restrictions [36]. Most, if not all, business objects follow a certain life cycle, and are frequently modified, shared, deleted or copied.
You are designing a new business object which will be incorporated into your company's system. It is expected that the new business object will be accessed by the current applications and processes within the system. However, when the new business object is first created (or subsequently updated) within the system, it must pass some
67 predefined approvals, validations, verifications and crosschecks before it becomes available for usage by the rest of the system.
5.5 Problem
As business object transitions between stages during its life cycle, how do you control changes such that its integrity and availability are ensured throughout the life cycle?
5.6 Forces
All business objects should follow a certain life cycle process throughout which
they are created, updated and shared.
Business object cannot and should not be created, updated or shared without an
underlying process which guards its integrity.
Managing the life cycle of business objects is often ignored or not followed,
resulting in inconsistent data at best, and missing or incorrect data at worst.
Business object life cycle should be flexible to adjust to constantly changing
business conditions.
Business object life cycle should be extendible to address different needs of
different business applications.
5.7 Solution
When a business object is created within a system, it must pass certain scrutiny before it can be considered a valid and complete business object within that system. During its life cycle a business object may go through various transition stages which determine its availability within the given system. In this paper we propose that at a minimum a business object must to go through three stages in its life cycle. The three basic stages are:
68 Create/Update Stage. This is the initial stage, during which the business object is
created, if it’s a new business object, or updated if it an existing one.
Workflow Stage. During this stage the business object undergoes vigorous
validations, verifications, and crosschecks.
Ready Stage. Once in this stage, the business object is ready and available for
consumption
Figure 20: Illustration of a Business Object life cycle using the example with the
Vendor business object
Creation/Update Stage
During this stage the business object is either created anew (for example when we create a new vendor), or is updated as the result of some data changes to the given business object. To reference above example, a new vendor business object must first be created and populated with vendor specific data. An existing vendor object can be updated during
69 this stage also. While in Create/Update stage, the business object is not available for consumption by other entities or processes. For example, a business object representing a new vendor ABC which is in the process of being created is not accessible by other business objects, such as purchase requisition or ordering process, because vendor ABC is not yet
“ready” to be consumed. It is important to note that if the business object is being updated, the update is performed on a copy of the original, and not on the original itself. This way the original business object is still available in the system, and only its copy is being updated. Once the copy is fully updated and enters the Ready stage, it replaces the original.
Workflow Stage
Once the Create/Update stage has been completed, the business object enters the
Workflow Stage. During this stage the workflow process takes over the state of the business object. As per above examples, a newly created vendor must pass vigorous validations, verifications and crosschecks before it can be available for consumption in the system.
Note that within the system, the workflow process can be either manual or automated process. The important thing to understand is that it is the workflow process that contains the logic (or rules) which must be applied to the business object. The business object itself does not (and should not) contains any logic (or rules) on how it should be processed by the workflow. The business object simply contains a set of related data which together comprise a specific business object (i.e. vendor, purchase request, etc.).
It should be noted that not all business objects must pass a complicated workflow stage. For example, a change to vendor contact data should not require high level approval or rigorous validation and verification. Thus a change to vendor's contact information
70 would require an update (Create/Update stage), some sort of simple approval (Workflow stage), and finally the change available system-wide (Ready stage), as seen in Figure 20.
Additionally, the Workflow stage is very flexible in that it can be highly configurable. Specific workflow implementations and types are outside of the scope of this paper, but suffice it to say that operations within a workflow can be different for different implementation. For example, in Figure 20 each approver is shown as having the ability to approve or deny the request. However, depending on the workflow implementation, an approver or a process within the workflow can also send the request back to the previous approver/process for re-validation/re-verification if necessary. Our example shows only two options (Approve or Deny) for simplicity purposes only.
Of the three stages, the Workflow is the only optional stage. Frequently, business objects need to be created in the system which does not require any validation or verification. An example of such business object would be a new customer. New customers need to be created quickly and frequently, and often do not require any validation or verification. Thus a new customer business object would only need Create/Update and
Ready stages.
It is important to note that although a new customer business object does not require validation/verification, it should still go through “an empty” Workflow stage. Thus if in the future a need arises to add some business rules to a new customer business object, they can readily be added to the existing workflow.
Ready Stage
Once the logic (or rules) of the Workflow Stage have been completed, the business object enters the Ready stage. At this stage no further updates to the business object are
71 allowed. From examples above, once all the approvals, validations, verifications and crosschecks have been performed on the vendor object during the Workflow stage, no further changes can be made to it while the business object is in Ready stage. When the business object enters Ready stage, it is available for consumption by other processes and entities. A new vendor business object can now be used to purchase supplies from.
When a business object needs to be updated (as opposed to being created new), a slightly different sequence of events should be followed. Prior to making any changes to the business object, a copy (new version) of that object must first be created. This is exemplified in Figure 21. There are a number of advantages to this approach:
1. While the new version of the business object is being updated, verified and
validated, the original version is still available for consumption within the system.
2. Updates to the new version are made independent of the original version, which
allows for audit trail and historical records keeping. Not only the changes
themselves are tracked, but the owner of the changes (who made the change) and
when the changes were made can be recorded.
72
Figure 21: Example of the three stages of a Business Object’s life cycle for update.
The Business Object Life Cycle Pattern is not only applicable to data or documents created by humans, and should be applied to the data generated, exchanged or modified between processes. For example, a supplier might send a catalog file to its customer for use in the customer's internal procurement system. Upon receipt of the catalog file from the supplier, the customer's system should first submit it for some sort of review, validation and acceptance process, before making the catalog available for general use by its employees. By following our pattern, this process would take place, and the supplier's catalog would go through the process of creation, validation and verification, and finally approval to become part of the customer's procurement system.
Naturally, there could be, and often are, more stages that a business object must go through in its life cycle. The additional stages are often due to industry specific requirements, application constraints, or business process demands. But any additional stages should be the extension of the three original stages proposed in this paper:
Create/Update, Workflow, Ready.
73 For example, a purchase requisition might go through the following stages in its life cycle:
Created → Submitted For Approval → Approved → Converted to Purchase Order → Sent to Vendor.
Although the transition stages are specific to a purchasing requisition, they are the extension of the original three stages. The Created Stage corresponds to the Create/Update
Stage of the business object life cycle. During this stage the purchase request is created and the items that need to be ordered are added to the purchase request. The “Submitted for
Approval” Stage corresponds to the Workflow Stage. During this stage the purchase request might go through the approval process, as well as validation and crosscheck, such as funds availability and verification, order amount limit, etc. Finally, once purchase request has been fully approved, it is in Approved Stage (i.e. Ready Stage), at which point it is “ready” to be converted into a purchase order and sent to the vendor for fulfillment.
5.8 Consequences
By adhering to the business object transition stages, we can enforce as many or as little business rules and processes as needed, without changing the underlying structure of the business object.
By employing the Business Object Life Cycle pattern we can improve business object concurrency and synchronization, which can be applied using different rules for each stage, thereby providing a granular implementation of business object concurrency and synchronization needs.
Finally, the Business Object Life Cycle pattern allows for version control or change management implementation of business object. For example, for business object updates,
74 a copy of the existing business object could be used instead of the original. This way the original is still available and accessible in the system, while its copy is being worked on.
Only when (or if) the copy reaches the Ready stage, would it replace the original version with its new changes.
5.9 Known uses
Most, if not all, major Commercial Off The Shelf (COTS) Enterprise Resource
Planning (ERP) developers such as Oracle and SAP, to name the two biggest, utilize extensive business object life cycle management processes to ensure the business data integrity. Ariba Inc., which has recently been acquired by SAP [25] uses similar data object process in its architecture and software products [26]. Ariba uses the concept of an
Approvable object, which is a representation of a business object. The Approvable object is similar to the business object presented in this paper in that within Ariba architecture the
Approvable object goes through a three stage process before it is fully approved and can be used within the system. In Ariba, the three stages are: Composing, Submitted, and
Approved. The Ariba architecture includes a workflow component which manages the
Approvable object through the business life cycle. Similarly, only when Approvable object is fully approved does it become available to other processes and entities within the system.
5.10 Related Patterns and Frameworks
5.10.1 The Document-View-Presentation (DVP) Pattern
DVP [28] separates an application into three components: document, view, and presentation. The document component holds business logic and data. The view component is responsible for service requests and supplying the data to the document. The presentation component processes the events and provides data to the view component.
75 The Business Object Life Cycle Pattern differs from DVP in that its main goal is to address the document life cycle, and not the particulars of its presentation.
5.10.2 The Model-View-Controller (MVC) Pattern
MVC [37] has become one of the most popular and widely accepted patterns in the market today. Its main benefit is that it separates the presentation of information from the business logic and data storage. The model component in MVC is responsible for business logic and data storage. The view component handles the end user presentation of the requested data. The controller component handles the input from the view component and converts it into instructions for the view and/or model.
Unlike the Business Object Life Cycle Pattern, the MVC can only support a request/response mode, and does not provide the means for handling a business process in the form of a workflow.
5.10.3 The Presentation-Abstraction-Control (PAC) Pattern
PAC [29] defines a structure for interactive software systems in the form of a hierarchy of cooperating agents. In PAC, every agent is responsible for a specific area of the application's functionality and is comprised of three components: presentation, abstraction, and control. The abstraction component in PAC is similar to MVC’s model component. The presentation component in PAC can be viewed as a combination of view and controller components in MVC pattern. The control component is responsible for facilitation between PAC agents.
The job of business processes is handled by the workflow component in the
Business Object Life Cycle Pattern, whereas in PAC it is the responsibility of the agent itself.
76 5.10.4 Workflow Patterns
Workflow Patterns [39] describe various patterns of the workflow process, covering Sequence, Parallel Split, Synchronization, and many other patterns.
The Business Object Life Cycle Pattern differs from the Workflow Patterns in that it is at a more abstract level than the inner workings of a particular workflow, and is not concerned with the type of workflow pattern that is being employed in the data object's life cycle, but rather how it is being employed.
5.11 Conclusions
The three stages life cycle pattern can be applied to just about any data-driven business object within business environment. At the same time, it can be extended to address specific and more complex business needs. For example, a purchase request, before entering the Ready stage, might go through other interim stages (i.e. Sent to vendor,
Shipped, Received, etc.). We believe that the Business Object Life Cycle Pattern is simple enough to be applicable to most business scenarios, yet easily extensible to add much more complex and more realistic business data and processes.
77 6. THE SIMPLE CHANGE HISTORY PATTERN
6.1 Introduction
In typical day-to-day operations of almost any enterprise, the end users of the enterprise applications are mainly concerned with easy access to data and completing their assigned tasks based on that data in the most efficient way possible. However in a multi- user environment, it is often beneficial, and at times required, to keep track of who made changes and when, and even what changes were performed. In general, more than one user or process may alter business data, and it is expected that applications supporting multi- user environments have the means and a build-in ability of track any and all changes performed to business data objects by users and processes. This capability is required in order to support an audit trail (NIST, 1997) to comply with legislation, such as the
Sarbanes-Oxley Act of 2002 (Sarbanes-Oxley, 2002) applicable to business financial records, or with the HIPAA Audit Program Protocol (DHHS, 2016), addressing patient record privacy. The granularity of the required change tracking is often driven by the type of business, or the type of data being changed, or economical, political, and legal forces outside of the business itself. For these reasons, there is no “one glove fits all” approach when it comes to designing and implementing audit trail solutions and it seems software architects may have to come up with a custom design. However, across the software industry and the different business domains, application architectures and design methodologies share common elements that can be formulated as design patterns.
78 The first of three patterns permission patterns, the Simple Change History pattern, addresses the problem of adding a simple audit trail in existing enterprise applications where a minimal change is required or even possible without significant code change.
6.2 Intent
In a multi-user environment changes to business data can be frequent and performed by more than one user. Knowing who last performed the change and when can be beneficial for audit trail and accountability. In this pattern we introduce the concept of simple change history, which enforces recording of the owner and date of the last change performed on a given business data object.
6.3 Example
A Human Resources (HR) application maintains a record of employees, including their personal and salary information. A new employee has been entered into the system by an HR clerk who entered the new employee’s salary incorrectly. An HR manager, realizing the mistake, must update the new employee’s salary to reflect the correct amount.
An audit trail for the initial creation and the subsequent update exists, recoding the owner, and the date and time of the initial employee record creation, as well as the owner, and the date and time of the subsequent update.
6.4 Context
You are designing a multi-user business application in which a given data object can be created and subsequently updated by different users at different times. Only the most recent update needs to be recorded.
6.5 Problem
How to keep track of who created or modified a given business data object and when.
79 6.6 Forces
It is important to know which user created/updated a given business data objects
and when.
A comprehensive policy of audit trail requirements has not been developed, and a
minimal approach is sufficient.
Major data structure changes are often difficult to implement in the legacy systems
so the least invasive approach for introducing an audit trail is needed.
6.7 Solution
“A business data object is a software artifact often used by business applications and services and it is a widely acceptable entity in the running of the business.” [40] In above example an employee record is considered a business data object as it is part of an HR application and has a well-established and commonly accepted attributes and behavior.
One of the simplest ways to track changes performed on a business data object is to store information of the most recent owner and the date (and time) of the change, as shown in
Figure 22.
Figure 22: UML class diagram for the BusinessDataObject class, with change history attributes and associations to a User class
80 The User class represents the identity of the user or process managing the object. If the object is being updated or created by some process within an application, then the User class would represent the owner of that process. By adding the createDate and updateDate attributes, and the createdBy and updatedBy associations to every business data object, we can enable a simple change history tracking of each data object. Every time a user or a process performs a change to an existing business data object, or creates a new data object, we can track the owner and date of the change. When a data object is initially created, the createdBy and createDate attributes are set to the user object that initiated the creation of the said object, as well as the date the creation took place. Consequently, when updates occur to the given data object, the updatedBy reference and the updateDate attribute are set to the corresponding user object and the date of the update, respectively.
6.8 Consequences
The Simple Change History Pattern enables an application to store the information on who performed the creation or update of a given business object and when, but the pattern falls short of keeping track of multiple updates to a given business data object. Because there is only one attribute for update owner and one for update date, the pattern allows for recording of the most recent update information only, thus resulting in the loss of the information about the previous updates. The pattern is a good fit when requirements are not detailed or specific, or when dealing with legacy applications, where significant changes to business data object might not be feasible, or when requirements for audit trail do not call for elaborate or complex approaches.
81 6.9 Known uses
Most major Commercial Off The Shelf (COTS) Enterprise Resource Planning (ERP) application developers such as Oracle and SAP, to name the two biggest, implement this pattern. The owner and date of change attributes are added to almost every business data object in these types of applications. In particular, Oracle Applications have
CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, and
LAST_UPDATE_DATE columns on most of their master data tables, such as
PO_HEADERS, PO_REQUISITION_HEADERS, PO_VENDORS, etc. [41]. These columns are used to store the owner and date of creation and change of every row of data within the application tables.
6.10 Conclusions
The Simple Change History Pattern is best suited for legacy systems, where changes to object and data structures are often limited. The simplicity of the pattern and its minimalistic approach make it a good candidate for systems and applications which have already been built, but which currently do not have any of the audit trail or historical record keeping capabilities. This pattern been proven over time by being widely applied in many
COTS enterprise applications, including products from Oracle, SAP, Ariba, PeopleSoft, and others.
82 7. THE BUSINESS DATA OBJECT VERSIONING PATTERN
7.1 Introduction
Often times the minimalist approach of the Simple Change History Pattern may not be sufficient to address business needs and requirements. Knowing who made the change and when may not be enough, and additional history information is required. The Business
Data Object Versioning Pattern addresses this problem by defining a pattern for preservation of every change iteration, as well as a rollback of the most recent change, if one is necessary.
7.2 Intent
There are often times when a simple record keeping of who made the changes and when is not sufficient because changes to a business data object are complex, may take time, and/or require review, validation and verification. At the same time, the business data object still needs to be available and accessible within the given application. The Business
Data Object Versioning Pattern provides a solution by introducing a new version of a given business data object which allows for preservation of the original data, and continuous validations and approvals of the proposed changes to a given business data object, without making them available to the application until all approvals and validations are completed.
7.3 Example
A purchase order has been issued to a vendor for the purchase of two new laptops.
However, soon after the purchase order had been sent to the vendor, it has been determined that the ship to address was entered incorrectly, and an additional laptop is required. A
83 change order (or a new version) of the existing order with the correct ship to address and the updated laptop quantity is created and submitted to the purchasing agent for approval of the proposed changes to the original order. The approval must take place before the change order can be sent to the vendor. Because the changes need to be approved, these changes cannot be applied to the original order object. At the same time, once the changes are approved, the application will preserve both the original and new versions of a given business data object, thereby providing an automatic audit trail if needed.
7.4 Context
You are designing a business application that requires that business data objects are constantly available, even when these data objects are in the process of being updated, and the updates can take time in order to be validated and approved. In addition, you need a mechanism to keep track of all changes performed on a given business data object over time.
7.5 Problem
How can existing business data object continue to maintain its original data within a business application while the proposed changes undergo validation, verification and approval. How can we keep track of all changes made to a given business data object over time.
7.6 Forces
While updates are being performed on the new version of the business data object,
the current version must remain available within the given system/application.
Requested updates which are not approved or which fail validation/verification
must not be applied to the current version of the business data object.
84 Business data objects must always be available and accessible within a system, even
while the updates on these data objects are being performed.
A full history of all changes performed on a business data object needs to be
preserved and is readily available when needed.
7.7 Solution
The class diagram in Figure 23 illustrates the design for this pattern. When a business data object needs to be modified, a new version of that object is created by making a duplicate copy of the original business data object. The original business data object is available within the system as identified by the previousVersionObj reference until changes are completed to the new version and approved, at which point the new version becomes the latest and current version of the business data object within the system, and the previous version is deactivated or retired.
Figure 23: UML class diagram for a Business Data Object with new version attributes
The activeFlag represents whether the object is active and available within a given system. The sequence diagram from Figure 24 shows the sequence of operations involved when a change is made to a business object. The original business object creates a new version, which is an exact copy of itself, but with the new changes, then submits the new version object for an approval process that could be an external element of the system. If
85 the approval succeeds, the new object replaces the original one, while keeping a reference to it, which is useful for audit.
The following tables list the procedure using the purchase order example described in the example above.
The original order has a Ship To Code of US001:
Table 1: Original Order
Order ID Order Active Previous Create Created By Ship
Version Flag Version Date To
Code
PO123 1 true Jan 1, 2015 User123 US001
We need to change the Ship To code to US023, so a new version of the order is created:
Table 2: Change Order In Progress
Order ID Order Active Previous Create Created Ship To
Version Flag Version Date By Code
PO123 1 true Jan 1, 2015 User123 US001
PO123 2 false PO123, Jan 2, 2015 User567 US023
Version 1
While the new version is being approved, the original version is still available in the system (its activeFlag attribute is set to true). Because the original version has already been approved, it can no longer be modified and is therefore a read-only version, thereby preventing any possible branching into more than one new version at a time. The new
86 version is only available for approval, verification and/or validation, but not for general use within the system (activeFlag is false).
Once the new version is fully approved, it becomes the active read-only data object.
The previous version is deactivated or retired, and is no longer available for general use within the system:
Table 3: Change Order Completed
Order ID Order Active Previous Create Created Ship To
Version Flag Version Date By Code
PO123 1 false Jan 1, 2015 User123 US001
PO123 2 true PO123, Jan 2, 2015 User567 US023
Version 1
Figure 24: UML sequence diagram for the Business Data Object class when a change is made to the object As seen in Figure 24, while the object's change approval is pending, the system should lock the object for subsequent changes. Once the changes have been approved, the original
87 data object is replaced with its new version. The original data object is not deleted, but rather set inactive: setActive(fase). This ensures that the original database object is preserved, but at the same time is not available for use as it has been retired and replaced by its newer version.
If on the other hand, the requested changes are denied, then the new version can simply be discarded or archived, and the original version of the data object remains in the system as the most recent version.
7.8 Consequences
All changes are performed on the new version of the business data object, while leaving previous version untouched and in read-only mode. Additionally, once a new version has been initiated, no other new versions are allowed. Only one new version of the business data object can exist at any given time. If the validation/approval process is lengthy, the previous version, or as far as the general audience is concerned, the current version, is still available for usage within a system until new version is verified and/or validated, and subsequently fully approved. If changes to the new version are not approved, the new version can then be deleted or archived for audit, leaving the previous version as the most current one. The most recent fully approved version of the business data object is always available within the system, regardless of what changes are being proposed or are in the process of being applied. All changes performed and approved are part of the new version, thereby creating a full automatic audit trail via previous versions of the given business data object.
An easy and convenient link between the most current version and the previous one is provided via the previousVersionObj object reference. Because all of the data is
88 preserved at the version level, the specifics of audit trail requirements need not be determined at design time, thereby making this pattern flexible and dynamic from audit trail requirements perspective. However, due to versioning of the business data object, and the logic required to ensure that the most recent version of the business data object is available to the application, and all previous versions are inactive, this pattern might not be an ideal fit for existing applications, where the business data object presentation logic is already in place and might not be easily adaptable to the versioning pattern. Changes to the new version by multiple users are not tracked as part of this pattern. To address the multi-user changes to the new version, it is recommended that this pattern be combined with the Change History Record Pattern, which is covered in the next section.
7.9 Known uses
Many COTS developers actively use a data object versioning in their applications, including SAP and Ariba. Users of these applications are provided with easy access to view and report on all changes performed on a given business data object allowing for seamless audit trail. Ariba, the developer of Procurement and Supply Chain applications, uses the concept of New Version on many of their data objects, including Requisitions, Purchase
Orders, Invoices, etc. [26] When a user needs to make a change to a requisition that has already been approved, he or she simply clicks on the Change button, which behind the scenes results in the creation of the new version, which is a duplicate copy of the requisition being changed. Ariba denotes the new requisition number with –V (i.e. V2 for version 2,
V3 for version 3, etc.) to inform the end user which version they are working with.
89 7.10 Conclusions
While the Simple Change History Pattern provides a quick and simple way to address a minimalist approach to audit trail of business data change history, the Business Data
Object Versioning Pattern is preferable when requirements call for capturing significantly more details about the history of changes which took place. This pattern introduces the concept of versioning of business data objects, which in turn allows for preservation of every change that has been performed on a given data. The versioning also allows for easy audit trail reporting by comparing the values of a given business object between the versions. Finally, the versioning approach provides convenient method of backing out the changes if this is ever needed or requested.
90 8. THE CHANGE HISTORY RECORD PATTERN
8.1 Introduction
The Simple Change History Pattern and the Business Data Object Versioning Pattern may not be suited for systems which require highly configurable audit trail. Often laws, regulations, and business conditions drive the audit trail requirements, which can also be fluid and may continuously change over time. For this reason it is preferable to have a configurable order trail as opposed to the one that has been designed and developed for specific instances. The pattern introduced in this chapter addresses this problem by defining a history record approach, which unlike the previous two patterns, is highly configurable and is much easier to maintain over time.
8.2 Intent
This pattern provides a solution for multi-user environments where the changes to a business data object are performed by multiple users and where there is a need to capture the information about who made the changes, when, and what changes were performed. In addition, it makes applications able to configure at runtime which changes should be recorded and which can be ignored.
8.3 Example
An employee gets married, receives a long overdue promotion and a raise. Within an
HR system, the changes to marital status, promotion and increased salary need to be updated on the employee record. Because of sensitivity and privacy, the salary should only be updated by someone with a more privileged access than a user who could update marital
91 status and employee level. Thus, at least two users would need to update the same employee record. Each update would need to be recorded and stored for future reference. The recorded data would contain the date and time of the update, the owner of the update, the reason for the update, as well as the old and new values of the updates.
8.4 Context
You are designing a new business application which requires that all changes to existing business data objects are recorded and available for audit, reporting, searches, etc.
Often the subject matter experts (SME) such as auditors are the ones who ultimately determine what changes must be recorded. Consequently the types of changes which are to be recorded should also be configurable at run-time, and not predetermined at design- time.
8.5 Problem
How can a business application be designed such that an SME can easily configure a change history recording for any given business data object.
8.6 Forces
An audit trail is often required for certain business data objects, but the specific
requirements are not available at design time.
Business subject matter experts (SME), and not application designers and
developers, should be in control of what data falls under audit trail requirements.
Business data objects can often be updated multiple times by multiple users during
the objects’ life cycle, but the number and type of changes that will be performed
is not known at design time.
92 Records of changes to business data objects must contain detailed information on
who performed a given change, when, why, and what specific changes took place
(i.e. new value and old value are preserved as part of the record of change).
Often, an audit trail and historical records must be implemented for business data
objects in legacy applications designed without any support for audit trail /
historical record keeping.
If space is a concern, it is beneficial to have a control over which parts of the
business data object should be part of audit trail, and which can be ignored.
8.7 Solution
The class diagram in Figure 25 describes the design for this solution. The business object references a set of change record objects. Each change to a business data object – the old value and the new value – and the time of the change are recorded and stored by a
ChangeRecord object. This record is then linked to the business data object (parent object) via an object reference (businessObj) or by some other uniquely identifiable mechanism.
93 Figure 25: UML class diagram for a business data object with change history records Although a history record can be comprised of a wide variety of attributes to address specific business needs, at minimum each change record must have the following attributes and associations:
Date and time of change. This attribute stores the date/time the change was
performed.
changedByUser: reference to the user object initiating the change.
changedAttributeName: the name of the business data object attribute (field) being
changed. For example, when employee’s salary is raised, this attribute would
contain a name of the salary attribute for employee business data object.
newValue:the new value of the business object field that was updated. In the
example of employee’s salary raise, this attribute would contain the employee’s
new salary amount. Because the type of the data being updated is not known in
advance, the type of New Value attribute should be Object, which in most modern
systems can store just about any data type.
94 oldValue: stores the old value of the field that was updated. In the example of
employee’s salary raise, this attribute would contain the employee’s old salary
amount. Because the type of the data being updated is not known in advance, the
type of oldValue attribute should be Object, too.
businessObject: this reference points to the business data object being updated.
There should be no Change Record object without a reference to a valid business
data object.
comment: this is an optional String attribute for storing a user entered comment
about the reason for the change being performed.
8.8 Consequences
This pattern provides the ability to store any changes performed on the business data object within a given business application. It allows for recording of changes to the same business data object by multiple users/processes. It also allows for recording of the identity of the user who performed the change, when, why, and the new and old values of the changed fields. The pattern assumes that the changes performed on the data object are synchronized and only one user/process may perform the changes at any given time. A rollback of the changes can be achieved by combining this pattern with the versioning pattern presented in the previous section, whereby unapproved changes request is denied and the changes are discarded. The pattern does not require that the audit trail requirement be known at design time. Instead, the pattern allows for the audit trail requirements to be highly configurable at run-time. By allowing this high flexibility over the configuration, of the three patterns presented in this paper, this pattern is best suited for business SMEs. By providing the ability to configure which data falls under audit trail, and which does not, the
95 pattern is also sensitive to possible space constrains and the volumes of audit trail and historical records which could bare direct effect on it. The pattern also provides the ability for legacy business data objects, which might not have been originally designed with audit trail in mind. Because the pattern allows for high level of configuration, storage requirements and availability should be addressed when large number of changes are present for a given business data object.
8.9 Related Patterns
8.9.1 Event-Result History Pattern
Eriksson and Penker put forth the Business Event-Result History pattern which can be used “to track significant business events and then to connect these events to their results”
[58]. This pattern proposes keeping record of important business events. The authors believe that keeping records of business events is not only good from perspective of the historical record maintenance, but can also be advantageous for the business to have these records available in order to be able to make sound business decisions based on the information stored in those records. According to the authors the Business Event-Result
History pattern is applicable when modeling enterprise financial and resource planning systems.
8.10 Known Uses
Many COTS developers actively employ change history records in their applications, including SAP and Ariba. All configured changes in these applications are recorded, stored, and accessible, making these applications in compliance with various legal and corporate policies. Ariba applications use a similar approach in their data objects architecture [26].
Each data object that requires historical data tracking is assigned a vector (or a list) type
96 field to store all historical changes performed on the object. Ariba uses the concept of groups, which determine which attributes/fields on a given data object are tracked by historical records when changes are performed on attributes/fields.
8.11 Conclusions
The Change History Record Pattern provides the ability for subject matter experts to be selective about what history records are created, and more importantly to be able to configure these history records at runtime, without any code modifications. Both, the
Change History Record Pattern and the Business Data Object Versioning Pattern are not mutually exclusive, and can provide a complete audit trail and historical record keeping solution when combined together, which has been put in practice by Ariba in its
Downstream and Upstream applications [26], which allow its users to view the historical data of almost all business object, as well as any changes performed that have been performed on them.
97 9. THE PERMISSION BASED GRANULAR ACCESS CONTROL PATTERN
9.1 Introduction
Often enterprise applications data is highly compartmentalized, and can only be viewed or updated by a limited number of users or processes. The compartmentalization follows different business and legal rules, and varies from business to business. As the result, it is often not possible to predict the access requirements at design time. To address this problem, this chapter introduces the Permission Based Granular Access Control
Pattern, which can be used for providing a granular access to individual parts of the business object based on permissions.
9.2 Intent
A holistic access control to business objects is not sufficient as business objects are often comprised of multiple parts (attributes, operations) and may contain references to other business objects. Objects need to be designed with built-in support for granular access control. Consequently, we need a model which provides a granular control to business objects. In this pattern we present a basic approach for access control to objects, attributes, and operations in environments with a manageable number of subjects.
9.3 Example
Consider a simple customer business object, which consists of customer name, address, telephone, email, credit card info, and ordering history.
The customer data should only be available to individuals who need it and have the right (permission) to access it. Most of the time, only parts of the customer's data is needed
98 by those who access it. For example, a marketing department might need to see the customer's order history and contact info, but they should not be able to see the customer's credit card info. On the other hand, the ordering department should have access to the customer's credit card info in order to be able to validate it, but might not have a valid business reason to see the order history.
Access to the customer object and its attributes could be programmed into the object itself. This approach however is not desirable as it does not take into account constantly changing business conditions and processes. Any changes to the way customer object is accessed and controlled would require additional programming, which is often expensive and time consuming.
An alternative is to associate permissions with the customer object and its attributes/operations. Thus, for example, a marketing department permission can be associated with the customer business object, and its contact info and ordering history attributes. At the same time, an ordering department permission can be associated with the customer business object's credit card attribute. Both permissions are associated with the customer object, but each propagates to a different set of its attributes, thus each permission provides a granular access control over the customer object.
9.4 Context
You are designing a new business object and need a way to provide granular access control to the new object and its attributes/methods when your business object is deployed in your business application. The granular access control should be configurable and verifiable. Finally, the granular access to the business object should also provide control over the business object's attributes’ visibility (read access) and editability (update access).
99 9.5 Problem
Access to business objects, their attributes and operations must be given individually to subjects in a granular way. A subject may be given access to an object, but not to all its attributes and operations. Also, access to Read, Update, Copy, Create, and Delete must be differentiated – per attribute. The system must apply policies to deal with situations where a subject's rights for an object conflicts with the specific access rights of that subject for the required attribute/operation. For instance, a subject that has the Read access right for an object may lack the Read right for one or more of its attributes (i.e. credit card number on the customer object).
9.6 Solution
The design in Figure 26 assigns RightsDescriptor objects to a subject that describe specific access type allowed for the subject to individual objects, their attributes, and operations. An optional RightsDescriptor object is assigned to each business object, attribute, and operation to describe access rights that apply for all subjects that request access. The PermissionAuthority object validates access by matching the rights a subject has for a specific object, attribute, or operation with the (optional) rights descriptor owned by corresponding object, attribute, or operation. Validation must consider cases when a subject does not have access rights objects for the requested access and when the object (or attribute/operation) has no rights descriptor. Best practices (assigning least privileges) can be applied.
100
Figure 26: The class diagram for the Permission Based Granular Access Control pattern
All object level permissions are propagated by to the attributes and operations of the object. At the attribute and operation level, these permissions can be overridden by explicitly assigning another permission to an attribute or operation.
Figure 27 shows the sequence diagram granting access to business objects and their attributes/operations using the Permission Based Granular Access Control pattern. When subject requests a specific access to a business object, we first must verify that at least one of the permissions assigned to the subject matches the permission required to perform the access requested. If the object level match is successful, we can then perform granular matches on the objects individual attributes and operations. Ones these matches are performed, the subject will either get nothing (permission match failed on the requested
101 business object), or the subject will get access to the requested business object and those attributes/operations which passed granular permission match.
Figure 27: The sequence diagram for Permission Based Granular Access Control pattern
The following table provides an example of how permissions can be mapped to a business object and its attributes. We use “/” to denote object/attribute relationship. For example, a customer object with its attribute credit card would be denoted as
Customer/CreditCard.
Table 4: Permission based granular attribute access
Customer Object Customer/CreditCard Customer/Telephone
Attribute Attribute
Create Permission CustomerService
Read Permission CustomerService or Finance
Finance
102
Update Permission CustomerService or Finance
Finance
Delete Permission Finance
Copy Permission CustomerService
Above table shows permission mappings for Customer business object and some of its attributes. Subjects with CustomerService permission are granted access to create, read, update, and copy a Customer business object. However, only users with Finance permission can delete a Customer business object. Because Customer/Telephone field does not have any permissions assigned to it explicitly, it inherits the access permissions of the object itself. The attribute Customer/CreaditCard, on the other hand, can only be updated or viewed by subjects with Finance permission. Consequently, subjects with
CustomerService permission may enter customer credit card info at the time of Customer business object instance creation, but do not have access to update or view the credit card info subsequently.
Thus via granular assignment of permissions we can provide a granular access control to a business object as a whole, as well as to its individual attributes and operations.
9.7 Consequences
This pattern is suitable for systems where it is feasible to assign all subjects rights descriptors for objects they would access, including for their attributes and operations. For each object (and each of its attributes/operations) it only requires optional specification for just one rights descriptor that applies to all subjects. An advantage of this approach is that the permissions associated with the given business object access control do not have to be 103 determined at design or development time. Rather, the mapping of permissions to objects can be performed at run-time, after the business object has been deployed in the business application. Assigning permissions at run-time also enables us to group the business objects based on the permission(s) to which they are mapped. Because we can group permissions into roles, we can easily incorporate our configuration into an existing Role Based Access
Control (RBAC) type architectures.
9.8 Related Patterns and Frameworks
9.8.1 Discretionary Access Control (DAC)
The DAC pattern enforces access control based on user identities and the ownership of objects. The owner of an object may grant permission to another user to access the object, and the granted user may further delegate the per-mission to a third person. [3]
9.8.2 Mandatory Access Control (MAC)
The MAC pattern governs access based on the security level of subjects (e.g., users) and objects (e.g., data). Access to an object is granted only if the security levels of the subject and the object satisfy certain constraints. The MAC pattern is also known as multilevel security model and lattice-based access control. [3]
9.8.3 Role Based Access Control (RBAC)
The RBAC pattern enforces access control based on roles. A role is given a set of permissions, and the users assigned to the role acquires the permissions given to the role.
Since the RBAC pattern is based on roles which are in general fewer than the number of users, it is useful for managing a large number of users. [1]
104 9.8.4 Attribute-based Access Control (ABAC)
Attribute-based access control defines an access control architecture whereby access rights are granted to users through the use of policies which combine attributes together. The policies can then use any type of attributes (user attributes, resource attribute, etc...). Attributes can be compared to static values or to one another thus enabling relation- based access control. [4]
9.8.5 Semantic Access Control (SAC)
The Semantic Access control model was created in 2002. The fundamentals of this semantics-based access control model are the definition of several metadata models at different layers of the Semantic Web. Each component of SAC represents the semantic model of a component of the access control system. The semantic properties contained in the different metadata models are used for the specification of access control criteria, dynamic policy allocation, parameter instantiation and policy validation processes. [42]
9.9 Conclusions
The ability to provide a controlled access to specific parts of a business object is the integral part of most enterprise applications. Often different users may only see/update only certain parts of a business object. While other access patterns concentrate on object/actor access as a whole, the Permission Based Granular Access Control Pattern offers a way to provide granular access to individual parts of the business object itself. This approach can be a useful tool for providing the granular access through configuration, outside of design and development process. The pattern provides a practical approach for configuring and maintaining granular access to individual parts of a business object and its features,
105 providing a useful tool to system administrators and subject matter experts to do so at run- time, without the need to make any code changes.
106 10. THE MONEY OBJECT PATTERN
10.1 Introduction
Money is so prevalent in our lives that we often don’t think about its content or implementation from a computer science perspective. Whenever money functionality is needed in given application, it is often left up to designers and developers to implement this functionality. Within single currency systems the implementation of money is fairly simple, as just a monitory amount needs to be captured. However, with continuous and rapidly expending internationalization and globalization of enterprise applications, there is an ever increasing need to have access to reusable and extensible implementation of the
Money Object and Money API which supports multi-currency environments. The Money
Object Pattern addresses these shortcomings, and should be a useful tool when implementing money object in single as well as multi-currency enterprise applications.
10.2 Intent
In most enterprise applications supporting monetary activities, a base currency is necessary in order to correctly track the money coming in and the money going out (a.k.a.
P&L, Profit and Loss). For example, how does a company calculate P&L when it sells one million euros worth of services, and buys five hundred thousand dollars’ worth of office supplies? A Money object within a given application must not only contain an amount and a currency of transactions but also the base currency, the date, and the exchange rate used.
In this paper we introduce a language neutral money object pattern which can be applied in enterprise applications to address the ever growing internationalization and globalization
107 of businesses and their applications. Our money pattern must also be able to handle single currency transactions without any changes to the structure of the money object so that it can be used for both, single as well as multi-currency transactions.
Ontologies sometimes distinguish between two major categories of entities,
"continuants" (entities that have a duration, a start and an end), and "occurrents" (entities that have a timestamp, e.g. transactions). In this pattern we treat the money as an occurent, i.e. as a monetary transaction [43].
10.3 Example
A business headquartered in the United States needs to purchase a product from a
French company, which sells its products in Euros. Because the US based business is headquartered in the United States, its base currency is the US dollar, and its transactions are recorded in US dollars. The US based business profit and loss is also calculated in US dollars. Thus if a US based business purchases 100 Euros worth of goods from a French company, the cost of those goods needs to be recorded in US dollars in the US business’s purchasing and accounting systems. At the same time, we want to preserve the original amount (in Euros) for proper record keeping. Therefore the transaction must be recorded as follows:
Amount in foreign currency: 100.00 EUR
Amount in base currency: 130.00 USD
Exchange rate: 1 EUR = 1.3 USD
Transaction date: March 12, 2015
In the conventional/legacy application the storage and retrieval of above transaction is left to the individual developers/designers. Some might chose to store the foreign
108 currency amount in one database table, then derive the base amount using the exchange rate derived elsewhere based on the transaction date. While others might opt for storing the base and the foreign currency amounts together, then leave the exchange rate derivation based on the two values stored.
Our pattern eliminates the guess work which is often unnecessarily performed by the developers/designers when the requirements call for a money object implementation by presenting the money object as a single unit which stores the monetary related values in one place.
10.4 Context
As businesses are becoming more global, the support for multi-currency transactions within a given business application is becoming unavoidable. You are designing a new business application which will be used to process transactions in multiple currencies. Each transaction needs to be stored as a single unit, containing the necessary information about monetary data used for each transaction. It is assumed that this application will have a base currency, which will be set based on the country where the business running the new applications is headquartered.
10.5 Problem
How can one structure a general purpose monetary object that contains a unified and complete monetary data, and that can be used for both, single currency and multi-currency transactions?
10.6 Forces
A monetary transaction in single or multi-currency environment should be storable
and retrievable as a single object or unit. Naturally, we could implement it as a
109 container of disjoint values, but it would be much more beneficial from application
design and development perspective, as well as efficiency of the storage/retrieval
process if the money object is treated as a unit, and not as a container of disjoined
values.
A monetary object should be able to support single and multi-currency transactions.
One could argue for the benefits and of a perceived simplicity of the single currency
money object in a single currency system. But a conversion or an upgrade of such
system to a multi-currency architecture, if one is ever needed, would be a daunting
process. Therefore there should not be a separate or different implementation for
single or multi-currency transactions. Consequently the same money object can be
implemented without any modifications in applications supporting single or multi-
currency business processes.
A monetary object for a single or multi-currency unit needs to support arithmetic
operations, such as addition, subtraction, multiplication, and division. Granted,
these calculations can be implemented outside of the money object, but without
these basic operations, the money object would not provide the full set of benefits
to application designers and developers.
A monetary object for multi-currency unit should store the date and the exchange
rate of the transaction. Although the exchange rate can be derived externally for the
given date, adding both the exchange rate and the transaction date to the monetary
object provides transaction record as well as the means of performing mathematical
calculations between monetary objects with different currencies.
110 Ability to display a monetary amount in base or actual/transaction currency. If
transactions were performed in multi-currency, we could always display them in
one currency or the other, but it would be beneficial from a usability perspective
for end users to be able to see both amounts if they so desired, or even toggle
between one or the other.
When needed, a monetary object should be capable of supporting the Net Present
Value (NPV) when performing arithmetic calculations. NPV calculations can be
complex, and are generally a subject of discussion in themselves, but it would add
to the money object’s usefulness if it could support NPV in its arithmetic
calculations.
10.7 Solution
Our solution is the Money Object Pattern which stores the amount in two currencies, and supports various arithmetic operations.
The Money object contains the following attributes:
Base currency
Amount in base currency
Transaction currency
Amount in transaction currency
Date of transaction (more precisely the date used to derive the exchange rate)
Exchange rate (always 1 when single currency is used as there’s nothing to convert
the single currency to)
The base currency is the “home” currency of the application. Each application must have a base (or home) currency declared. For example, a business that is registered in the
111 United States would have US dollar as the base (or home) currency because its tax liabilities are expected to be in US Dollars. All transactions and book keeping are expected to be performed in the base (or home) currency. If implementing in Java, java.util.Currency would be the currency type.
The amount in base currency is the amount of transaction after it is converted from the actual currency to base currency, using the value of the exchange rate. Thus a product purchased for 100 euros (EUR), would be recorded as 130 dollars (USD) in base currency, using the exchange rate of 1 EUR = 1.30 USD. The data type for amount in base currency is Double, as many currencies have fractions or precision (i.e. 2 decimal places to represent the cents amount in US dollar, or 0 for Italian Lira), however the type can also be different, depending on the language implementation, For example, in Java a friendlier type to use would be java.math.BigDecimal as it provides public methods for rounding and precision setting. Note: the precision of a currency is generally defined in the Currency object
(java.util.Currency in the case of Java), and not the Money object.
Transaction currency is the currency that was used to purchase goods or services. In our money object it can be (and often is) the same as the base currency if the goods or services were purchased using the same currency as the base currency of the system/application. If implementing in Java, java.util.Currency would be the currency type.
Amount in transaction currency is the value of purchase or transaction in the currency requested by the selling party. In above example, the amount in transaction currency would be 100 euros. The data type and fraction derivation logic is similar to that described for the base amount about, except a different currency would be used to perform the derivation.
112 Date of transaction is used to store the date and time of the transaction, which in turn can be used to determine the exchange rate. The time zone of the transaction date is application dependent. Some applications are configured with the time zone of the business header quarters, while others might use a GMT time zone to have a single point of reference, yet others might use strictly local time. The date type is also implementation dependent. For example, in Java one can use a java.util.Date or java.util.Calendar.
Exchange rate is the value used to convert from transaction currency to base currency.
Note: when transaction currency and base currency are the same, then exchange rate is 1.
10.7.1 Implementation Details
The following is an example of the Money class implementation in Java.
113 Figure 28: The Money Object UML class diagram
Figure 28 shows the class diagram of the Money object. For simplicity and clarity, we assume that all null checking has been performed by the Money object constructor.
Also for simplicity, we avoid the use of Factory classes, which would be preferable in the actual implementation of the Money class.
There could be numerous constructors to instantiate a Money object, so we’ll provide a few examples of those we feel would be most often used. Also, the base currency is generally set/configured as part of application-specific properties, and would not normally be passed as a parameter to the Money constructor. However, in the examples below we use it as a parameter for the sake of simplicity, and to improve the flexibility of the constructors. In a real world application, we would use (in Java)
114 Currency.getInstance(Locale.getDefault()), or some other API to obtain a base currency of the application. class Money...
//In cases where exchange rate is known…
public Money (BigDecimal amount, Currency currency
, Currency baseCurrency, bigDecimal exchangeRate) {
this.amount = amount;
this.currency = currency;
this.baseCurrency = baseCurrency;
this.amountInBaseCurrency = amount*exchangeRate;
this.exchangeRate = exchangeRate;
this.transactionDate = new Date(Date.getTime());
}
//In cases where both, the exchange rate and date, are known…
public Money (BigDecimal amount, Currency currency, Currency baseCurrency
, BigDecimal exchangeRate, Date date) {
this.amount = amount;
this.currency = currency;
this.exchangeRate = exchangeRate;
this.amountInBaseCurrency = amount*exchangeRate;
this.baseCurrency = baseCurrency;
this.transactionDate = date;
}
115 //In cases where we are dealing with single currency transaction
//(i.e. base and transaction currencies are the same)…
public Money (BigDecimal amount) {
this.amount = amount;
this.currency = getBaseCurrency();
this.exchangeRate = 1;
this.amountInBaseCurrency = amount;
this.baseCurrency = getBaseCurrency();
this.transactionDate = new Date(Date.getTime());
}
//If our application has base currency configured and has access to the latest exchange rates,
//then the ultimate constructor would be as follows…
public Money (BigDecimal amount, Currency currency) {
Date date = new Date(Date.getTime());
this.amount = amount;
this.currency = currency;
this.exchangeRate = getExchangerate(currency, getBaseCurrency(), date);
this.amountInBaseCurrency = amount*exchangeRate;
this.baseCurrency = getBaseCurrency();
this.transactionDate = date;
}
116 //In cases where we can use some sort of web service to obtain the currency exchange rate
//based on the date…
public Money (BigDecimal amount, Currency currency, Currency baseCurrency,
Date date) {
this.amount = amount;
this.currency = currency;
this.exchangeRate = getExchangerate(currency, baseCurrency, date);
this.amountInBaseCurrency = amount*exchangeRate;
this.baseCurrency = baseCurrency;
this.transactionDate = date;
}
Note: getExchangerate() is assumed to be some external function (e.g. implemented by a web services) which will return the exchange rate between the 2 currencies specified and the requested date.
Once we instantiate the Money object using one of the above constructors, we can now take advantage of its public method to perform various operations on this object.
One of the main advantages of the Money object is that the arithmetic operations can be performed on Money objects with different currencies. This is easily accomplished by the use of base amount value of the two Money objects. Since the arithmetic operation is performed within a specific application, which we assume is configured with a specific locale, we can assume that the base currency of our Money objects is the same as it is
117 derived from the locale of the application. Thus the use of the base amount is ideal for performing arithmetic operations on the Money objects.
Add and subtract are very powerful operations offered by the Money object. In a real life scenario, a business could have thousands of transactions in many different currencies. These transactions can be easily summed up simply by summing up the base amounts of all transactions.
For simplicity and clarity, we assume that all null checking has been performed by the Money object constructor. class Money...
//add one money object to another
public Money add (Money money) {
if (money != null) {
this.baseAmount = this.baseAmount + money.baseAmount;
this.amount = this.baseAmount * this.exchangeRate;
}
return this;
}
//add one money object to another
public Money subtract (Money money) {
if (money != null) {
this.baseAmount = this.baseAmount - money.baseAmount;
this.amount = this.baseAmount * this.exchangeRate;
}
118 return this;
}
//multiply Money by some number…
public Money multiply (Double arg) {
this.baseAmount = this.baseAmount * arg;
this.amount = this.amount * arg;
return this;
}
//divide Money by some number. Note, we are not checking for 0 and are letting application
//environment handle division by 0.
public Money divide (Double arg) {
return multiply(1/arg);
}
//compare Money objects
public static int compareTo (Money money1, Money money2) {
money1.baseAmount.compareTo(money2.baseAmount);
}
Some helper methods to round out the base features of the Money object.
class Money...
//get base currency of the application
//this is usually application/implementation specific and can be accomplished
//in many different ways. Here we give example of one approach.
119 public static Currency getBaseCurrency () {
return Currency.getInstance(Locale.getDefault());
}
//ultimately a Money object would need to be displayed to the end users,
//and toString is just one possible way to do it in a predefined format.
public String toString () {
return this.currency.getSymbol()
+ this.amount.setScale(this.currency.getDefaultFractionDigits())
+ this.currency. getCurrencyCode();
}
Numeric values, and especially money amounts, are often displayed differently in different parts of the world. For example, in North America a period is used to indicate the beginning of decimal numbers. Elsewhere, a comma is the accepted decimal numbers separator. The Money object can thus format and display the amount based on specific locale if the view layer ever requires it.
public String toString (Locale local) {
//return locale-specific string representation of this money object.
}
We believe that above methods provide sufficient set of functionalities to make the
Money object useful in just about any application.
10.8 Consequences
The Money Object Pattern addresses a number of shortcomings when only an amount and a currency are used to represent a monetary unit. In this pattern we introduced the
120 concept of base amount and base currency, which enables us to easily perform arithmetic operation on a money object, as well as maintain a single point of reference, even in a multi-currency system.
In addition, the Money object supports single and multi-currency application configuration/setup, and can thereby be deployed in just about any environment.
As with any currency exchanges, the exchange rate and exchange date play a crucial role in determining the relationship between different currencies. We addressed this relationship by making the exchange rate and exchange date an integral part of the Money
Object Pattern.
The Money Object Pattern also provides great flexibility when it comes to presentation of the Money object. By maintaining the base and actual currency information within the object itself, we are able to display the object in different currencies, depending on the needs of the application employing the Money object.
This pattern does not take into account the NPV (Net Present Value) when describing arithmetic operations of the money object. The NPV determines what interest rate to apply, and is not necessarily the interest rate set by Federal Reserve for US dollars (or a central bank of another country for its home currency). Companies, industries and even specific projects can have their own internal interest rates. All interest rates can change over time.
Consequently, there is a factor of uncertainty when calculating the net present value. Due to a multitude of complex considerations related to NPV, a more elegant solution is to let an external component or service handle the NPV calculations. For that reason, the NPV, as it relates to the money object, is assumed to be calculated outside of the money object
121 itself. Instead, the money object can, when needed, take the NPV into account when arithmetic calculations are performed by calling an external component or service.
10.9 Known uses
Most major Commercial Off The Shelf (COTS) Enterprise Resource Planning (ERP) developers such as Oracle and SAP, to name the two biggest, have their own custom implementations of handling the money and multi-currency data. Ariba Inc. [26], which has recently been acquired by SAP [44] uses a custom implementation of the Money object which is very similar to that described in this paper. A good part of the pattern which we propose in this paper is the result of our study of Ariba’s Money object implementation.
Ariba’s Money object also uses base currency, actual currency, the date, and exchange rate to record the value of a transaction.
10.10 Related Patterns and Frameworks
10.10.1 Martin Fowler’s Money Object
Martin Fowler introduced the concept of a Money object in his book “Patterns of
Enterprise Application Architecture” [6], in which he proposed a monetary unit in the form of an object. Our pattern extends on his original idea that, at the very least, the money object needs to have an amount and currency, and needs to be able to handle certain arithmetic operations.
10.10.2 Money Class, Microsoft .NET
Microsoft introduced the Money Class to its flagship .NET framework [45]. The
Money Class in Microsoft .NET is more of a data object and does not currently support arithmetic operations.
122 10.10.3 JSR 354 (Money & Currency) - Specification
The Java framework is introducing the Money support in its upcoming release 9 [46].
The proposed specification is very detailed, and includes a very large number of new objects and interfaces to support Money & Currency features in release 9. Some of the concepts such as monetary object and various arithmetic operations between two monetary objects with different currencies are covered in this pattern, and are similar to those introduced in the proposed JSR specification. The JSR specification introduces the javax.money.MonetaryAmount interface, which provides public methods for performing arithmetic operation on a money object. The main difference between the pattern in this paper and the JSR 354 is that the latter is a detailed specification of how the Money &
Currency will be implemented in Java, and is less of a pattern. As such, it is much more complex than the pattern introduced in this paper.
10.11 Conclusions
The Money Object Pattern offers a simple, unified and flexible solution for handling money type data in just about any system or application. The pattern supports single and multi-currency environments, as well as arithmetic operations on money type data. This pattern also provides alternatives for money data formatting and presentation, making it an ideal solution for User Interface and Reporting implementations. The pattern has been successfully applied by Ariba in all of its applications, including Ariba Supplier Network
(ASN) [26], which handles transactions in every currency currently in use around the world.
123 11. PATTERNS AND XML
The improvements introduced in XML Schema 1.1 Specification [47] offer the capability to enforce the concept of Business Object Validity Constraint introduced in
Chapter 4 in a platform and language independent manner. Building on the patterns presented in this dissertation, and applying XML-based technologies, it is possible to develop the concept of the Self-validating Business Object. With the XML Schema 1.1
[47], it is now possible to extend business rules and business logic as part of the XML
Schema declaration.
XML Schema already provides the ability to add limited business rules to the schema document via datatypes. For example, in XSD it is possible to define Date or Integer type element or attribute, and enforce the datatypes through XML document validation. But with the introduction of Assertions, it is now possible to conduct validations within a given
XML document based on different criteria and logic, not just datatype checking.
Using the conventional wisdom, most designers and developers incorporate business rules and business logic using well established programming languages such as Java,
JavaScript, C#, C++, and others. But if some or all of the business rules and logic can be moved to the XML Schema Definition, then it would be possible maintain all of the business object’s metadata in one place, allowing for less reliance on software and hardware dependencies.
This can be accomplished by employing XPath and Assertions. Assertions allow XML
Schema writers to add constraints and validations using XPath 2.0 notation. So the
124 Validity, Editability, and Visibility constraints introduced in Chapter 3 as part of the
Business Object Pattern can be incorporated into the XML Schema file representing a given business object.
Following is an example of implementing a validity constraint as part of the XSD file.
The above validity constraint requires that the currency on the document or business object being validated must be US Dollar. If this is not the case, an assertion will be raised indicating to the caller that an error has occurred. This type of validation can be applied to user interfaces and web services as part of the XML Schema file definition, and does not need to be coded in another language such as Java or C++.
Using XLST we can define logic for the Visibility constraint as well. For example, if the business rule states that only the HR department should have access to employee’s social security number, then we can add and XLST instruction to remove the social security number field when a business object or XML document is presented to the calling program.
This visibility can be applied to user interface presentation, as well as web services integration.
There are a number of advantages to applying business rules and business logic as part of the XML Schema Definition file and not code them in another language.
125 Any XML schema can be extended with additional self-validating
rules/constraints instead of modifying the current schema. Schemas are object
oriented in nature and can be extended to add new elements and attributes. The
constraints can therefore be added to existing schemas in the same fashion.
Constraints can be applied to web services. Constraints do not have to be user
interface specific and can be applicable to web services also. For example, when a
web service processes a request, it can validate the incoming data against the
particular schema to ensure that all elements comply with the constraint rules
found in that schema.
Self-validating rules/constraints can be interpreted with XSLT, utilizing XQuery,
XPath, and other existing XML technologies. The advantages of these XML
technologies are that they are software and platform independent.
A self-validating data object does not require any additional code because all
logic is stored as part of the object’s XML schema used to define the object,
which also makes it an open source implementation.
We believe pattern implementation in business object’s XML Schema has a promising potential and further research in this area is certainly desired, as the benefits of self-validating business objects presented in this chapter could offer great benefits and opportunities in this area.
126 12. CONCLUSIONS AND FUTURE WORK
Enterprise applications are complex systems which are built and deployed on many different platforms, across multiple corporate networks. They require high degree of availability, often 24x7, are highly data intensive in nature, and must support a large number of concurrent users. Consequently, building enterprise applications is a complex and often difficult process, which requires high level of knowledge in various aspects of
Information Technology, as well as business subject matter expertise.
One of the ways to address the complexities of enterprise application design and development is to employ proven patterns which provide proven solutions to common problems. The contribution of this dissertation is the introduction of the seven patterns which provide solutions to some of the common problems faced by enterprise application designers and developers.
The Business Object Pattern introduces a number of concepts unique to business applications. First, the pattern presents the dynamic vs static nature of business objects, and the different approaches in which each can be designed and developed. Second, the pattern introduces the concept of business object constraints. There are three constraints included in the pattern, each addressing a specific area of business object integrity. The validity constraint certifies that any changes performed on the business object are valid and do not violate any business rules associated with the given business object. The visibility constraint provides security by ensuring that the visibility of any business object fields is compliant with business rules and regulations. Finally the editability constraint is employed
127 to prevent unauthorized changes to data within a business object. Third, the business object workflow ensures that the business objects undergo the various states dictated by business rules.
The Business Object Life Cycle Pattern introduces the concept of multiple stages which comprise a business object’s life cycle. During these stages the business objects undergo various checks, validations, and verifications which ensure the integrity of these objects. Employing this pattern can also improve business objects concurrency and synchronization requirements, which are often different at each stage, by allowing for a granular implementation at each stage.
The Simple Change History Pattern addresses the problem of recording changes to business data in constrictive environments, where allowable changes to the code and/or data structure are very limited or prohibitive. Although the historical data put forth by this pattern is very limited, it may be sufficient in many circumstances.
The Business Data Object Versioning Pattern provides a unique solution by introducing a concept of business object versioning. The pattern defines a method for preservation of the data while the changes to a given business data object are ongoing, without making these changes available to the application until all approvals and validations are completed.
The Change History Record Pattern offers the most flexible approach for audit trail and change history preservation. Unlike the previous two change history patterns, this pattern defines a configurable approach to audit trail. The benefit of being able to configure the audit trail details at runtime is obvious, as designers and developers often may not have the subject matter expertise to determine what should be included in the historical
128 information at design time. Another advantage of the configurable audit trail is that business and economic conditions often change, which in may result in the need to make changes to the audit process. Finally, audit trail requirements may differ from country to country, and from business to business, in which case the configurable audit trail would be the preferred option.
The three change history patterns presented in this dissertation build on each other’s strengths and together provide a design approach for building business data objects audit trail capabilities. The aim was to organize the three patterns in a language and data storage neutral approach. Continuously changing political, economic and legal conditions reinforce the need in improvements in audit trail and change history preservation approaches. It is hoped that the three patterns presented make a meaningful contribution to this important, yet often overlooked area of enterprise application design and development.
The Permission Based Granular Access Control Pattern provides a clear, generic and extendible design-time approach to securing access to business objects and their entities. It allows for use of as many or as granular permissions to control access to various parts of business data in a declarative way.
It is important to note that the permissions are independent of the access control model used. The content of the permission-specific attributes can be adapted to each access control model. For instance, in a Mandatory AC model the content of a permission attribute would be the security level, in the Discretionary AC model it would point to specific users, in RBAC it would contain roles, and finally in the Semantic AC model, it would point to
AC policies.
129 The Money Object Pattern expends on the concept of a business object by defining
Money as a specific type of business object. The pattern is most useful in the enterprise applications which require multi-currency support, however the pattern also supports a single currency configuration. This pattern offers a simple and flexible solution for handling money type data within enterprise applications. In addition to supporting single and multi-currency environments, the pattern also addresses arithmetic operations on the data of type money. Finally, by providing alternatives for formatting and presentation, the pattern also offers a solution ideal solution for User Interface and Reporting implementations.
For future work, it would be of great interest to address the specifics of currency conversion rates, their structure, and derivation, ultimately deriving a new pattern that would complement the Money Object Pattern introduced in this paper. We believe that a new pattern addressing NPV (Net Present Value) calculations as part of the Money object could provide significant benefit when designing enterprise level applications.
Further research is also needed to see how the patterns would work with more complex models, those including tens or hundreds of objects and workflows. Also of great interest is the transition to design/implementation model, as well as opportunities for code generation. The available storage options and how they can be incorporated into the pattern are also of significant interest, especially when taking into account the recent advances in and popularity of NoSql databases.
The concept of Self Validating Business Object introduced in Chapter 11 has a great potential, and further research in this area may prove to be beneficial contribution to the application of patterns in XML Schemas defining business objects.
130 Finally, the delivery and presentation of business objects to the end users from a platform-neutral specification is of great interest as the wide range of the devices used by businesses has grown exponentially over the years. The availability of business applications is no longer expected to be on desktops and laptops only. New avenues for using these patterns should be explored for pervasive computing and mobile peer-to-peer computing applications.
131 13. REFERENCES
[1] D. Ferraiolo, D. R. Kuhn, and R. Chandramouli. Role-Based Access Control. Artech House, 2003.
[2] Yagüe, M. I., & Maña, A. Semantic access control model: A formal specification. In Computer Security, ESORICS 2005 (pp. 24-43). Springer Berlin Heidelberg.
[3] Kim, D. K., Mehta, P., & Gokhale, P., Describing access control models as design patterns using roles. In Proceedings of the 2006 conference on Pattern languages of programs (p. 11). ACM.
[4] Yuan, E., & Tong, J. Attributed based access control (ABAC) for web services, ICWS 2005. Proceedings. 2005 IEEE International Conference on. IEEE.
[5] Fowler M. Analysis Patterns: Reusable Object Models, Addison-Wesley Longman, 1997.
[6] Fowler M., Patterns of Enterprise Application Architecture, Addison Wesley, 2002.
[7] Krafzig, Dirk, Karl Banke, and Dirk Slama. Enterprise SOA: service-oriented architecture best practices. Prentice Hall Professional, 2005.
[8] Fielding, Roy Thomas, Chapter 5: Representational State Transfer (REST), Architectural Styles and the Design of Network-based Software Architectures (Ph.D.). University of California, Irvine, 2000.
[9] Feng, Xinyang, Jianjing Shen, and Ying Fan., REST: An alternative to RPC for Web services architecture., Future Information Networks, 2009. ICFIN 2009. First International Conference on, pp. 7-10. IEEE, 2009.
[10] Weerawarana, Sanjiva, Francisco Curbera, Frank Leymann, Tony Storey, and Donald F. Ferguson. Web services platform architecture: SOAP, WSDL, WS-policy, WS- addressing, WS-BPEL, WS-reliable messaging and more. Prentice Hall PTR, 2005.
[11] SOAP, The Simple Object Access Protocol, online at https://www.w3.org/TR/2007/REC-soap12-testcollection-20070427/.
[12] Keen Martin, Amit Acharya, Susan Bishop, Alan Hopkins, Sven Milinski, Chris Nott, Rick Robinson, Jonathan Adams, and Paul Verschueren, Patterns: Implementing an SOA using an enterprise service bus, IBM Redbooks 336 (2004),
132 http://ck20.com/MQ/WBIMB/sg246346%20Implementing%20SOA%20using%20ESB.p df.
[13] BPEL, The Web Services Business Process Execution Language, online at http://docs.oasis-open.org/wsbpel/2.0/OS/wsbpel-v2.0-OS.html.
[14] Chappell, David. Enterprise service bus, O'Reilly Media, Inc., 2004. https://www.thali.ch/files/Shop/Documents/013254_Probekapitel.pdf.
[15] IBM WebSphere, http://www-03.ibm.com/software/products/en/appserv-was.
[16] Microsoft Biztalk, online at https://www.microsoft.com/en-us/cloud-platform/biztalk.
[17] Oracle Enterprise Service Bus, online at http://www.oracle.com/technetwork/middleware/service-bus/overview/index.html.
[18] Hohpe, Gregor, and Bobby Woolf. Enterprise integration patterns: Designing, building, and deploying messaging solutions. Addison-Wesley Professional, 2004.
[19] Zimmermann, Olaf, Thomas Gschwind, Jochen Küster, Frank Leymann, and Nelly Schuster, Reusable architectural decision models for enterprise application development, In International Conference on the Quality of Software Architectures, pp. 15-32. Springer Berlin Heidelberg, 2007, http://ozimmer.de/download/QOSA2007_4880_0015_0032.pdf.
[20] James Lewis and Martin Fowler, Microservices, a definition of this new architectural term, online at https://martinfowler.com/articles/microservices.html.
[21] Dragoni, Nicola, Saverio Giallorenzo, Alberto Lluch Lafuente, Manuel Mazzara, Fabrizio Montesi, Ruslan Mustafin, and Larisa Safina, Microservices: yesterday, today, and tomorrow, arXiv preprint arXiv:1606.04036 (2016), https://arxiv.org/pdf/1606.04036.pdf.
[22] Newman, Sam., Building microservices: designing fine-grained systems, O'Reilly Media, Inc., 2015.
[23] Richardson, Chris., Microservice Patterns, Manning Publications, 2017.
[24] Fernandez E.B.,Yuan X.Y., Securing analysis patterns, Procs. of the 45th ACM Southeast Conference (ACMSE 2007), March 23-24, 2007, Winston-Salem, North Carolina.
[25] Wong K. and Bass D., SAP to Acquire Ariba for $4.3 Billion in Push Into Cloud. Bloomberg, May 23, 2012.
[26] Ariba Inc., 2013. http://www.ariba.com.
133 [27] Bohrer K., Johnson V., Nilsson A., Rubin B., The San Francisco Project: An Object- Oriented Framework Approach to Building Business Applications, IBM.
[28] Chang K.Y., Chen L.S., Lai C.K., Document-View-Presentation Pattern, Department of Electrical Engineering, National Cheng-Kung University, Taiwan., 1999.
[29] Buschmann, F., R. Meunier, H. Rohnert, P. Sommerlad, and M. Stal. Pattern-Oriented Software Architecture: A System Of Patterns. West Sussex, England: John Wiley & Sons Ltd., 1996.
[30] SmartClient Enterprise Edition, Isomorphic Software, 2010. http://smartclient.com/product/smartclient.jsp.
[31] Adobe Flex, Adobe Systems Incorporated, 2013. http://www.adobe.com/products/flex.html?promoid=DINEZ.
[32] Sencha GTX, Sencha Inc., 2013. http://www.sencha.com/products/gxt.
[33] Vaadin UI Components, Vaadin Server & Client, Vaadin Ltd., 2012. https://vaadin.com/home.
[34] Icefaces, ICEsoft Technologies Inc., 2013. http://www.icesoft.org/java/home.jsf.
[35] FPDS-NG, Federal Procurement Data System - Next Generation, 2013. https://www.fpdsng.com.
[36] A Guide To The Sarbanes-Oxley Act, The Sarbanes-Oxley Act of 2002, http://www.soxlaw.com/.
[37] Glenn E. Krasner and Stephen T. Pope, A cookbook for using the model-view controller user interface paradigm in Smalltalk-80, Journal of Object-Oriented Programming, Volume 1 Issue 3, Aug./Sept. 1988, Pages 26 – 49.
[38] Buschmann F., Henney K., Schimdt D., Pattern-oriented Software Architecture: On Patterns and Pattern Language (Vol. 5) John Wiley & Sons., 2007.
[39] W.M.P. van der Aalst, A.H.M. ter Hofstede, B. Kiepuszewski, and A.P. Barros, 2004, Workflow Patterns, Department of Technology Management, Eindhoven University of Technology.
[40] Rubis R., Cardei I., The Dynamic Business Object Pattern, 20th Conference on Pattern Languages of Programs, Monticello, IL, October 2013
[41] Oracle Applications Technical Reference Manuals, Oracle Technology Network, Oracle Corp. [online] http://www.oracle.com/technetwork/apps-tech/index.html (Accessed 15 January, 2017).
134 [42] Semantic Access Control, A Semantics-based Access Control Model for Open and Distributed Environments, http://www.lcc.uma.es/~yague/Semantics- basedAccessControl.html.
[43] Sowa, John F., Knowledge Representation: Logical, Philosophical, and Computational Foundations, Brooks / Cole, 1999.
[44] ABAP and BAPI, SAP AG, 2013. http://scn.sap.com/community/abap.
[45] Money Class, Dynamics CRM 2015, Microsoft .NET Library, Microsoft, https://msdn.microsoft.com/en-us/library/microsoft.xrm.sdk.money(v=crm.7).aspx.
[46] Java Community Process, JSR 354: Money and Currency API, https://jcp.org/en/jsr/detail?id=354.
[47] Extensible Markup Language (XML) 1.1 (Second Edition), W3C Recommendation 16 August 2006, edited in place 29 September 2006, https://www.w3.org/TR/2006/REC- xml11-20060816/.
[48] Adams J., Koushik S., Vasudeva G., Calambos G. (2002) Patterns for e-business: A Strategy for Reuse, IBM Press.
[49] Alexander C., A pattern language, Oxford University Press, New York, 1997.
[50] Beedle M., Devos M., Sharon Y., Schwaber K., Sutherland J., SCRUM: An extension pattern language for hyperproductive software development, Pattern languages of program design, 4, pp. pp. 637-651., 1999.
[51] Buckl S., Matthes F., Monahov I., Roth S., Schulz C., Schweda C.M., 2012. Enterprise Architecture Management Patterns for Company-wide Access Views on Business Objects, ACM Transactions on Applied Perception, Vol. 2, No. 3, Article 1, Publication date: May 2012.
[52] Business Object DTF, Common Business Objects, OMG Document bom/97-12-04, 1997.
[53] Columbuss, Louis, 2013 ERP Market Share Update: SAP Solidifies Market Leadership. Forbes., May 12, 2013.
[54] Coplien J. O., Software design patterns: Common questions and answers, The Patterns Handbook: Techniques, Strategies, and Applications, Cambridge University Press, pp. 311-320., 1998.
[55] Daum B., Modeling Business Objecs with XML Schema, Morgan Kaufmann Publishers, 2003.
135 [56] Fernandez E. B., Pan R., A Pattern Language for Security Models. In Proceedings of the 8th Conference on Pattern Language of Programs (PloP), Monticello, IL, 2001.
[57] Fernandez E.B., Yuan X.Y., Semantic Analysis Patterns, Procs. 19th Int. Conf. on Conceptual Modeling, ER2000, Salt Lake City, UT, October 2000. Springer Lecture Notes in Computer Science, Volume LNCS 1920, 183-195.
[58] Eriksson H.-E., Penker M., Business Modeling with UML: Business Patterns at Work, OMG Press / Wiley Computer Publishing, 2000.
[59] Fernandez-Buglioni E., Security patterns in practice: designing secure architectures using software patterns John Wiley & Sons, 2013.
[60] Ferreira H.S., Correia F.F., Welicki L., Patterns for Data and Metadata Evolution in Adaptive Object-Models. Paper presented at the 15th Conference on Pattern Languages of Programs (PLoP). 18-20 October, 2008. Nashville, TN, USA.
[61] Fortis A., Fortis F., Workflow Patterns in Process Modeling, European Conference on Computer Science & Applications, 2009.
[62] Gamma E., Helm R., Johnson R., Vlissides J., Design Patterns: Elements of Reusable Object Oriented Software, Addison-Wesley, 1994.
[63] Jianrui Wang and Akhil Kumar, A Framework for Document-Driven Workflow Systems, Smeal College of Business, Pennsylvania State University, 2005.
[64] Krasner G.E. and Pope S.T., A cookbook for using the model-view controller user interface paradigm in Smalltalk-80. Journal of Object-Oriented Programming, Volume 1 Issue 3 (Aug./Sept. 1988), 26-49.
[65] Laakso Sari A. Collection of User Interface Design Patterns, University of Helsinki, Dept. of Computer Science, 2003.
[66] Leymann C. F. F., Retter R., Schupeck W., Arbitter P., Cloud computing patterns, Springer, pp. 978-3, 2014.
[67] McGrath W., Bowman B., McCallum D., Hincapié-Ramos J.D., Elmqvist N., Irani P., Branch-explore-merge: facilitating real-time revision control in collaborative visual exploration, Proceedings of the 2012 ACM international conference on Interactive tabletops and surfaces.
[68] Nick Russell, Arthur H.M. ter Hofstede, David Edmond, W.M.P. van der Aalst, Centre for Information Technology Innovation, Queensland University of Technology, Department of Technology Management, Eindhoven University of Technology, 2005.
136 [69] Phillips S., Sillito J., Walker R., Branching and merging: an investigation into current version control practices, Proceedings of the 4th International Workshop on Cooperative and Human Aspects of Software Engineering, 21 May, 2011, Waikiki, Honolulu, HI, USA.
[70] Russell, N. C., Hofstede, ter, A. H. M., Aalst, van der, W. M. P., & Mulyar, N. A., Workflow control-flow patterns: a revised view BPM reports, Vol. 0622 Gamma, E., Design patterns: elements of reusable object-oriented software. Pearson Education, 2006.
[71] Schmidt D. C. Using design patterns to develop reusable object-oriented communication software, Communications of the ACM, 38(10), pp. 65-74., 1995.
[72] Schmidt D. C., O’Ryan C. Patterns and performance of distributed real-time and embedded publisher/subscriber architectures, Journal of Systems and Software, 66(3), pp. 213-223., 2003.
[73] Sridaran R., Padmavathi G., Iyakutti K., A Survey of Design Pattern Based Web Applications, Journal of Object Technology, Vol. 8, No. 2, March-April 2009.
[74] Thomas C. W., The Rise and Fall of Enron, Journal of Accountancy, April 1, 2002.
[75] W.M.P. van der Aalst1, A.H.M. ter Hofstede, B. Kiepuszewski, and A.P. Barros, 2005, Advanced Workflow Patterns, Department of Technology Management, Eindhoven University of Technology.
[76] Yoshioka N., Washizaki H., & Maruyama K. A survey on security patterns, Progress in Informatics, 5(5), pp. 35-47., 2008.
[77] .NET, Microsoft, 2013. http://www.microsoft.com/net.
[78] Ariba Spend Management Documentation, Approval Rules Guide, Release 9r1, July 2008.
[79] J2EE, Oracle Corporation, 2013. http://www.oracle.com/technetwork/java/javaee/overview/index.html.
[80] Java 1.4.2 API Documentation, Oracle, https://docs.oracle.com/javase/1.4.2/docs/api/.
[81] Spring Framework, GoPivotal, Inc., 2013, http://www.springsource.org/spring- framework.
[82] McQuillan, John M.; David C. Walden, Some considerations for a high performance message-based interprocess communication system, Proceedings of the 1975 ACM SIGCOMM/SIGOPS workshop on Interprocess communications. ACM Press.
[83] WSDL, The Web Services Description Language, online at https://www.w3.org/TR/wsdl.
137 [84] Adams J., Koushik S., Galambos G., Vasudeva G., Patterns for e-business: A Strategy for Reuse, IBM Press, 2001.
[85] Appleton B., Patterns and Software: Essential Concepts and Terminology, 2000, http://www.bradapp.com/docs/patterns-intro.html.
[86] The Unified Modeling Language Specifiction, Object Management Group, http://www.omg.org/spec/UML, 2017.
[87] The World Wide Web Consortium, XML Path Language (XPath) 3.1, https://www.w3.org/TR/xpath-31/.
[88] The World Wide Web Consortium, XML Schema Definition Language (XSD) 1.1 Part 1: Structures, https://www.w3.org/TR/xmlschema11-1/.
[89] The World Wide Web Consortium, XML Schema Definition Language (XSD) 1.1 Part 2: Datatypes, https://www.w3.org/TR/xmlschema11-2/.
[90] The World Wide Web Consortium, XSL Transformations (XSLT) Version 3.0, https://www.w3.org/TR/xslt-30/.
[91] Walmsley P., Definitive XML Schema, Prentice Hall, 2013.
[92] Rubis R., Cardei I., Permission Based Granular Access Control Pattern, 21st Conference on Pattern Languages of Programs, Monticello, IL, September 2014.
[93] Rubis R., Cardei I., Business Object Life Cycle Pattern, 21st Conference on Pattern Languages of Programs, Monticello, IL, September 2014.
[94] Rubis R., Cardei I., The Business Data Object Versioning and Change History Patterns, 22nd Conference on Pattern Languages of Programs, Pittsburgh, PA, October 2015.
[95] Rubis R., Cardei I., The Money Object Pattern, 22nd Conference on Pattern Languages of Programs, Pittsburgh, PA, October 2015.
138