Making an application secure is much harder than just adding a password protected login screen. This paper contains a collection of patterns to be used when dealing with application security. Secure Access Layer provides an interface for applications to use the security of the systems on which they are built. Single Access Point limits entry into the application through one single point. Check Point gives the developer a way to handle an unknown or changing security policy. Groups of users have different Roles that define what they can and cannot do. The global information about the user is distributed throughout the application with a Session. Finally, users are presented with either a Limited View of legal options or are given a Full View With Errors. These seven patterns work together to provide a security framework for building applications. This paper was submitted, accepted and workshopped at PLoP `97 Copyright 1998. All Rights Reserved. Permission granted to copy for the PLoPD...

Abstract. Complex software systems require expressive notations for representing their software architectures. Two competing paths have emerged. One is to use a specialized notation for architecture – or architecture description language (ADL). The other is to adapt a general-purpose modeling notation, such as UML. The latter has a number of benefits, including familiarity to developers, close mapping to implementations, and commercial tool support. However, it remains an open question as to how best to use object-oriented notations for architectural description, and, indeed, whether they are sufficiently expressive, as currently defined. In this paper we take a systematic look at these questions, examining the space of possible mappings from ADLs into object notations. Specifically, we describe (a) the principle strategies for representing architectural structure in UML; (b) the benefits and limitations of each strategy; and (c) aspects of architectural description that are intrinsically difficult to model in UML using the strategies. 1

JBoss is an extensible, reflective, and dynamically reconfigurable Java application server. It includes a set of components that implement the J2EE specification, but its scope goes well beyond J2EE. JBoss is open-ended middleware, in the sense that users can extend middleware services by dynamically deploying new components into a running server. We believe that no other application server currently offers such a degree of extensibility. This paper focuses on two major architectural parts of JBoss: its middleware component model, based on the JMX model, and its meta-level architecture for generalized EJBs. The former requires a novel class loading model, which JBoss implements. The latter includes a powerful and flexible remote method invocation model, based on dynamic proxies, and relies on systematic usage of interceptors as aspect-oriented programming artifacts.

CORE ...........................................................................................................................204 Deep Models .......................................................................................................................................205 Refactoring and Distillation ................................................................................................................205 17. Large-Scale Structure.................................................................................................................206 EVOLVING ORDER .........................................................................................................................208 SYSTEM METAPHOR [BECK 2000] .................................................................................................209 PLUGGABLE COMPONENTS.............................................................................................................210 ABSTRACT DOMAIN FRAMEWORK .................................................................................................212 RESPONSIBILITY LAYERS...............................................................................................................212 Large-Scale Structure, Unification Contexts, and Distillation ............................................................223 Refactoring Toward a Fitting Structure...............................................................................................225 Architecture, Architecture Teams, and Large-Scale Structure ............................................................227 18. Game Plans ..................................................................................................................................230 Looking Forward.....

The Workflow Patterns Initiative was established with the aim of delineating the fundamental requirements that arise during business process modelling on a recurring basis and describe them in an imperative way. The first deliverable of this research project was a set of twenty patterns describing the control-flow perspective of workflow systems. Since their release, these patterns have been widely used by practitioners, vendors and academics alike in the selection, design and development of workflow systems [vdAtHKB03]. This paper presents the first systematic review of the original twenty control-flow patterns and provides a formal description of each of them in the form of a Coloured Petri-Net (CPN) model. It also identifies twenty three new patterns relevant to the control-flow perspective. Detailed context conditions and evaluation criteria are presented for each pattern and their implementation is assessed in fourteen commercial offerings including workflow and case handling systems, business process modelling formalisms and business process execution languages. 1

Over the past decade, software architecture research has emerged as the principled study of the overall structure of software systems, especially the relations among subsystems and components. From its roots in qualitative descriptions of useful system organizations, software architecture has matured to encompass broad explorations of notations, tools, and analysis techniques. Whereas initially the research area interpreted software practice, it now offers concrete guidance for complex software design and development. We can understand the evolution and prospects of software architecture research by examining the research paradigms used to establish its results. These are, for the most part, the paradigms of software engineering. We advance our fundamental understanding by posing research questions of several kinds and applying appropriate research techniques, which differ from one type of problem to another, yield correspondingly different kinds of results, and require different methods of validation. Unfortunately, these paradigms are not recognized explicitly and are often not carried out correctly; indeed not all are consistently accepted as valid. This retrospective on a decade-plus of software architecture research examines the maturation of the software architecture research area by tracing the types of research questions and techniques used at various stages. We will see how early qualitative results set the stage for later precision, formality, and automation and how results build up over time. This generates advice to the field and projections about future impact. Keywords: Software architecture, research paradigms 1.

A design pattern is a particular prose form of recording design information such that designs which have worked well in the past can be applied again in similar situations in the future. The availability of a collection of design patterns can help both the experienced and the novice designer recognize situations in which design reuse could or should occur. We have found that design patterns: 1) provide an effective "shorthand" for communicating complex concepts effectively between designers, 2) can be used to record and encourage the reuse of "best practices", 3) capture the essential parts of a design in compact form, e.g. for documentation of existing software architectures. Since the patterns community is one that shares information in an open forum and builds on the experiences of others, we chose to submit a joint paper on our industrial experiences with patterns. We focus on the lessons learned in our respective industrial settings as a first step towards answering the questions...

Agent systems must have a strong foundation; one approach that has been successfully applied to other kinds of software is patterns. This paper presents a collection of patterns for agents. 2. MOTIVATION Almost all agent development to date has been "home grown" [4] and done from scratch, independently, by each development team. This has led to the following problems: . Lack of an agreed definition: Agents built by different teams have different capabilities. . Duplication of effort: There has been little reuse of agent architectures, designs, or components. . Inability to satisfy industrial strength requirements: Agents must integrate with existing software and computer infrastructure. They must also address security and scaling concerns. Agents are complex and ambitious software systems that will be entrusted with critical applications. As such, agent based systems must be engineered with valid software engineering principles and not constructed in an ad hoc fashion. Agent system...

Abstract Developers of communication software must confront recurring design challenges involving robustness, efficiency, and extensibility. Many of these challenges are independent of the application-specific requirements. Successful developers resolve these challenges by applying appropriate design patterns. However, these patterns have traditionally been locked in the minds of expert developers or buried within complex system source code. The primary contribution of this paper is to describe a family of design patterns that underly many object-oriented communication software systems. In addition to describing each pattern separately, the paper illustrates how knowledge of the relationships and trade-offs among patterns helps guide the construction of reusable communication software frameworks. 1 Introduction Building, maintaining, and enhancing high quality communication systems is hard. Developers must have a deep understanding of many complex issues such as service initializatio...

Factory, Builder, and Service Configurator) the ACE framework components facilitate the development of communication software that may be updated and extended without modifying, recompiling, relinking, or even restarting running systems [6]. 3.1.4 Self-contained Distributed Service Components ACE provides a standard library of distributed services that are packaged as self-contained components. Although these service components are not strictly part of the ACE framework, they play two important roles: Factoring out reusable distributed application building blocks: These service components provide reusable implementations of common distributed application tasks such as naming, event routing, logging, time synchronization, and network locking; Demonstrating common use-cases of ACE: These distributed services also demonstrate how ACE components (such as Reactors, Service Configurators, Acceptors and Connectors, Active Objects, and IPC wrappers) can be used effectively to develop flexi...