Communications of the ACM
Home/Magazine Archive/June 2007 (Vol. 50, No. 6)/Design Patterns For Managing Product Life Cycle Information/Full Text
Communications of the ACM
Design Patterns For Managing Product Life Cycle Information
The increasing demands on product life cycle management mean that information about products must be easily accessible during the product's entire lifetime. At the same time, the increasingly complex supplier networks (the "virtual enterprise") boost the need to exchange product information between organizations [9]. Increasing amounts of product customizations make it necessary to handle information on the product-item level rather than on the product-type level, which greatly adds to the amount of product information [7]. Therefore, vast amounts of product and component information are currently pushed forward in the supplier network so that all information can be associated with the final product. This easily leads to an information overflow in the downstream supply chain [10].
Transferring product information between supplier network members is technically challenging [9]. As shown by current EDI implementations, setting up such information links is costly and time-consuming for all participating companies. Even though information links exist, handling changes in products and in the information about them is not an easy task, especially when done on a product-item level. The challenge is to know where the information should be updated if there are multiple copies of it in different companies.
In software engineering, object-oriented programming (OOP) was developed as a solution to similar problems that initially occurred in simulation systems and graphical user interfaces (GUIs) [2], which both require managing great amounts of structured data. In this article, we show how an agent-based architecture can fulfill the same role as objects in OOP, where product agents benefit from OOP methods with only simple amendments to present IT services. The main technical difference is that agents must be able to communicate over company boundaries, while objects usually communicate inside a program running on a single computer.
As the Internet becomes universally accessible (at least in the industrial context), product information can be made available anywhere without copying it through a supplier network. Many companies already have existing Web services, where product information is accessible at least on the product-type level. The challenge is how to easily determine where that data is, how to access it, how to distribute the data to all parties requiring it, and how to update the data in all places. A simple solution is for the manufacturer of a product to attach product- or item-specific identities on all products manufactured. If the identities are globally unique, they can be used as references to where the product (or product item) information is accessible. Such an identity corresponds to an object reference in OOP, while message passing between agents corresponds to method calls in OOP. With these basic elements, it is possible to use standard OOP data structures and practices, for example, design patterns, for managing product information in a way that is already tested.
From Object-Oriented Programming to Product Agents
During the 1980s, the old procedural programming paradigm changed into an object-oriented paradigm. OOP has since become the dominant paradigm in software engineering. A main reason for this was that OOP makes it easier to manage data and functionality of a program by concentrating them around the object concept; that is, anyone (usually another object) that has a reference to the object can access information about the object through the object's methods. The available methods are declared in the class' public interface.
One-to-many relationships between objects are implemented by using object containers (actual collections of references to objects) that have existed in OOP since the Smalltalk programming language [4]. Object containers have obvious counterparts in the real world, for example, containers, packages, and sub-assemblies, among others. More complex structures, like hierarchies, can be constructed using object containers in standard ways called Design Patterns [3]. Design Patterns are reference solutions to many information management tasks that have been designed by experienced programmers and tested in multiple applications.
Where OOP offers "object-centric information management," product agents offer "Product centric information management" [57], where information regarding a product is retrieved over information networks when needed using unique product identities as references. Similar efficiency gains as those obtained by moving to OOP can be expected by moving to agent-based product information management.
A common definition of an agent says an agent should be autonomous, social, reactive, and proactive [11]. In practice there is no universal agreement on what an agent is and the agent concept is used in many different ways.
A product agent is implemented as a software component accessible over the Internet using some standardized communication protocol. The reference to an agent must be globally unique and indicate the Internet address where the agent can be accessed. For the agent reference, we have proposed using an ID@URI format, where the URI part identifies a resource, whose uniqueness is guaranteed by definition [1]. The ID part can use some existing identification standard as long as it remains unique inside the address space of the URI. Standards for globally unique identifiers have also been developed, for example, Global Trade Item Number (GTIN), Global Location Number (GLN) and Electronic Product Code (EPC).
In OOP, the communication between objects is based on method calls, but in the product-agent concept communication is performed through messages between the product agents, typically based on XML. The association between methods and messages is not new, for instance, Goldberg and Robson [4] call communication between objects "message passing," not "method calling." Interfaces have their direct correspondence in common communication protocols, for example, SOAP, Corba. Object containers are implemented by using database tables.
The accompanying table summarizes the relationships between the basic concepts of OOP and product-agent systems.
Using these basic parallels between OOP and agent systems, we address how OOP collections and Design Patterns can be used for handling product information in two typical product life cycle management contexts.
Design Patterns for Communicating Product Agents
For products with parts made by different companies, product information may have to be fetched from several sources. The same applies to information updates, where the updated information must be forwarded to the information systems of all companies concerned by the update. Several projects conducted with industrial partners at Helsinki University of Technology have revealed this is a major issue for information management. Two common industrial requirements and solution models for them are:
- Composite products. These are typically products that contain sub-assemblies made by different companies. Shipment units, for example, containers, pallets, among others, are also treated under this title.
- Observers. Companies that have not manufactured sub-assemblies may also need to receive information updates, even though they do not provide any information about the product. A transportation company, the recipient of a product in transport, or the users of recalled products are examples of these kinds of companies.
Design patterns used in OOP exist under similar names for both of these requirements.
- Composite. One of the most important design patterns presented in OOP is the Composite design pattern [3], the intent of which is to compose objects into tree structures to represent part-whole hierarchies, where individual objects and compositions can be treated uniformly. One of the most common uses of this design pattern is in drawing programs, where graphical objects may be grouped together to form new objects, which can then be grouped together with others. A set of operations is then applicable both to groups and objects.
The same is true for both products and shipment units used in transport that usually contain parts that come from many different companies. This signifies that physical product items become parts of each other, so the information related to them becomes interconnected. The construction of composite products usually does not change too much during the life cycle of most products, but it is a vital piece of information to manage when changes occur. Such changes occur when a shipment is transferred from one transport container to another, or when a part of a product is replaced with another during maintenance or refurbishing. Often the product individual forms a multi-level hierarchy, in which a product individual consists of a set of other product individuals as illustrated in Figure 1 where every part of the product has a list of references to the parts they contain in ID@URI format.
Figure 2 illustrates the propagation of an information update, for example, location update, through the containment hierarchy of a composite product. In many cases, only the identifier of the outermost part is accessible for reading. The outermost part is also the one at the top of the containment hierarchy, which makes it easy to propagate the information update to all the parts of the containment hierarchy. Fetching information about composite products works in a similar way. All companies in Figure 2 have product agents that receive the messages and autonomously decide on what information should be forwarded. This is important because it allows every company to control exactly what information is sent where.
The Composite design pattern recommends using bidirectional links in the hierarchy, which means that information can be fetched and updated by reading the identifier of any part of the composite. Messages currently implemented from the Composite design pattern are "GetComposite" (returns list of parts), "add" and "remove" ("add" and "remove" use only one message with a parameter indicating the operation to perform). Removing a part from a composite product can be done either explicitly by sending a message or implicitly by receiving a location update message indicating the part has been removed from the composite. We assume the best way to handle removal of parts will turn out to be rather application-specific.
Observer. The intent of the Observer design pattern is to define one-to-many dependencies between objects so that when one object changes state, all its dependents are notified and updated automatically [3]. One of the most common uses of this design pattern is in GUIs, where user actions on one GUI element also affect other GUI elements. Standard GUI classes of the Java language are an example of this, where the Observer pattern is used in numerous "listener interfaces." This can be used for propagating information updates in cases where the Composite pattern is not applicable, for example, when both the sender and the receiver need to track a shipment, or when break-downs of product components need to be communicated to a logistics company handling spares replenishments in addition to the producers of the product.
Figure 3 illustrates how an information update could be propagated through Observer references. Items [email protected], [email protected], and 456@ comp4.com observe item [email protected]. Items [email protected] and [email protected] observe item [email protected]. Therefore the information update message shown in the figure will be sent to the corresponding product agents.
Implementing the Observer design pattern means messages must exist to add observers and remove them. Observers are also usually interested only in specific information updates, so there may be several different add and remove messages for different kinds of information updates.
Implementation
In OOP, objects live and evolve inside the working memory of the computer on which the program is running. If the object data needs to be persistent, then it must be written to a file or stored into a database. The same is true for product agents; persistent data is usually stored in databases. Therefore, product agents are a bridge between external access to product information over the Internet and access to information stored in company databases. Such software components are usually called middleware because they enable otherwise isolated information systems to communicate with each other.
At Helsinki University of Technology we have developed a pilot product agent system implemented according to these specifications. The software, available at http://dialog.hut.fi, is distributed under the terms of the GNU Lesser General Public License. Here, we discuss the implementation from a messaging perspective, and then explain how "object containers" are implemented using database tables.
Messaging protocols. The current implementation uses three alternative communication protocols for message passing: SOAP, HTML form, and Java RMI. These different protocols are supported because they all provide different trade-offs between ease of installation and maintenance, firewall configuration, and communication speed. In order to make the system as open as possible, a major challenge is to standardize the messages used independently of the communication protocol itself so that any software producer could implement them and have their applications communicate with others successfully.
Database tables as agent containers. The software components are programmed in Java, so the communication with databases is performed using the Java Database Connectivity (JDBC) protocol. For now, databases seem to be the only universal way to communicate with most existing Enterprise Resource Planning (ERP) systems because they tend to have proprietary Application Programming Interfaces. A more direct integration with ERP systems could be necessary for real-time applications with short reaction times, but for most product life cycle management applications it should not be necessary.
Database tables used by the product agents are created by the middleware component as/when needed. Relations between product items are stored as three fields of a database table as "relation_name;subjectReference:ObjectReference" where references are stored as ID@URI. Composite and Observer data structures use relation names such as "parent," "child," "observe," and so on. Since the middleware components manage these relations, both Composite and Observer functionality can be implemented without modifying existing information systems.
Experiences from pilot installations. Two pilot installations have been performed in a multi-company environment [8]. The first pilot consisted in tracking project shipments in a global environment. Shipments were identified with RFID technology and tracked at several checkpoints. The second pilot consisted in tracking incoming and outgoing goods at warehouses of several third-party contractors. Goods were identified with barcodes. These pilot installations show that the middleware messaging architecture presented here is operational. Composite and Observer have been implemented and tested by exchanging messages defined by the corresponding design patterns in a similar way as in the pilot installations. Therefore this kind of middleware can provide a common technical platform for distributed management of product information, independently of the application area. In what way these design patterns are used in practice (user interfaces, connections to existing software, and so on) can be expected to be highly application-dependent.
Conclusion
In this article we have presented basic building blocks for using OOP concepts to manage product life cycle information in a multi-supplier context. These building blocks make it possible to create distributed agent-based information architectures that make product information accessible in controlled ways over the Internet. We have also presented how well-known OOP practices can be applied to information management of composite products and for propagating information updates through the Observer pattern.
The concepts have been implemented using several communication protocols and data formats, which all have different advantages and challenges as shown by experiences from two industrial pilot installations. Using different protocols need not be a problem because the same product-agent component can simultaneously support all communication protocols and data formats used. However, establishing universally accepted standards especially for message formats remains one of the biggest challenges of the future. We believe that by keeping our system open, that is, open source and general purpose, it will be possible to implement new functionality for applications not yet identified while allowing the integration of evolving standards.
References
1. Berners-Lee, T., Fielding, R., Irvine, U.C., and Masinter, L. Uniform Resource Identifiers (URI): Generic Syntax; www.ietf.org/rfc/rfc2396.txt.
2. Dahl, O.-J. and Nygaard, K. SIMULAAn ALGOL-based simulation language. Commun. ACM 9, 9 (Sept. 1966), 671678.
3. Gamma, E., Helm, R., Johnson, R., and Vlissides, J. Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley, Reading, MA, 1995.
4. Goldberg, A. and Robson, D. Smalltalk-80: The Language and its Implementation. Addison-Wesley, Reading, MA, 1983.
5. Kärkkäinen, M., Holmström, J., Främling, K., and Artto, K. Intelligent productsA step towards a more effective project delivery chain. Computers in Industry 50, 2 (2003), 141151.
6. Kärkkäinen, M., Främling, K., and Ala-Risku, T. Integrating material and information flows using a distributed peer-to-peer information system. In Collaborative Systems for Production Management. H.S. Jagdev, J.C. Wortmann, H.J. Pels, Eds. Kluwer, Boston, MA, 2003, 305319.
7. Kärkkäinen, M., Ala-Risku, T., and Främling, K. The product centric approach: A solution to supply network information management problems? Computers in Industry 52, 2 (2003), 147159.
8. Kärkkäinen, M., Ala-Risku, T., and Främling, K. Efficient tracking for short-term multi-company networks. International Journal of Physical Distribution and Logistics Management 34, 7 (2004), 545564.
9. Petrie, C. and Bussler, C. Service agents and virtual enterprises: A survey. IEEE Internet Computing 7, 4 (2003), 6878.
10. van Dorp, K.J.Tracking and tracing: a structure for development and contemporary practices. Logistics Information Management 15, 1 (2002), 2433.
11. Wooldridge, M. and Jennings, N.R. Intelligent agents: Theory and practice. Knowledge Engineering Review 10, 2 (1995), 115152.
Figures
Figure 1. Example of composite product hierarchy.
Figure 2. Propagation of information updates (IU) for the composite hierarchy of
Figure 3. Propagation of information update (IU) through Observer references as for Composite in
©2007 ACM 0001-0782/07/0600 $5.00
Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee.
The Digital Library is published by the Association for Computing Machinery. Copyright © 2007 ACM, Inc.
No entries found