COMCOR - Agile Architect
TECHNICAL REFERENCE ARCHITECTUREFORCOMPONENT BASED DEVELOPMENTANDENTERPRISE APPLICATION INTEGRATIONBy Tim BarrettCOMCORComCor I.T Solutions b.v.-1 -
TECHNICAL REFERENCE ARCHITECTURE FOR CBD AND EAIContents1. Introduction .41.1 Technical Reference Architecture Scope. 41.2 Component Definition . 41.3 Component-Based Solutions . 71.4 Technical Reference Architecture Users . 71.5 ICT And Business Problems addressed . 72. Technical Reference Architecture Focus.92.1 Technical Reference Architecture Focus . 93. Technical Reference Architecture Positioning .113.1 Business Strategy. 113.2 Logical Application Architecture. 113.3 Technical Infrastructure . 113.4 Technical Application Architecture. 124. Technical Reference Architecture Overview.134.1 Business Component Layering . 134.2 Business Components and State. 144.3 Integration of Function Components with Existing Applications . 164.4 Business Components and Workflow . 174.5 Component Invocation Models and Middleware. 185. Technical Reference Architecture Meta Models .245.1 Positioning. 245.2 Target Implementation Technologies. 245.3 Business Task Components . 255.4 Function Components . 295.5 The Complete Technical Reference Architecture & Security . 336. Supporting Infrastructure .356.1 Component Technologies. 356.2 Message Brokers. 366.3 Application Wrappers . 407. In Conclusion.418. Glossary of Terms .42COMCOR TECHNICAL REFERENCE ARCHITECTURE 3COMCOR2 OF 44
TECHNICAL REFERENCE ARCHITECTURE FOR CBD AND EAIFiguresFigure 1: Component Typology. 5Figure 2: Middleware Abstraction Through Layering . 6Figure 3: Middleware Abstraction through Runtime Software Components and Containers . 6Figure 4: Architecture . 11Figure 5: Technical Reference Architecture Business Component Layering . 13Figure 6: Technical Reference Architecture and Workflow Management . 18Figure 7: MOM Based Service Bus . 19Figure 8:Total View of Middleware. 23Figure 9: Business Task Component Meta Model. 24Figure 10: Function Component Meta Model . 29Figure 11: Function Component Granularity. 32Figure 12: Business Component Reference Architecture . 33Figure 13: Non-invasive Message Brokers. 37Figure 14: Super API Based Message Brokers . 37Author:Tim BarrettComCor I.T Solutions b.v.tim.barrett@comcor.nlT: 31 (0)24 6453345F: 31 (0)24 6453347COMCOR TECHNICAL REFERENCE ARCHITECTURE 3COMCOR3 OF 44
TECHNICAL REFERENCE ARCHITECTURE FOR CBD AND EAI1. IntroductionThis paper presents ComCor’s Technical Reference Architecture. This provides an architecturalreference for the construction and integration of Component-based Solutions. It providesanswers to crucial questions in the following areas:-The need to provide Business solutions which are both scalable and flexibleThe need to integrate new and already existing business solutions in a consistent, efficient,productive mannerThe need to define optimal physical and logical layering strategies1.1 Technical Reference Architecture ScopeThe reference architecture should be used widely within an enterprise for optimum effectiveness. Itshould be applied throughout an enterprise, or throughout a division or sub-division. If thearchitecture is used widely, then there will be a consistency of approach to the design, constructionand integration of business solutions. Concrete projects use this architecture as a reference. Itprovides a consistent foundation for these projects. Building on this foundation, it guides theprojects at a tactical level. Reference alone is not enough, the chosen architecture must articulatethe directions of technical change to be followed. This means that the technical referencearchitecture also has a strategic role within enterprises.The Technical Reference Architecture does not provide detailed coding guidelines, orrecommendations aimed at specific tools. It provides a starting point and reference for the creationof concrete, detailed designs. From these designs, component-based solutions are constructed,and integrated with existing solutions.1.2 Component DefinitionThe term component is used somewhat loosely within the software industry. The term can beapplied at three distinct levels. We consider it important to identify these levels, and apply a specificcomponent definition to each level. These definitions are then used consistently throughout the restof the document.1.2.1 Component Types-Objects are programming language constructions. Objects and components are relatedbecause the code in a COM or CORBA or Java component is usually a set of VB, C or JavaOO objects.-Runtime software components are packages of programs managed as a unit and accessedonly through interfaces. Runtime software components can be distributed – in other words theyrun in a middleware infrastructure. Com , Enterprise Java Beans (EJB), and CORC (CorbaComponent model) provide standard (and competing) component models for runtime softwarecomponents.-Business components are the logical design modules in a service-oriented architecture.These components may be developed on any platform using any technique. They provideservices through an interface. Business components are not necessarily built using runtimesoftware components, although this will tend to be the case in modern software developmentprojects. There are two types of Business Component: Business Task Components, whichCOMCOR TECHNICAL REFERENCE ARCHITECTURE 3COMCOR4 OF 44
TECHNICAL REFERENCE ARCHITECTURE FOR CBD AND EAIinteract directly with users in order to complete a set of logically related business tasks, andFunction Components, which provide transactional services related to a logical domain.These services are often closely concerned with the manipulation of data, and a Functioncomponent usually encapsulates persistent data. Component Based Solutions are thereforemade up of one or more Business Task components that orchestrate the use of Functioncomponents. Function components serve many masters. Many different types of BusinessTask component can use the same type of Function component.All three of these levels have one important feature in common – they all make services availablevia interfaces. This document is largely concerned with Business components, and the use ofruntime software components to build business components. We are also concerned with the needto allow existing (legacy) applications to project themselves as function components throughapplication wrapping techniques.Business Solution is made up of 1.*Business Component is built usingBusiness Task Componentis either aor aFunction Component1.*Runtime Software Component is built using 1.*ObjectFigure 1: Component Typology1.2.2 Runtime Software Component ContainersA runtime software component has to interact with its infrastructure (middleware) in order to solvethe problem of its clients. This is a problem, which hinders reuse and can make the componentunimplementable on other platforms. This problem is especially acute if the business logic whichthe component provides interacts directly with middleware.To alleviate this problem, the component should adhere to the container model. The containermodel provides a clear separation between the container, which interacts with middleware, and thebusiness solution provided by the component. A runtime software component developer providesthe business logic. The vendor of the component technology provides the interaction of acomponent with middleware. The container model allows technical issues, such as transactionalCOMCOR TECHNICAL REFERENCE ARCHITECTURE 3COMCOR5 OF 44
TECHNICAL REFERENCE ARCHITECTURE FOR CBD AND EAIbehavior and security, to become attributes of the container. These attributes can then beconfigured dynamically, as opposed to arranging them ‘somewhere’ in the business logic. Thecomponent developer can concentrate fully on providing the business solution. This is a shift fromthe time-honored technique of building abstraction layers above a technical platform andmiddleware (see figure 2).APPLICATION SPECIFIC CODEMIDDLEWARE ABSTRACTION LAYERVendor Supplied MiddlewareImplementation neutralmiddleware calls, e.g.‘encrypt message’Implementationmiddleware calls, usingAPIs provided byFigure 2: Middleware Abstraction Through LayeringUsually, the motivation for such layers is the perceived need to express middleware services, suchas security services in terms of a vendor independent set of services. Application logic calls theabstract services as opposed to calling the middleware directly. The potential advantage is theperceived independence of the business logic from the specific vendor’s middleware. Thisapproach, however, can give rise to a serious maintenance burden. The abstraction layer needs tobe maintained, supported, and kept up to date with the services supplied by product vendors. Often,extra services are provided above and beyond those supplied by the products upon which the layeris built. This exacerbates the maintenance burden. The abstraction layer is thus proprietary anddoes not solve a problem but instead can create a new maintenance problem.Component ContainerClientCOMPONENTINTERFACEIntercepts the client‘s call,interacts with technicalenvironment, and callsthe application logicComponentApplication LogicTechnicalFigure 3: Middleware Abstraction through Runtime Software Components and ContainersFigure 3 depicts the component/container approach. The runtime software component’s containerintercepts client calls and manages behavior such as the transaction mode, locking regime, andsecurity. This behavior is dynamic and can be configured at runtime. The programming model hasaltered quite radically. Instead of the abstraction layer calling the vendor specific middleware, thecontainer calls the application code inside the component.COMCOR TECHNICAL REFERENCE ARCHITECTURE 3COMCOR6 OF 44
TECHNICAL REFERENCE ARCHITECTURE FOR CBD AND EAI1.2.3 Runtime Software Component TechnologiesAt the time of writing two runtime software component technologies are prevalent. These are theComponent Object Model (COM ) from Microsoft, and the Enterprise Java Beans (EJB) modelfrom Sun et al. In addition to these two, the OMG is defining ‘CORC’, the CORBA componentmodel. We expect to see the first vendor implementations of the CORC model in early 2000.1.2.4 Business Components and Runtime Software ComponentsBusiness Components can be built in such a way that the spirit of component based development –which is all about having applications provide interfaces – is lived up to, without necessarily usingone of the industry standard runtime software component technologies to build the Businesscomponents. If a business application provides a clean set of callable services, which can be calledby any client or peer application, then this application could be said to be a ‘Business component’,especially if these callable services are the only way in which the application’s services can beaccessed. This interface centric definition of the term Business Component is important from thepoint of view of integration with existing applications. It also allows us to design and develop interms of components where large-scale mission critical applications are being constructed, forwhich the current runtime component technology products and standards such as COM, EJB andCORC do not yet provide a sufficiently robust and complete platform or sufficient performance.1.3 Component-Based SolutionsComponent-based solutions are characterized by:- A purely interface focused approach to the design and development of components at all threelevels (program objects, runtime software components and business components).- The provision of business solutions through the creation, extension, deployment and assemblyof business components.- The ability to distribute business components in a heterogeneous environment.- The use of various styles of communication between these components, including:- Synchronous method invocation- Deferred synchronous method invocation- Asynchronous communication (one way messages, and publish / subscribe messaging)- The provision of access to business components through various ‘channels’ (e.g. internet,intranet)1.4 Technical Reference Architecture UsersThe Technical Reference Architecture has been written for those involved in the design andconstruction of new component-based solutions, as well as those involved in the integration ofheterogeneous solutions of all types - new, purchased and already existing (legacy).1.5 ICT And Business Problems addressedThe Technical Reference Architecture addresses the following strategic problem areas:- The need for a standard, consistent approach to the construction of component basedsolutions- The need for a standard, effective approach to enterprise application integration- The need to select a runtime software component technology, and to correctly positionruntime software component technology.- The provision of technical architectural criteria to be applied to package acquisition- The provision of a migration strategy providing a framework for the gradual introduction andintegration of component based solutions, whether these are built in house or purchasedCOMCOR TECHNICAL REFERENCE ARCHITECTURE 3COMCOR7 OF 44
TECHNICAL REFERENCE ARCHITECTURE FOR CBD AND EAI-Achieving reuse and flexibility in IT solutions1.5.1 Potential BenefitsThe potential benefits of a consistent approach to the creation and integration of component- basedsolutions are: Flexibility: Components can be added without breaking the system Component behavior can be changed without breaking the system Component behavior can be changed quickly Presentation channel / Input device independence Backend (‘BackOffice’) application and database independence Productivity Business Solution Assembly - new business solutions are assembled from existing businesscomponents and new business components Invocational Reuse. Reuse in this model is not simply a matter of reusing code objects. Itfocuses on the provision of generally useful services which can be invoked by a variety ofdifferent business solutions in a variety of contexts. Existing applications can be rendered as reusable business components through theintegration architecture Reuse of intellectual content of the architecture - no need to reacquire knowledge Reuse of technical standards to be applied for package acquisition Highly productive languages can be applied - e.g. Java, Delphi as well as proven languagessuch as COBOL. Developers focus on providing solutions to business problems, as opposed to having to dealextensively with low-level middleware problems (especially if modern, runtime softwarecomponent technologies are used). Architectural approach to technology ensures that technology is a prime enabler of businessinnovationCOMCOR TECHNICAL REFERENCE ARCHITECTURE 3COMCOR8 OF 44
TECHNICAL REFERENCE ARCHITECTURE FOR CBD AND EAI2. Technical Reference Architecture FocusWe begin by describing the structure of a business solution as defined within the TechnicalReference Architecture.The reference architecture exhibits service centricity, that is the focus is on distributed services,with ‘thin’ clients and a positioning of databases not simplistically as the third tier in a three tierarchitecture, but as a method of resource management within a shared resource layer. Otherresource management approaches such as message queuing and pathways to legacy applicationsare also recognized within this layer. Another major feature of the architecture is the attention paidto the automation of business tasks. We suggest that automated support of business tasks must behighly dynamic and event driven, because real life business tasks exhibit these attributes. Anotherfocus area is that of application integration. Most enterprises today suffer from application spaghetti- that is a large amount of difficult to manage ad hoc interfaces between heterogeneousapplications on heterogeneous platforms. We describe an application wrapping architecture, as wellas vital tools (application wrappers, message brokers and supporting middleware) which if usedwell can significantly reduce this interface burden.We then turn to the Technical Infrastructure services vital to any Technical Reference Architecturebased solution. We focus on component technologies, message brokers, applicationwrappers and communications middleware.2.1 Technical Reference Architecture FocusThe Technical Reference Architecture focuses on the following key areas:-The Construction Architecture to be used for the d
TECHNICAL REFERENCE ARCHITECTURE FOR CBD AND EAI COMCOR TECHNICAL REFERENCE ARCHITECTURE 3 COMCOR 4 OF 44 1. Introduction This paper presents ComCor’s Technical Reference Architecture. This provides an architectural reference for the construction and integration of Component-based Solut
1. The need for an agile way of working 6 2. The need for an agile way of working 9 3. Agile Core Values - Agile Project Management Vs. 10 Agile Event Management 4. Agile principles 12 _Agile Principles of Agile Project Management 13 _Agile Principles of VOK DAMS Agile Event Management 14 5. Agile Methods 16 _Scrum in Short 16 _Kanban in Short 18
1.1 Purpose of the Agile Extension to the BABOK Guide1 1.2 What is Agile Business Analysis?2 1.3 Structure6 Chapter 2:The Agile Mindset 2.1 What is an Agile Mindset?7 2.2 The Agile Mindset, Methodologies, and Frameworks8 2.3 Applying the Agile Mindset9 2.4 Agile Extension and the Agile Ma
Agile Estimating and Planning by Mike Cohn Agile Game Development with Scrum by Clinton Keith Agile Product Ownership by Roman Pichler Agile Project Management with Scrum by Ken Schwaber Agile Retrospectives by Esther Derby and Diana Larsen Agile Testing: A Practical Guide for Testers and Agile Teams by Lisa Crispin and .
Agile World View "Agility" has manydimensions other than IT It ranges from leadership to technological agility Today's focus is on organizational & enterprise agility Agile Leaders Agile Organization Change Agile Acquisition & Contracting Agile Strategic Planning Agile Capability Analysis Agile Program Management Agile Tech.
The most popular agile methodologies include: extreme programming (XP), Scrum, Crystal, Dynamic Sys-tems Development (DSDM), Lean Development, and Feature Driven Development (FDD). All Agile methods share a common vision and core values of the Agile Manifesto. Agile Methods: Some well-known agile software development methods include: Agile .
1. Agile methods are undisciplined and not measurable. 2. Agile methods have no project management. 3. Agile methods apply only to software development. 4. Agile methods have no documentation. 5. Agile methods have no requirements. 6. Agile methods only work with small colocated teams.-7. Agile methods do not include planning. 8.
The Agile Customer . 9/6/2012 6 Agile Development Team Agile Analyst . 9/6/2012 7 Agile Programmer Agile Tester . 9/6/2012 8 Agile Manager Agile Usability Designer . 9/6/2012 9 Kicking off a project The Inception Deck –Ten questions you’d be crazy not to ask before starting any
Am I my Brother’s Keeper? Sibling Spillover E ects: The Case of Developmental Disabilities and Externalizing Behavior Jason Fletcher, Nicole Hair, and Barbara Wolfe July 27, 2012 Abstract Using a sample of sibling pairs from the PSID-CDS, we examine the e ects of sibling health status on early educational outcomes. We nd that sibling developmental dis- ability and externalizing behavior are .
