DOCSLIB.ORG

1 Layered Architecture

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
1 Layered Architecture e-gov Architecture Application Architecture 1 Layered Architecture ................................................................................. 3 1.1 Introduction ..................................................................................... 3 1.2 Best practices................................................................................... 3 1.2.1 Choose a layered architecture ......................................................... 3 1.2.2 Apply design patterns to layer the architeture.................................... 6 2 Domain Layer .......................................................................................... 8 2.1 Introduction ..................................................................................... 8 2.2 Best practices................................................................................... 8 2.2.1 Introduce a domain layer in the architecture...................................... 8 2.2.2 Apply design patterns on the domain layer ........................................ 9 2.2.3 Utilize the full power of OO ............................................................10 2.2.4 Avoid the anemic domain model .....................................................10 2.2.5 Minimize the dependencies with other layers ....................................10 2.2.6 Unit test the domain layer..............................................................10 3 Service Layer..........................................................................................11 3.1 Introduction ....................................................................................11 3.2 Best practices..................................................................................11 3.2.1 Introduce a session façade in the architecture ..................................12 3.2.2 Introduce Business Delegates in the architecture...............................14 3.2.3 Introduce a Service Locator in the architecture .................................15 3.2.4 Apply Inversion of Control (IoC) .....................................................16 3.2.5 Avoid storing all business logic in the service layer. ...........................18 3.2.6 Use the service layer as an alternative entry point.............................18 3.2.7 Integration with the PersistenceLayer ..............................................20 3.2.8 Handle transactions in the Service Layer ..........................................20 3.2.9 Handling security in the Service Layer .............................................20 4 Persistence Layer ....................................................................................21 4.1 Problem..........................................................................................21 4.2 Solution..........................................................................................21 4.3 Best practices..................................................................................22 4.3.1 Understand the difference between the object and the RDBMS Model ...22 4.3.2 OO Model != existing RDBMS model ................................................22 4.3.3 Different object models can map to the same data model...................23 4.3.4 Leverage O/R Mapping tools...........................................................23 4.3.5 Use Object Inheritance Mapping where possible ................................23 4.3.6 Object relationship Mapping ...........................................................25 4.3.7 Buy vs build.................................................................................25 4.4 Persistence Frameworks....................................................................25 4.4.1 Java Data Objects (JDO)................................................................25 4.4.2 Enterprise Java Beans 2.x..............................................................26 4.4.3 Enterprise Java Beans 3 ................................................................27 4.4.4 Hibernate ....................................................................................28 4.4.5 Other J2EE/J2SE Persistence frameworks .........................................28 4.4.6 ADO.NET .....................................................................................28 4.4.7 Other .NET Persistence frameworks.................................................28 1 e-gov Architecture Application Architecture 5 Presentation Layer...................................................................................30 5.1 Introduction ....................................................................................30 5.2 Best practices..................................................................................30 5.3 Apply presentation tier design patterns ...............................................31 5.4 Best Practices..................................................................................32 5.4.1 Build upon an existing presentation framework .................................32 5.4.2 Choose a corporate standard..........................................................32 5.4.3 Develop with portal integration in mind............................................32 5.4.4 Have a strategic vision to integrate external applications into the corporate portal. .....................................................................................33 5.4.5 Add existing applications to the corporate Portal ...............................34 5.4.6 ASP.NET......................................................................................34 5.5 Presentation Frameworks ..................................................................35 5.5.1 Evolution of presentation frameworks in the J2EE space. ....................35 5.5.2 Java Server Faces (JSF).................................................................36 5.5.3 Apache Struts ..............................................................................37 5.5.4 Spring Web MVC...........................................................................38 5.5.5 WebWork ....................................................................................38 6 Overall design considerations ....................................................................40 6.1 Introduction ....................................................................................40 6.2 Best practices..................................................................................40 6.2.1 Minimize Network roundtrips ..........................................................40 6.2.2 Design patterns............................................................................40 6.2.3 Centralize Business Logic...............................................................42 6.2.4 Moving between tiers ....................................................................43 6.2.5 Design Patterns............................................................................43 6.3 Transactions ...................................................................................47 6.4 Exception handling...........................................................................47 6.5 Managing State ...............................................................................47 7 Managing the code base ...........................................................................48 7.1 Introduction ....................................................................................48 7.2 Best practices..................................................................................48 7.2.1 Setup sub projects in the development environment..........................48 7.2.2 Standardize the development environment.......................................48 7.2.3 Promote reuse through the sub projects...........................................48 7.2.4 Manage dependencies between the sub projects ...............................48 7.2.5 Apply a Modular approach to the development environment................49 7.2.6 Conclusion...................................................................................50 2 e-gov Architecture Application Architecture 1 Layered Architecture 1.1 Introduction Most enterprise applications are composed of a large number of components throughout the environment. In addition to that, these components often have different levels of abstraction. In order to adhere to the ever changing business requirements, how can we come up with an application architecture that supports: • Maintainability • Reusability • Scalability • Robustness • Security 1.2 Best practices This application architecture should: • Promote separation of concerns among the components in the architecture (Separating the user interface from the business logic , and the business logic from the data store) • Allow for changes to one part of the architecture to have a minimal impact on others parts. For example, changing a web interface should only have an impact on the user interface part of the application. • Promote reuse; components should follow the Low Coupling / High Cohesion pattern. o Individual components should be cohesive. o Unrelated components should be loosely coupled. • Allow for the different components of the architecture to be deployable independently • Allow for the different components of the architecture to be testable independently • Support the physical distribution across different tiers 1.2.1 Choose a layered architecture We need to separate the various components within the architecture into logical and technical layers. Components in a particular layer: • Should have
Load more

Recommended publications
  • 1. Domain Modeling
    Software design pattern seminar sse, ustc Topic 8 Observer, Mediator, Facade Group K 1. The observer pattern (Behavioral pattern, chapter 16 and 17) 1) the observer is an interface or abstract class defining the operations to be used to update itself 2) a solution to these problems A. Decouple change and related responses so that such dependencies can be added or removed freely and dynamically 3) solution A. Observable defines the operations for attaching, de-attaching and notifying observers B. Observer defines the operations to update itself 4) liabilities A. Unwanted concurrent update to a concrete observable may occur Figure 1 Sample Observer Pattern 2. The mediator pattern (Behavioral pattern, chapter 16 and 17) 1) the mediator encapsulates how a set of objects interact and keeps objects from referring to each other explicitly 2) a solution to these problems A. a set of objects communicate in well-defined but complex ways. The resulting interdependencies are unstructured and difficult to understand B. reusing an object is difficult because it refers to and communicates with many other objects C. a behavior that's distributed between several classes should be customizable without a lot of subclassing 3) solution A. Mediator defines an interface for communicating with Colleague objects, knows the colleague classes and keep a reference to the colleague objects, and implements the communication and transfer the messages between the colleague classes 1 Software design pattern seminar sse, ustc B. Colleague classes keep a reference to its Mediator object, and communicates with the Mediator whenever it would have otherwise communicated with another Colleague 4) liabilities A.
    [Show full text]
  • Ioc Containers in Spring
    301AA - Advanced Programming Lecturer: Andrea Corradini [email protected] http://pages.di.unipi.it/corradini/ AP-2018-11: Frameworks and Inversion of Control Frameworks and Inversion of Control • Recap: JavaBeans as Components • Frameworks, Component Frameworks and their features • Frameworks vs IDEs • Inversion of Control and Containers • Frameworks vs Libraries • Decoupling Components • Dependency Injection • IoC Containers in Spring 2 Components: a recap A software component is a unit of composition with contractually specified interfaces and explicit context dependencies only. A software component can be deployed independently and is subject to composition by third party. Clemens Szyperski, ECOOP 1996 • Examples: Java Beans, CLR Assemblies • Contractually specified interfaces: events, methods and properties • Explicit context dependencies: serializable, constructor with no argument • Subject to composition: connection to other beans – Using connection oriented programming (event source and listeners/delegates) 3 Towards Component Frameworks • Software Framework: A collection of common code providing generic functionality that can be selectively overridden or specialized by user code providing specific functionality • Application Framework: A software framework used to implement the standard structure of an application for a specific development environment. • Examples: – GUI Frameworks – Web Frameworks – Concurrency Frameworks 4 Examples of Frameworks Web Application Frameworks GUI Toolkits 5 Examples: General Software Frameworks – .NET – Windows platform. Provides language interoperability – Android SDK – Supports development of apps in Java (but does not use a JVM!) – Cocoa – Apple’s native OO API for macOS. Includes C standard library and the Objective-C runtime. – Eclipse – Cross-platform, easily extensible IDE with plugins 6 Examples: GUI Frameworks • Frameworks for Application with GUI – MFC - Microsoft Foundation Class Library.
    [Show full text]
  • Design Pattern Interview Questions
    DDEESSIIGGNN PPAATTTTEERRNN -- IINNTTEERRVVIIEEWW QQUUEESSTTIIOONNSS http://www.tutorialspoint.com/design_pattern/design_pattern_interview_questions.htm Copyright © tutorialspoint.com Dear readers, these Design Pattern Interview Questions have been designed specially to get you acquainted with the nature of questions you may encounter during your interview for the subject of Design Pattern. As per my experience good interviewers hardly plan to ask any particular question during your interview, normally questions start with some basic concept of the subject and later they continue based on further discussion and what you answer: What are Design Patterns? Design patterns represent the best practices used by experienced object-oriented software developers. Design patterns are solutions to general problems that software developers faced during software development. These solutions were obtained by trial and error by numerous software developers over quite a substantial period of time. What is Gang of Four GOF? In 1994, four authors Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides published a book titled Design Patterns - Elements of Reusable Object-Oriented Software which initiated the concept of Design Pattern in Software development. These authors are collectively known as Gang of Four GOF. Name types of Design Patterns? Design patterns can be classified in three categories: Creational, Structural and Behavioral patterns. Creational Patterns - These design patterns provide a way to create objects while hiding the creation logic, rather than instantiating objects directly using new opreator. This gives program more flexibility in deciding which objects need to be created for a given use case. Structural Patterns - These design patterns concern class and object composition. Concept of inheritance is used to compose interfaces and define ways to compose objects to obtain new functionalities.
    [Show full text]
  • Dependency Injection with Unity
    D EPEN DEPENDENCY INJECTION WITH UNITY Over the years software systems have evolutionarily become more and more patterns & practices D ENCY complex. One of the techniques for dealing with this inherent complexity Proven practices for predictable results of software systems is dependency injection – a design pattern that I allows the removal of hard-coded dependencies and makes it possible to Save time and reduce risk on your NJECT assemble a service by changing dependencies easily, whether at run-time software development projects by or compile-time. It promotes code reuse and loosely-coupled design which incorporating patterns & practices, I leads to more easily maintainable and flexible code. Microsoft’s applied engineering ON guidance that includes both production The guide you are holding in your hands is a primer on using dependency quality source code and documentation. W I injection with Unity – a lightweight extensible dependency injection TH DEPENDENCY INJECTION container built by the Microsoft patterns & practices team. It covers The guidance is designed to help U software development teams: various styles of dependency injection and also additional capabilities N I of Unity container, such as object lifetime management, interception, Make critical design and technology TY and registration by convention. It also discusses the advanced topics of selection decisions by highlighting WITH UNITY enhancing Unity with your custom extensions. the appropriate solution architectures, technologies, and Microsoft products The guide contains plenty of trade-off discussions and tips and tricks for for common scenarios managing your application cross-cutting concerns and making the most out of both dependency injection and Unity. These are accompanied by a Understand the most important Dominic Betts real world example that will help you master the techniques.
    [Show full text]
  • Designpatternsphp Documentation Release 1.0
    DesignPatternsPHP Documentation Release 1.0 Dominik Liebler and contributors Jul 18, 2021 Contents 1 Patterns 3 1.1 Creational................................................3 1.1.1 Abstract Factory........................................3 1.1.2 Builder.............................................8 1.1.3 Factory Method......................................... 13 1.1.4 Pool............................................... 18 1.1.5 Prototype............................................ 21 1.1.6 Simple Factory......................................... 24 1.1.7 Singleton............................................ 26 1.1.8 Static Factory.......................................... 28 1.2 Structural................................................. 30 1.2.1 Adapter / Wrapper....................................... 31 1.2.2 Bridge.............................................. 35 1.2.3 Composite............................................ 39 1.2.4 Data Mapper.......................................... 42 1.2.5 Decorator............................................ 46 1.2.6 Dependency Injection...................................... 50 1.2.7 Facade.............................................. 53 1.2.8 Fluent Interface......................................... 56 1.2.9 Flyweight............................................ 59 1.2.10 Proxy.............................................. 62 1.2.11 Registry............................................. 66 1.3 Behavioral................................................ 69 1.3.1 Chain Of Responsibilities...................................
    [Show full text]
  • JAVA CONCURRENCY ONLINE TRAINING – Java2aspire
    JAVA CONCURRENCY, JAVA PROFILING, THREAD POOLING, JAVA 8 Features, MAVEN and DESIGN PATTERNS ONLINE TRAINING By K.Ramesh Curriculum THREAD POOLING Day 01: Executor Framework 20 min Day 01: Java Profiling 10 min Day 01: Executor 10 min Day 01: ExecutorService 10 min Day 01: Executors 15 min Day 02: ThreadPoolExecutor 20 min Day 02: BlockingQueue 10 min Day 02: Callable vs Runnable 15 min Day 02: Future 15 min JAVA CONCURRENCY Day 03: ConcurrentHashMap 30 min Day 03: Producer Consumer 30 min Day 04: CountDownLatch 20 min Day 04: CyclicBarrier 20 min Day 04: Deadlock Condition 20 min Day 05: Race Condition 30 min Day 05: Semaphore 30 min JAVA 8 FEATURES Day 06: Lambda Expressions 40 min Day 06: Functional Interfaces 10 min Day 06: Functional Programming 10 min Day 07: Method References 10 min Day 07: Default Methods 40 min Day 07: Optional 10 min Day 08: Stream API 1 hour MAVEN Day 09: Project Object Model (POM) 20 min Day 09: Project Description 10 min Day 09: Public Repository 10 min Day 09: Dependency Management 10 min Day 09: Build Configuration 10 min Day 10: Installation 15 min Day 10: Dependency Scope 15 min Day 10: Proprietary Dependencies 15 min Day 10: Project Inheritance 15 min Day 11: Maven life cycle 20 min Day 11: Maven Directory Structure 20 min Day 11: Archetypes 20 min Day 12: Applications 1 hour DESIGN PATTERNS Day 13: Factory Pattern 20 min Day 13: Abstract Factory Pattern 10 min Day 13: Single Pattern 20 min Day 13: Prototype Pattern 10 min Day 14: Composite Pattern 10 min Day 14: Facade Pattern 15 min Day 14: DAO
    [Show full text]
  • Design Patterns in Ocaml
    Design Patterns in OCaml Antonio Vicente [email protected] Earl Wagner [email protected] Abstract The GOF Design Patterns book is an important piece of any professional programmer's library. These patterns are generally considered to be an indication of good design and development practices. By giving an implementation of these patterns in OCaml we expected to better understand the importance of OCaml's advanced language features and provide other developers with an implementation of these familiar concepts in order to reduce the effort required to learn this language. As in the case of Smalltalk and Scheme+GLOS, OCaml's higher order features allows for simple elegant implementation of some of the patterns while others were much harder due to the OCaml's restrictive type system. 1 Contents 1 Background and Motivation 3 2 Results and Evaluation 3 3 Lessons Learned and Conclusions 4 4 Creational Patterns 5 4.1 Abstract Factory . 5 4.2 Builder . 6 4.3 Factory Method . 6 4.4 Prototype . 7 4.5 Singleton . 8 5 Structural Patterns 8 5.1 Adapter . 8 5.2 Bridge . 8 5.3 Composite . 8 5.4 Decorator . 9 5.5 Facade . 10 5.6 Flyweight . 10 5.7 Proxy . 10 6 Behavior Patterns 11 6.1 Chain of Responsibility . 11 6.2 Command . 12 6.3 Interpreter . 13 6.4 Iterator . 13 6.5 Mediator . 13 6.6 Memento . 13 6.7 Observer . 13 6.8 State . 14 6.9 Strategy . 15 6.10 Template Method . 15 6.11 Visitor . 15 7 References 18 2 1 Background and Motivation Throughout this course we have seen many examples of methodologies and tools that can be used to reduce the burden of working in a software project.
    [Show full text]
  • Semantic Description of Services and Service Factories for Ambient Intelligence Rémi Emonet
    Semantic Description of Services and Service Factories for Ambient Intelligence Rémi Emonet To cite this version: Rémi Emonet. Semantic Description of Services and Service Factories for Ambient Intelligence. Soft- ware Engineering [cs.SE]. Institut National Polytechnique de Grenoble - INPG, 2009. English. tel- 00450479 HAL Id: tel-00450479 https://tel.archives-ouvertes.fr/tel-00450479 Submitted on 26 Jan 2010 HAL is a multi-disciplinary open access L’archive ouverte pluridisciplinaire HAL, est archive for the deposit and dissemination of sci- destinée au dépôt et à la diffusion de documents entific research documents, whether they are pub- scientifiques de niveau recherche, publiés ou non, lished or not. The documents may come from émanant des établissements d’enseignement et de teaching and research institutions in France or recherche français ou étrangers, des laboratoires abroad, or from public or private research centers. publics ou privés. GRENOBLE INP n◦ attribu´epar la biblioth`eque THESE` pour obtenir le grade de ❉♦❝❡✉ ❉✉ ●♦✉♣❡ ●❡♥♦❜❧❡ ■◆ Sp´ecialit´e: Informatique pr´epar´eeau Laboratoire d’Informatique de Grenoble dans le cadre de l’Ecole´ Doctorale Math´ematiques, Sciences et Technologies de l’Information, Informatique pr´esent´eeet soutenue publiquement par R´emi ❊♠♦♥❡ le 23 septembre 2009 ❉❡❝✐♣✐♦♥ ❙♠❛♥✐✉❡ ❞❡ ❙❡✈✐❝❡ ❡ ❞✬❯✐♥❡ à ❙❡✈✐❝❡ ♣♦✉ ❧✬■♥❡❧❧✐❣❡♥❝❡ ❆♠❜✐❛♥❡ ❙❡♠❛♥✐❝ ❉❡❝✐♣✐♦♥ ♦❢ ❙❡✈✐❝❡ ❛♥❞ ❙❡✈✐❝❡ ❋❛❝♦✐❡ ❢♦ ❆♠❜✐❡♥ ■♥❡❧❧✐❣❡♥❝❡ Directeur de th`ese : James L. ❈♦✇❧❡② Co-directeur de th`ese : Dominique ❱❛✉❢❡②❞❛③ JURY Pr. Marie-Christine Rousset Pr´esident Pr. James L. Crowley Directeur de th`ese Dr. Dominique Vaufreydaz Co-directeur de th`ese Pr. Gregory D. Abowd Rapporteur Pr. David Simplot-Ryl Rapporteur Pr. Michel Riveill Examinateur 2 R´esum´e Ce manuscrit ´etudie l’ad´equation des approches `aservices, ainsi que leur am´elioration, pour l’int´egration dynamique et la r´eutilisation logicielle dans le cadre de l’informatique ambiante.
    [Show full text]
  • Sun Certified Enterprise Architect for Java EE Study Guide / Mark Cade, Humphrey Sheil
    Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in this book, and the publisher was aware of a trademark claim, the designations have been printed with initial capital letters or in all capitals. Sun Microsystems, Inc. has intellectual property rights relating to implementations of the technology described in this publication. In particular, and without limitation, these intellectual property rights may include one or more U.S. patents, foreign patents, or pending applications. Sun, Sun Microsystems, the Sun logo, J2ME, J2EE, Java Card, and all Sun and Java based trademarks and logos are trademarks or registered trademarks of Sun Microsystems, Inc., in the United States and other countries. UNIX is a registered trademark in the United States and other countries, exclusively licensed through X/Open Company, Ltd. This publication is provided “as is” without warranty of any kind, either express or implied, including, but not limited to, the implied warranties of merchantability, fitness for a particular purpose, or non-infringement. This publication could include technical inaccuracies or typographical errors. Changes are periodically added to the information herein; these changes will be incorporated in new editions of the publication. Sun Microsystems, Inc. may make improvements and/or changes in the product(s) and/or the program(s) described in this publication at any time. The authors and publisher have taken care in the preparation of this book, but make no expressed or implied warranty of any kind and assume no responsibility for errors or omissions. No liability is assumed for incidental or consequential damages in connection with or arising out of the use of the information or programs contained herein.
    [Show full text]
  • Secure Telemedicine System for Home Health Care
    Graduate Theses, Dissertations, and Problem Reports 2000 Secure telemedicine system for home health care Sridhar Vasudevan West Virginia University Follow this and additional works at: https://researchrepository.wvu.edu/etd Recommended Citation Vasudevan, Sridhar, "Secure telemedicine system for home health care" (2000). Graduate Theses, Dissertations, and Problem Reports. 1099. https://researchrepository.wvu.edu/etd/1099 This Thesis is protected by copyright and/or related rights. It has been brought to you by the The Research Repository @ WVU with permission from the rights-holder(s). You are free to use this Thesis in any way that is permitted by the copyright and related rights legislation that applies to your use. For other uses you must obtain permission from the rights-holder(s) directly, unless additional rights are indicated by a Creative Commons license in the record and/ or on the work itself. This Thesis has been accepted for inclusion in WVU Graduate Theses, Dissertations, and Problem Reports collection by an authorized administrator of The Research Repository @ WVU. For more information, please contact [email protected]. SECURE TELEMEDICINE SYSTEM FOR HOME HEALTH CARE Sridhar Vasudevan Thesis submitted to the College of Engineering and Mineral Resources at West Virginia University in partial fulfillment of the requirements for the degree of Master of Science in Computer Science V.Jagannathan, Ph.D., Chair Sumitra Reddy, Ph.D. James D. Mooney, Ph.D. Department of Computer Science and Electrical Engineering Morgantown, West Virginia 2000 Keywords: EJB, Java, Home Health Care, Telemedicine SECURE TELEMEDICINE SYSTEM FOR HOME HEALTH CARE Sridhar Vasudevan ABSTRACT This thesis describes a low-cost telemedicine system that provides home based patient care by linking patients with skilled nurses at the home care agency.
    [Show full text]
  • Java Design Patterns I
    Java Design Patterns i Java Design Patterns Java Design Patterns ii Contents 1 Introduction to Design Patterns 1 1.1 Introduction......................................................1 1.2 What are Design Patterns...............................................1 1.3 Why use them.....................................................2 1.4 How to select and use one...............................................2 1.5 Categorization of patterns...............................................3 1.5.1 Creational patterns..............................................3 1.5.2 Structural patterns..............................................3 1.5.3 Behavior patterns...............................................3 2 Adapter Design Pattern 5 2.1 Adapter Pattern....................................................5 2.2 An Adapter to rescue.................................................6 2.3 Solution to the problem................................................7 2.4 Class Adapter..................................................... 11 2.5 When to use Adapter Pattern............................................. 12 2.6 Download the Source Code.............................................. 12 3 Facade Design Pattern 13 3.1 Introduction...................................................... 13 3.2 What is the Facade Pattern.............................................. 13 3.3 Solution to the problem................................................ 14 3.4 Use of the Facade Pattern............................................... 16 3.5 Download the Source Code.............................................
    [Show full text]
  • J2EE Architecture and Patterns in Enterprise Systems
    J2EE Architecture and Patterns in Enterprise Systems Zhiguo Guo University of Tampere Department of Computer and Information Science Master’s Thesis May 2004 i University of Tampere Department of Computer and Information Science Zhiguo Guo: J2EE Architecture and Patterns in Enterprise Systems Master’s Thesis, 60 pages May 2004 The purpose of this thesis is to illustrate an enterprise project named HUVA, in which Java Platform 2, Enterprise Edition (J2EE) architecture and patterns are applied. This study took a constructive research approach: It starts from the application domain including the initial plan and business model, then moves to the system architecture covering the architecturally significant requirements and the system structure compliant with J2EE architecture, finally ends at the application design elaborated by applying the J2EE patterns at a high level. As a result the architectural and application design satisfied the project needs and requirements; and the HUVA software has been implemented in practice according to the design. Keywords: J2EE, architecture, pattern, enterprise system. ii Acknowledgements I would like to thank Professor Roope Raisamo and Professor Isto Aho from the University of Tampere for being my encouraging, patient and responsible supervisors during the master’s thesis project. I would like to thank Mr. Mika Miettinen from Solteq Oyj and Mr. Timo Westkämper for supporting the technical aspects of this thesis. Finally, I would like to use this opportunity to express huge thanks to my dear wife, Chongliang Tang for always being the invaluable person behind my success. Tampere - Finland, June 1st, 2004 Zhiguo Guo iii Contents 1. Introduction.............................................................................................................1 2. Application domain ...............................................................................................3 2.1.
    [Show full text]