Transcription
Mo 2January 21-25, 2008, Munich, GermanyICM - International Congress Centre MunichPattern-Oriented Software ArchitectureFrank BuschmannKevlin Henney
ARCHITECTURETHE CRAFT OF SOFTWAREPattern-OrientedSoftware ArchitectureKevlin HenneyFrank BuschmannSiemens AGfrank.buschmann@siemens.comPATTTERN–ORIENTED SOFTWAREARCHITECTURECurbralan -Alone PatternsPattern Complements / Pattern CompoundsPattern Stories / Pattern SequencesPattern LanguagesOutroductionReferencesPattern-Oriented Software Architecture2 Frank Buschmann, Kevlin Henney, all rights reserved1
IntroductionPATTTERN–ORIENTED SOFTWAREARCHITECTUREWhere we areStand-Alone PatternsPattern Complements / Pattern CompoundsPattern Stories / Pattern SequencesPattern LanguagesOutroductionReferencesPATTTERN–ORIENTED SOFTWAREARCHITECTUREPattern-Oriented Software Architecture3 Frank Buschmann, Kevlin Henney, all rights reservedOn Designing with Patterns (1)Patterns have become a popular tool in software design They have changed the way software developersthink about and practice software design They provide us with a software design vocabulary They help us to resolve recurring problemsconstructively and based on proven solutions They support us in understanding the architectureof a given software system .But: applying patterns in software design is not necessarilydesigning with patterns!Pattern-Oriented Software Architecture4 Frank Buschmann, Kevlin Henney, all rights reserved2
ARCHITECTUREPATTTERN–ORIENTED SOFTWAREOn Designing with Patterns (2)Patterns applied in isolation and as modular building blocks donot create sustainable lient Fail to consider the surroundingproblems and their solutions.Component Have at best only local effects. Do not complement one anotheror mutually reinforce theirbeneficial ompositeStrategyLeafgnesirDCompositeoPo Create complex architecturesthat lack useful operational anddevelopmental ionPATTTERN–ORIENTED SOFTWAREARCHITECTUREPattern-Oriented Software Architecture5 Frank Buschmann, Kevlin Henney, all rights reservedOn Designing with Patterns (3)There are two fundamental ways of integrating patterns: Refinement: One pattern refines the structure and behavior of anotherpattern to address a specific sub-problem or implementation detail. Combination: Two or more patterns arranged to form a larger structurethat addresses a more complex problem.There are also relationships regarding choice: Alternatives: Some patterns describe alternatives to one another. Theyaddress the same or a similar problem, but each pattern considers a slightlydifferent set of forces. Thus, the patterns provide different solutions and havedifferent consequences. Cooperation: Some patterns nicely complement one another, mutuallyreinforcing their structural and behavioral properties.Pattern-Oriented Software Architecture6 Frank Buschmann, Kevlin Henney, all rights reserved3
ARCHITECTUREPATTTERN–ORIENTED SOFTWAREOn Designing with Patterns (4)Patterns applied by considering theirrelationships create balanced designs. Have systemic effects.ARCHITECTURECommand &Composite Complement one anotherand mutually reinforce theirbeneficial Client Consider their surroundingproblem and solution entoMementoConcreteCommand Create whole and balanceddesigns that expose therequired operational anddevelopmental qualities.Pattern-Oriented Software ArchitecturePATTTERN–ORIENTED pplication7 Frank Buschmann, Kevlin Henney, all rights reservedOn Designing with Patterns (5)This tutorial is on designing withpatterns to create,The networkwith economy and elegance,TelegramTelegramForwarderReceiverpasses telegrams topasses telegrams toTelegrampassesConvertercommands utesLogCommandAlarmscreatessoftware designs andimplementationsthat work and meet theirexpected quality attributes!PickWorkpiecePattern-Oriented Software Architecture8SetPointCalculation Frank Buschmann, Kevlin Henney, all rights reserved4
ARCHITECTUREPATTTERN–ORIENTED SOFTWAREWhere we areIntroductionStand-Alone PatternsPattern Complements / Pattern CompoundsPattern Stories / Pattern SequencesPattern LanguagesOutroductionReferencesPATTTERN–ORIENTED SOFTWAREARCHITECTUREPattern-Oriented Software Architecture9 Frank Buschmann, Kevlin Henney, all rights reservedA Solution to a Problem (1)A stand-alone pattern: Presents a solution for a recurring problem that arises in a specificcontext. Documents proven design experience; is an "aggressive disregard oforiginality" Brian Foote Specifies a spatial configuration of elements and the behavior thathappens in this configuration. Provides common vocabulary and conceptual understanding.Pattern-Oriented Software Architecture10 Frank Buschmann, Kevlin Henney, all rights reserved5
ARCHITECTUREPATTTERN–ORIENTED SOFTWAREHalf-Object Plus Protocol at a GlanceProblemHalf ObjectsHow can we design objects in adistributed system:Node 1Node 2local such that access to them and theexecution of their services incursminimal performance penalties?remoteSolutionClient Split an object into multiple halves –one half per address space fromwhich the object is accessed.Protocol Within each half, fully implement all functionality thatcan be executed locally without using the network. Implement functionality that crosses address spaces partiallyin each half and coordinate the halves via a protocol.PATTTERN–ORIENTED SOFTWAREARCHITECTUREPattern-Oriented Software Architecture11 Frank Buschmann, Kevlin Henney, all rights reservedA Solution to a Problem (2)A stand-alone pattern: Is both a process and a thing, with the thing being created by theprocess. Addresses a set of forces that completes the general problem bydescribing requirements, constraints, and desired properties for thesolution. Introduces a set of interacting roles that can be arranged in manydifferent ways, not a fixed configuration of classes or components. Specifies a solution that is based on experience, judgment, anddiligence – it cannot necessarily be constructed in a straightforwardmanner using a common engineering method.Pattern-Oriented Software Architecture12 Frank Buschmann, Kevlin Henney, all rights reserved6
ARCHITECTUREPATTTERN–ORIENTED SOFTWAREHalf-Object Plus Protocol at a Glance (2)ProblemHow can we design objects in adistributed system:ForceRole: Half ObjectsNode 1Node 2local such that access to them and theexecution of their services incursminimal performance penalties?remoteSolutionRole: ClientRole: Protocol Split an object into multiple halves –one half per address space fromwhich the object is accessed. Within each half, implement all functionality thatcan be executed locally without using the network.Processorientedsolution Implement functionality that crosses address spaces partiallyin each half and coordinate the halves via a protocol.PATTTERN–ORIENTED SOFTWAREARCHITECTUREPattern-Oriented Software Architecture13 Frank Buschmann, Kevlin Henney, all rights reservedDesigning with Stand-Alone PatternsStand-alone patterns can help you to resolve specific, restrictedproblems well, but They discuss the solution they introduce in isolation from other problems andtheir solutions, and also the dependencies between the problems andsolutions. They do not consider alternative solutions to similar problems but with differentsets of forces. They do not inform you when to address the problem in the context ofdesigning a concrete system that must resolve many different problems.Patterns are like colorful words, bits and pieces of an expressivelanguage whose grammar is forgotten and whose excitingstories and cultural tales are lost!Pattern-Oriented Software Architecture14 Frank Buschmann, Kevlin Henney, all rights reserved7
ARCHITECTUREPATTTERN–ORIENTED SOFTWAREWhere we areIntroductionStand-Alone PatternsPattern Complements / Pattern CompoundsPattern Stories / Pattern SequencesPattern LanguagesOutroductionReferencesPATTTERN–ORIENTED SOFTWAREARCHITECTUREPattern-Oriented Software Architecture15 Frank Buschmann, Kevlin Henney, all rights reservedPattern ComplementsPattern complements are sets of patterns that are Complementary with respect to competition. One pattern may complementanother because it provides an alternative solution to the same or a similarproblem, and thus is complementary in terms of the design decisions that canbe taken. Complementary with respect to completeness. One pattern maycomplement another because it completes a design, acting as a natural pairingto the other.Although the two ideas seem distinct at first glance, competition andcooperation are often very closely related.Pattern-Oriented Software Architecture16 Frank Buschmann, Kevlin Henney, all rights reserved8
ARCHITECTUREPATTTERN–ORIENTED SOFTWAREPattern in CompetitionAbstract FactoryAbstractFactorycreate productAdispose productAAbstractProductAConcreteFactorycreate productAdispose erProductAProductABuildercreate partAdispose partAcreate partBdispose partBPatterns in Competition Resolve the same core problem, but presentalternative solutions to it. Each solutionaddresses different forces in context. Provide an overview of the problem's entiresolution space and allow developers todecide, when to use whatAbstractPartApattern in the ate partAdispose partAcreate partBdispose partBParttAAbstractPartBPartB Abstract Factory, BuilderConcretePartBPartBPATTTERN–ORIENTED SOFTWAREARCHITECTUREPattern-Oriented Software Architecture Objects for States, Methodsfor States, Collection forStates17 Iterator, Batch Method,Enumeration Method Frank Buschmann, Kevlin Henney, all rights reservedThe Iterator PatternClassically defined in terms of separating the responsibility foriteration from its target The knowledge for iteration is encapsulated in a separate object from thetarget, typically but not necessarily a collection. Iteration is managed externally from the collection. Rendered idiomatically in different languages, e.g. STL in C and (more thanonce) in Java's standard libraryIteratorProvide a way to access the elements of an aggregate objectsequentially without exposing its underlying representation.Pattern-Oriented Software Architecture18 Frank Buschmann, Kevlin Henney, all rights reserved9
ARCHITECTUREPATTTERN–ORIENTED SOFTWAREIterator Configuration SketchThere are four essential, elementary operations associated with anIterator's behavior Initializing an iteration, i.e. the initializer of a for loop Checking a completion condition, i.e. the continuation condition of a for loop Accessing a current target value, e.g. in the body of a for loop Moving to the next target value, i.e. the progression of a for loopCollectionType*1createIterator() : Iterator«create»PATTTERN–ORIENTED SOFTWAREARCHITECTUREPattern-Oriented Software Architecture19IteratorTypefinished() : Boolean {query}value() : Type {query}next() Frank Buschmann, Kevlin Henney, all rights reservedDistribution Issues In a distributed environment concurrency is implicit But this is not the only force at work Operation invocations are no longer trivial Communication can dominate computation Partial failure is almost inevitableclientservantCost of communicationPattern-Oriented Software Architecture20 Frank Buschmann, Kevlin Henney, all rights reserved10
ARCHITECTUREPATTTERN–ORIENTED SOFTWAREThe Batch Method Pattern Iterated simple methods use up bandwidth The client and server parts spend far more time waiting on communicationthan performing useful computation Therefore, provide the repetition in a data structure This is a coarser and more appropriate granularity that reducescommunication and synchronisation costs Batching can refer to passed sequences of values, result sequences ofvalues, or both passed and result sequencesBatch MethodGroup multiple collection accesses together to reduce the cost ofmultiple individual accesses in a distributed environment.PATTTERN–ORIENTED SOFTWAREARCHITECTUREPattern-Oriented Software Architecture21 Frank Buschmann, Kevlin Henney, all rights reservedThe Enumeration Method Pattern An inversion of the basic Iterator design Iteration is encapsulated within the collection Collection stateless with respect to iteration A method on the collection that receives a Command, which itthen applies to its elements Idiomatic iteration in Smalltalk and other languages with support fortreating blocks of code as objectsEnumeration MethodSupport encapsulated iteration over a collection by placingresponsibility for iteration in a method on the collection. Themethod takes a Command object that is applied to the elementsof the collection.Pattern-Oriented Software Architecture22 Frank Buschmann, Kevlin Henney, all rights reserved11
ARCHITECTUREPATTTERN–ORIENTED SOFTWAREEnumeration Method SketchHas very different trade-offs when compared to the Iteratorapproach Client is not responsible for loop housekeeping details Synchronization can be provided at the level of the whole traversal rather thanfor each element access Sometimes known as the Internal Iterator pattern, but clearly has nothing incommon with (External) mand)executeOn(Type)Loop administration is handled inthe implementation of theenumerationMethodPATTTERN–ORIENTED SOFTWAREARCHITECTUREPattern-Oriented Software ArchitectureTypeLoop body is now provided asthe implementation of theexecuteOn method23 Frank Buschmann, Kevlin Henney, all rights reservedPattern in CooperationPatterns in Cooperation Naturally complement one another towards a more complete and balanceddesign. Mutually reinforce their quality properties. Examples: Command andCommand Processor Abstract Factory,Factory Method, andDisposal Method Iterator,Combined Method,and Batch MethodAbstract ductAAbstractFactorycreate productAdispose productAConcreteFactorycreate productAdispose productAFactory MethodDisposal MethodPattern-Oriented Software Architecture24 Frank Buschmann, Kevlin Henney, all rights reserved12
ARCHITECTUREPATTTERN–ORIENTED SOFTWAREConcurrency Issues for Iterator Synchronization is required to ensure consistent and coherentstate change This cannot be handled adequately by the Iterator client Property-style programming, i.e. using fine-grained getters andsetters, is inappropriate There is a mismatch in granularity and coherenceclient 1PATTTERN–ORIENTED SOFTWAREARCHITECTUREPattern-Oriented Software Architectureservant25client 2 Frank Buschmann, Kevlin Henney, all rights reservedThe Combined Method PatternApplying it gives slightly coarser granularity than the separatedmethods of an ordinary sequential Iterator Aligns and groups the unit of failure, synchronization and common use Makes method design more transactional in style Improves the encapsulation of collection use, isolating the client fromunnecessary details of execution and failureCombined MethodCombine methods that are commonly used together to guaranteecorrectness and improve efficiency in threaded and distributedenvironments.Pattern-Oriented Software Architecture26 Frank Buschmann, Kevlin Henney, all rights reserved13
ARCHITECTUREPATTTERN–ORIENTED SOFTWAREBatched IteratorsA combination of these various patterns recurs in distribution andcomponent-based design A compound design that addresses many ryMethodDisposalMethodPATTTERN–ORIENTED SOFTWAREARCHITECTUREPattern-Oriented Software Architecture27 Frank Buschmann, Kevlin Henney, all rights reservedThe Batch Iterator (or Chunky Iterator) PatternA combination of, primarily, both Batch Method and Iterator,addressing more than either one Iterating over individual values in a server wastes both time and bandwidth,even with a Combined Method Batch Method can cause the client to block for too long: the delay for all valuesto be gathered and marshaled may be unacceptable, reducing clientresponsiveness Therefore, combine both patterns so that an Iterator pulls many values at atime using a Batch MethodBatch MethodIteratorPattern-Oriented Software Architecture28 Frank Buschmann, Kevlin Henney, all rights reserved14
ARCHITECTUREAtomicNode Describe recurringarrangements of several tightlyintegrated patterns that togetherresolve more complex problemsthan each constituent patternalone can do.CompositeNodeAbstractNodeAtomicNode*Pattern ��ORIENTED SOFTWAREPattern CompoundsParentRequestMediatorBureaucracy List what patterns help resolvingthe core problem.AbstractNode Specify how all patterns integratewith one another.AtomicNode*ParentCompositeNodeExample: Bureaucracy integrates Composite, Chain of Responsibility, Observer, andMediator to model complex, collaborative hierarchical structures.PATTTERN–ORIENTED SOFTWAREARCHITECTUREPattern-Oriented Software Architecture29 Frank Buschmann, Kevlin Henney, all rights reservedElement or Compound?Is a set of cooperating patterns complementary or compound? The general notion of usage or inclusion of one pattern in anothersuggests that we can consider most patterns as compounds, witheach pattern drawing on others to realize its fill expression. However, the term compound is normally reserved for a group ofpatterns that addresses problem in its own right and is alwaysresolved with the same arrangement of its constituent patterns. Sometimes it is just a matter of perspective.If we want to focus on iteration only, we can consider Batch Iterator as a patterncompound. If we want to focus on the supporting nature of patterns we canconsider Iterator and Batch Method as a pair of complementary patternscooperating in the same design.Pattern-Oriented Software Architecture30 Frank Buschmann, Kevlin Henney, all rights reserved15
ARCHITECTUREPATTTERN–ORIENTED SOFTWARESupport for Designing with PatternsPattern complements and pattern compoundssupport designing with patterns but: Although they consider dependencies between, and the rolebased integration of, patterns, they still fail to support a trulypattern-based approach to software development!Pattern Complements: Consideration of alternatives.Limited to resolving isolated localproblems.PATTTERN–ORIENTED SOFTWAREARCHITECTUREPattern-Oriented Software ArchitecturePattern Compounds: Present recurring arrangementsof tightly integrated patterns.Limited to resolving isolated problems.31 Frank Buschmann, Kevlin Henney, all rights reservedWhere we areIntroductionStand-Alone PatternsPattern Complements / Pattern CompoundsPattern Stories / Pattern SequencesPattern LanguagesOutroductionReferencesPattern-Oriented Software Architecture32 Frank Buschmann, Kevlin Henney, all rights reserved16
ARCHITECTUREPATTTERN–ORIENTED SOFTWAREPattern StoriesPattern StoriesReflection Are like diaries that tells their readershow one specific software system,subsystem, or large component wasdeveloped with the help of patterns.ProxyThey discuss: What patterns were consideredand selected to resolve the problems.StrategyAcceptorConector How the selected patterns wereinstantiated within the system’sspecific context and architecture.StrategyReactorBroker33 Frank Buschmann, Kevlin Henney, all rights reservedA Short Story: Warehouse ManagementWarehouse Management Systems:PATTTERN–ORIENTED SOFTWAREARCHITECTUREAdapterForwarderReceiver What specific problems were to beresolved in what specific order.Pattern-Oriented Software ArchitectureProxyFacade Organize warehouse operation: storing,fetching, picking, replenishment, etc. Control and optimize the material flowwithin a warehouse. Control base automation. Cooperate with other applications, suchas ERP systems and databases.Pattern-Oriented Software Architecture34 Frank Buschmann, Kevlin Henney, all rights reserved17
ARCHITECTUREPATTTERN–ORIENTED SOFTWAREKey Challenges (1)Building Warehouse ManagementSystems requires: defining an appropriate base-linearchitecture that specifies the system'sfunctional and infrastructural subsystems,their relationships and key interactions. developing/selecting suitablecomponent/communication middleware. designing and implementing thesystem's functionality withsufficient quality: performance,stability, scalability, extensibility, etc.ERPHCIUserMgr designing a user-friendly user interface.ARCHITECTUREPATTTERN–ORIENTED SOFTWAREWarehouseDBRepresentationAccessMaterial FlowControlFaultMgr providing an efficient connection ofthe system with the database.Pattern-Oriented Software ArchitectureWarehouseManagement35Base Automation Frank Buschmann, Kevlin Henney, all rights reservedKey Challenges (2)Six key requirements affect thesystems base-line architecture: Modularity: the system is developedby a large, globally distributed teamERPHCI Distribution: the system is esentationMaterial FlowControl?DBAccessFaultMgr Human-computer interaction: usersinteract with the system via differentuser interfaces.UserMgrBase Automation Integration: we want to integrate third-partyproducts and legacy software. Scalability: the system must support small-scale warehouses as well aslarge-scale warehouses. Performance: the system must support high-performance and throughput.Pattern-Oriented Software Architecture36 Frank Buschmann, Kevlin Henney, all rights reserved18
ARCHITECTUREPATTTERN–ORIENTED SOFTWAREPartitioning the Big Ball of Mud (1)The basis for a sustainable base-line architecture is a clear separation andencapsulation of different system concerns.Otherwise, the implementation of these concerns will likely be tangled ratherthan loosely coupled, which complicates their independent development,configuration, and deployment across a computer network.How can we organize thesystem's functionality intocoherent groups such thateach group can be developedand modified independently?PATTTERN–ORIENTED SOFTWAREARCHITECTUREPattern-Oriented Software Architecture37 Frank Buschmann, Kevlin Henney, all rights reservedLayers at a GlanceProblemHow can we partition the functionalityin a system such that:User Interface Layer Functionality of different kinds ofabstraction and levels of granularityis decoupled as much as possible.Business Process LayerBusiness Object Layer Functionality at a particular level ofabstraction or granularity can evolveat different times and rates withoutincurring rippling effects.Database Access LayerInfrastructure LayerSolution Define one or more layers for the software under development with eachlayer having a distinct and specific responsibility, for instance, regardingabstraction, granularity, or rate of change.Pattern-Oriented Software Architecture38 Frank Buschmann, Kevlin Henney, all rights reserved19
ARCHITECTUREPATTTERN–ORIENTED SOFTWAREPartitioning the Big Ball of Mud (2)Partition the system into multiple interacting Layers with each layerrepresenting a specific responsibility or concern of relevance andcomprising all functionality that addresses that concern. Presentation: gateways to higherlevel MES or ERP systems / HMI.Presentation Business Processes: administrativeand operational functionality.Business Process Business Objects: representationsof domain-specific physical andlogical entities.Business Objects Infrastructure: persistence, loggingfailover, etc.Infrastructure Access: gateways to lower-levelsystems in the field level.PATTTERN–ORIENTED SOFTWAREARCHITECTUREPattern-Oriented Software ArchitectureAccess39 Frank Buschmann, Kevlin Henney, all rights reservedDecomposing the Layers (2)Layers are an important step toward providing a product-line architecture forthe warehouse management system.Yet layers alone are still too coarse grained to support sufficiently modularsoftware development: they only separate concerns between functionalityat different kinds and levels of abstraction, but not between differentfunctionality at the same level.How can we refine a layeredarchitecture into smaller, strictlyseparated modular parts witheach part having a clearlydefined and scopedresponsibility?PresentationBusiness ProcessBusiness ObjectsInfrastructureAccessPattern-Oriented Software Architecture40 Frank Buschmann, Kevlin Henney, all rights reserved20
ARCHITECTUREPATTTERN–ORIENTED SOFTWAREDomain Object at a hod2How can we partition the functionalityin a system such that: Each self-contained unit of functionalityis decoupled as much as possible fromother self-contained units of functionality.ImplementationTwo forms ofdomain objectName Any unit of self-contained functionalitycan evolve at different timeswithout incurring ripple tesType uctInformationMetadataModule 1Type 2IL-CodeType 3IL-CodeResourcesSolutionEncapsulate each self-contained functionality into a domain object An interface provides the accessible methods of the domain object. An implementation realizes the offered functionality of the domain object.PATTTERN–ORIENTED SOFTWAREARCHITECTUREPattern-Oriented Software Architecture41 Frank Buschmann, Kevlin Henney, all rights reservedDecomposing the Layers (2)Provide a Domain Object for each self-contained, coherent, andfunctionally related responsibility within a layered design.Pattern-Oriented Software Architecture42 Frank Buschmann, Kevlin Henney, all rights reserved21
ARCHITECTUREPATTTERN–ORIENTED SOFTWAREAccessing Domain Object Functionality (1)The partitioning of the warehouse management process control system intolayers containing domain objects provides a sustainable foundation formodular software development.However, in spite of the clear separation of different responsibilities, thedomain objects are still tightly connected: each domain object directlyaccesses the concrete implementation type of the domain object it uses.How can we ensure thatdomain objects do notdepend on implementationsof other domain objects?WarehouseTopologyImplementationMaterial entationPATTTERN–ORIENTED SOFTWAREARCHITECTUREPattern-Oriented Software Architecture43 Frank Buschmann, Kevlin Henney, all rights reservedExplicit Interface andEncapsulated Implementation at a GlanceProblemHow can clients use components such that:Explicit Interface They are independent of component internals,such as concrete type, implementation,interface, and programming model.InterfaceMethod1InterfaceMethod2 Remote access can be supported transparently. Changes to the component's realization donot ripple through to thod1ImplementationMethod2SolutionPhysically separate the interface of the component from its implementationand export the interface to the clients of the component: An explicit interface realizes the published contract of a component. An encapsulated implementation realizes the component's functionality.Pattern-Oriented Software Architecture44 Frank Buschmann, Kevlin Henney, all rights reserved22
ARCHITECTUREPATTTERN–ORIENTED SOFTWAREAccessing Domain Object Functionality (2)Split each domain object into an Explicit Interface with a correspondingEncapsulated Implementation to separate the object's public contractfrom its realization.PATTTERN–ORIENTED SOFTWAREARCHITECTUREPattern-Oriented Software Architecture45 Frank Buschmann, Kevlin Henney, all rights reservedBridging the Network (1)Most installations of the warehouse management systems are deployedacross a computer network in order to meet their operational requirements.Consequently there could be a process or machine boundary between anytwo layers in the system or between any two domain objects of a layer.How can we shield Domain Objectsof the system from dealing withnetworking issues directly whilesupporting location-independentinteraction between ttern-Oriented Software Architecture46 Frank Buschmann, Kevlin Henney, all rights reserved23
ARCHITECTUREPATTTERN–ORIENTED SOFTWAREBroker at a GlanceProblemHow can we support remoting such that:Client 1Client 2Servant 1Servant 2Clt-ProxyServant 3Clt-ProxyServant 1Svr-ProxyNode 1Broker Communication is location rate the communication infrastructureof a distributed system from its applicationfunctionality via a federation of brokers:Node 2Broker Clients and servants provide applicationfunctionality on any network node.Servant 2Svr-ProxyServant 3Svr-ProxyServant 1Clt-Proxy Brokers mediate IPC between clientsand servants.Servant 2Servant 3Client 3 Client-side and server-side proxies provide location independence andshield clients and servants from networking issues.PATTTERN–ORIENTED SOFTWAREARCHITECTUREPattern-Oriented Software Architecture47 Frank Buschmann, Kevlin Henney, all rights reservedBridging the Network (2)Introduce a Broker to allow distributed domain objects of thewarehouse management system to access and communicate withone another in the same way, as if both parties were collocated.Pattern-Oriented Software Architecture48 Frank Buschmann, Kevlin Henney, all rights reserved24
ARCHITECTUREPATTTERN–ORIENTED SOFTWARESeparating User Interface (1)Domain objects of the presentation layer neither implement any businesslogic nor maintain any business state—both responsibilities are assignedto other layers of the system that are
Pattern-Oriented Software Architecture 4 On Designing with Patterns (1) Patterns have become a popular tool in software design They have changed the way software developers think about and practice software design They provide us with a software desig
