Skyway Builder Developer's Guide

Transcription

1 Skyway Builder Developer's Guide June 24, 2008 Skyway Software

2 Skyway Builder Developer's Guide: June 24, 2008 Skyway Software Published Copyright 2008 Skyway Software Abstract Skyway Builder, a component of Skyway Visual Perspectives, is a model-driven development and deployment platform that enables developers to build and deliver Rich Internet Applications (RIAs) and Web Services faster using the Spring Framework with Hibernate for data persistence. This user guide is intended to introduce users to the Skyway Builder environment and introduce the general development approach and design options. The Skyway Builder embedded help will describe the steps and configuration options in more detail, and it is recommended as a companion to this user guide.

3

4 Table of Contents 1. Skyway Visual Perspectives Skyway Builder Architecture Overview Design-time Architecture Key Technologies Used Execution-time Architecture Deployment Key Technologies Used Environment Overview Eclipse Concepts Skyway Builder Versions Skyway Buider's Eclipse-based Components Skyway Views Skyway Toolbars and Menus Editors Application Development Skyway Development Artifacts Project Meta-data Model Application Layering Web Layer Service Layer Data Layer Development Process Development Steps Create Project Projects Project Configurations General Info Project Variables Project Constants View Mappings Data Layer Domain Model Implementing the Domain Model Basic Data Types Data Types Defining Fields Defining Relationships Persistence Mapping Data Stores Data Operations Named Queries Leveraging Existing Databases Importing Types Using Data Types from Other Sources Java Beans Web Services Service Layer Skyway Service Operations Operation Interface iv

5 Skyway Builder Developer's Guide 2.2. Operation Resources Recursion Actions Steps Custom Java Code Embedding Java Code Calling Java Libraries Using Groovy Web Services Consume Web Services Produce Web Services - Model First Development Produce Web Services - Contract First Development Building Web Layer Web Controllers URL Action Mapping Web Conversations Variables Constants Actions Steps Building Views JSP Pages Web Controls Using CSS Integrating additional web resources Model-View-Controller Model-View-Controller Layers Model-View-Controller Interactions UI Composition Patterns Page Centric Pattern Page Composition Pattern Page Flow Patterns Page-to-Page Pattern Page-to-Action Pattern Page Composition Pattern Page Composition (AJAX) Pattern Deploying Applications Deployment Explained Runtime Architecture Deployment Models Community Edition Deployment Options Option Option Enterprise Edition Deployment Options Option Option Changing Databases Run Application Security Securing Project Resources Securing Services Authorization... v

6 List of Figures Skyway Visual Perspectives... 1 Design-time Architecture... 2 Execution-time Architecture... 4 Web Only Deployment (WAR)... 5 Full JEE Deployment (EAR/WAR/EJB3)... 5 Skyway Toolbar Project Meta-Data Model Skyway Navigator Application Layers - High-Level Development Steps Overview Domain Model (Banking Example) Data Types (Banking Example) Data Stores (Banking Example) Skyway Service Operations Operation Actions Skyway Builder CE - Action Steps Skyway Web Controller Conversation Conversation Example: Survey Entry Web Conversation Actions Skyway Conversation - Action Steps Skyway Site Page Centric Pattern Page Composition Pattern Page Flow Patterns vi

7 List of Tables Skyway Builder Editions... 9 Skyway Builder Distribution/Download Methods... 9 Skyway Basic Data Types Relationship Types JPA Query Examples Comparison of Native and External Data Models Scenarios for using external data models Step Group: Data Manipulation Steps Step Group: Service Steps Step Group: Flow Steps Step Group: Exception Steps Step Group: Transaction Management Steps Web Service WSDL to Skyway Mappings Request Mapping Parameters Request Mapping Parameter Examples Skyway Web Controls - Part Skyway Web Controls - Part Event Descriptions Skyway Commands - Part Skyway Commands - Part vii

8 List of Examples Event and Command - JSP Fragment... Linking to external CSS files... Linking to images... Linking to javascript libraries... viii

9 Chapter 1. Skyway Visual Perspectives Skyway Visual Perspectives (SVP) is a family of Eclipse-based tools, and SVP aims to deliver an easyto-use environment where developers from any background can build rich user interfaces, applications, and services that leverage existing assets and are designed from the ground up for an Service Oriented Archtiecture (SOA) ecosystem. Figure 1.1. Skyway Visual Perspectives 1. Skyway Builder Skyway Builder, fully integrated into Eclipse, is a model-driven development and deployment platform that enables organizations to build and deliver Rich Internet Applications (RIAs) and Web services faster than ever before. With Skyway Builder you can gather requirements visually for maximum accuracy, build the solution quickly using models, and deploy RIAs to the most common open-source application servers at the push of a button. Developers maintain maximum design and development flexibility via modeling capabilities or via traditional coding techniques in their efforts to build rich and meaningful web applications because they are no longer bogged down by the redundant, tedious tasks of today s software delivery. Solutions built with Skyway Community Edition (CE) are based on common Eclipse standards, including EMF, GMF, and WTP, and all solutions are deployed using the Spring Framework with Hibernate data persistence. 1

10 Chapter 2. Architecture Overview 1. Design-time Architecture Skyway Visual Workspace is a set of Eclipse plugins. Eclipse provides a workspace where Skyway Builder's functionality can run side-by-side with plugins from other sources. In addition to leveraging the Eclipse plug-in architecture, Skyway Builder is implemented using the technology of various other Eclipse technologies, including the Eclipse Modeling Project, the Web Tools Project, and the Data Tools Project. Each will be described in more detail next. Figure 2.1. Design-time Architecture 1.1. Key Technologies Used This is a listing and brief description of the key design time technologies used by Skyway Builder Eclipse IDE and Workspace Skyway Builder leverages the Eclipse plugin architecture for adding modeling capabilities to Eclipse. Eclipse Web Tools Platform Project Site [ 2

11 Architecture Overview Eclipse Modeling Framework (EMF) Project Skyway Builder leverages a lot of Eclipse technologies. While EMF is a general purpose modeling framework, Skyway is an instantiation of EMF specifically targetted at web applications (including RIA) and web services. The EMF project is a modeling framework and code generation facility for building tools and other applications based on a structured data model. From a model specification described in XMI, EMF provides tools and runtime support to produce a set of Java classes for the model, along with a set of adapter classes that enable viewing and command-based editing of the model, and a basic editor. EMF Project Site [ Eclipse Web Tools Platform (WTP) Project The Eclipse Web Tools Platform (WTP) project extends the Eclipse platform with tools for developing Web and Java EE applications. It includes source and graphical editors for a variety of languages, wizards and built-in applications to simplify development, and tools and APIs to support deploying, running, and testing apps. Eclipse Web Tools Platform Project Site [ Eclipse Data Tools Project (DTP) For database connections Eclipse JEE Tools Project Site [ 2. Execution-time Architecture Skyway Builder generates ready-to-run Spring-based web applications and services. The generated applications, which can be deployed to open-source and commercial JEE application servers, make extensive of Spring technologies and projects, including Spring Core and spring MVC. 3

12 Architecture Overview Figure 2.2. Execution-time Architecture 2.1. Deployment The development artifacts used in model-centric development with Skyway Builder are higher-level development concepts than JEE. While these artifacts will ultimately be generated and deployed as JEE components, familiarity with JEE components isn't required when developing with Skyway Builder. In JEE there are essentially two deployment scenarios, web-only and web/ejb3, and Skyway Builder supports both deployment scenarios. Unlike typical JEE development, the deployment scenario doesn't need to be determined at the beginning of the development process. A developer will build the application in exactly the same manner, and the deployment will be configured when the application is ready to run. Whether a developer is deploying to a sandbox or to a production server, the process is exactly the same. The developer will specify the runtime infrastructure, and the models will be generated into JEE applications matching the configured infrastructure Web Only Deployment (WAR) Web-only deployments (WAR), which has been popularized by the Spring framework, consists of deploying applications to a servlet container and augmenting the application with transaction management and persistence functions. 4

13 Architecture Overview Figure 2.3. Web Only Deployment (WAR) Full JEE Deployment (EAR/WAR/EJB3) Full JEE deployment is a configuration where components are distributed between the servlet and EJB containers. Figure 2.4. Full JEE Deployment (EAR/WAR/EJB3) 2.2. Key Technologies Used Here is a listing and brief description of the key runtime technologies used Java Persistance API (JPA) The Java Persistence API, sometimes referred to as JPA, is a Java programming language framework that allows developers to manage relational data in Java Platform, Standard Edition and Java Platform, Enterprise Edition applications. Persistence consists of three areas: 5

14 Architecture Overview 1. the API, defined in the javax.persistence package 2. the Java Persistence Query Language 3. object/relational metadata Eclipse JEE Tools Project Site [ Java_Persistence_API] Spring Framework Spring is a Java/J2EE application framework. Features of Spring: The most complete lightweight container, providing centralized, automated configuration and wiring of your application objects. The container is non-invasive, capable of assembling a complex system from a set of loosely-coupled components (POJOs) in a consistent and transparent fashion. The container brings agility and leverage, and improves application testability and scalability by allowing software components to be first developed and tested in isolation, then scaled up for deployment in any environment (J2SE or J2EE). A common abstraction layer for transaction management, allowing for pluggable transaction managers, and making it easy to demarcate transactions without dealing with low-level issues. Generic strategies for JTA and a single JDBC DataSource are included. In contrast to plain JTA or EJB CMT, Spring's transaction support is not tied to J2EE environments. A JDBC abstraction layer that offers a meaningful exception hierarchy (no more pulling vendor codes out of SQLException), simplifies error handling, and greatly reduces the amount of code you'll need to write. You'll never need to write another finally block to use JDBC again. The JDBC-oriented exceptions comply to Spring's generic DAO exception hierarchy. Integration with Toplink, Hibernate, JDO, and ibatis SQL Maps: in terms of resource holders, DAO implementation support, and transaction strategies. First-class Hibernate support with lots of IoC convenience features, addressing many typical Hibernate integration issues. All of these comply to Spring's generic transaction and DAO exception hierarchies. AOP functionality, fully integrated into Spring configuration management. You can AOP-enable any object managed by Spring, adding aspects such as declarative transaction management. With Spring, you can have declarative transaction management without EJB... even without JTA, if you're using a single database in Tomcat or another web container without JTA support. A flexible MVC web application framework, built on core Spring functionality. This framework is highly configurable via strategy interfaces, and accommodates multiple view technologies like JSP, Velocity, Tiles, itext, and POI. Note that a Spring middle tier can easily be combined with a web tier based on any other web MVC framework, like Struts, WebWork, or Tapestry. 6

15 Architecture Overview You can use all of Spring's functionality in any J2EE server, and most of it also in nonmanaged environments. A central focus of Spring is to allow for reusable business and data access objects that are not tied to specific J2EE services. Such objects can be reused across J2EE environments (web or EJB), standalone applications, test environments, etc without any hassle. Spring's layered architecture gives you a lot of flexibility. All its functionality builds on lower levels. So you can e.g. use the JavaBeans configuration management without using the MVC framework or AOP support. But if you use the web MVC framework or AOP support, you'll find they build on the configuration framework, so you can apply your knowledge about it immediately. Spring Framework - About [ Hibernate Spring uses Hibernate for persistence framework. Hibernate is a powerful, high performance object/relational persistence and query service. Hibernate lets you develop persistent classes following object-oriented idiom - including association, inheritance, polymorphism, composition, and collections. Hibernate allows you to express queries in its own portable SQL extension (HQL), as well as in native SQL, or with an object-oriented Criteria and Example API. Hibernate [ 7

16 Chapter 3. Environment Overview 1. Eclipse Concepts This section reviews some key Eclipse concepts that are particularly relevant to Skyway Builder. Overview of Eclipse Concepts Workbench - In Eclipse the workbench is the Eclipse user interface. The workbench has various components to it, including editors, views and perspectives. Editors - Editors are located in the main section of the workbench. Eclipse Editors are added to Eclipse by Eclipse plug-ins, and they are used to perform the activities associated with plugins. Views - On the perimeter of editors are Views, which are used to navigate and manage the activity being performed within the editor. Views can also provide context-sensitive data related to the activity. Views are added to Eclipse by Eclipse plug-ins. Perspective - A perspective is a visual container of views, editors, and menu/toolbar commands that are configured for a particular task. Perspectives are added to Eclipse by Eclipse plug-ins. A perspective also specifies the default layout of the views that can be used as-is, or you can customize the perspective according to your preferences. Perspective Bar - Eclipse provides a perspective bar for switching between perspectives. Workspace - In Eclipse a workspace is a directory where your projects are stored and grouped. Since you can have several workspaces, you are prompted to pick your workspace when you start Eclipse. You can't access Eclipse projects from a workspace you haven't opened. You can optionally tell Eclipse to use your selected workspace as the default workspace, so that you won't be prompted everytime you start-up Eclipse. Project - A project is a container for resources associated with the activity being performed by a user of a particular plug-in or set of plugins. Projects are associated with one and only one workspace, and the type of project is determined by project natures. Natures - Project natures describe behavioral aspects of a project. Natures associated a project with plugins. Wizards - During the creation of the new artifacts, wizards are used to prompt the user for required information (i.e. name) and optional information. Preferences - Preferences provide a standard dialog for managing the preferences of Eclipse plug-ins that are installed in the workbench, 2. Skyway Builder Versions The following table describes the different versions of Skyway Builder that are available. 8

17 Environment Overview Table 3.1. Skyway Builder Editions Edition Description Skyway Builder Community Edition (CE) the community edition of Skyway Builder; opensource build complete JEE web applications based on Spring Framework web-only deployment (WAR files for servlet/jsp container) deploy to open-source application servers (Tomcat, Jetty, JBoss) Skyway Builder Enterprise Edition (EE) the enterprise edtion of Skyway Builder; adds enterprise features to the community edition consume and produce web services; contractfirst web services development graphically define transaction boundaries (transaction management) simplified security authentication; use LDAP, simple DB or any other Spring-supported security realm web/ejb3 deployment (EAR files for servlet and ejb containers) deploy to commercial application servers includes enterprise-class JDBC drivers for commercial database management systems design-time and runtime support Table 3.2. Skyway Builder Distribution/Download Methods Distribution Description Skyway Builder Rich Client Platform (RCP) minimal Eclipse installation bundled with Skyway plugins Skyway Builder Eclipse Plugin for adding Skyway plugins and perspective to existing installation of Eclipse 3.3 Source Code available for download; create your own build More information can be found at the Skyway Communtity site [ 3. Skyway Buider's Eclipse-based Components Skyway Builder is a set of Eclipse plugins that provides functionality to build web applications. In addition to enabling developers to leverage Skyway's functionality in a familiar environment, it also let's Skyway Builder co-exist with other tools (plug-ins) in one integrated environment. 9

18 Environment Overview As described earlier, an Eclipse perspective is a visual container of views, editors, and menu/toolbar commands that are configured for a particular task. The Skyway Builder Perspective represents a set of views, editors and menu/toolbar commands for the model-driven development of dynamic web applications based on the Spring framework and Hibernate persistence. The various components of Skyway Builder Perspectives will be described next Skyway Views Skyway Navigator The Skyway Navigator is an Eclipse view for navigating the resources of a Skyway Project Skyway Toolbars and Menus Skyway Toolbar When using the Skyway Builder perspective, the Skyway Toolbar provides toolbar access to Skyway functions, including creation, deployment and execution. Figure 3.1. Skyway Toolbar 10

19 Environment Overview Skyway Menus 3.3. Editors Skyway Editors Just about every Skyway-related resource has an Editor for configuring and modelling the implementation of the artifact. Skyway Editors Project Editor Service Editor Operation Editor Action Editor Web Controller Editor Web Conversation Editor Data Type Editor Data Store Editor 11

20 Chapter 4. Application Development 1. Skyway Development Artifacts Within Skyway Visual Perspectives, there are graphical (and abstract) representations of object types and actions that can be taken against these types. These object types often have direct correlations to Java artifacts or JEE application server configuration files. The high level artifacts are listed below. Summary of Skyway Artifacts Projects are the top level artifact within the developer's workspace. All other objects must be made within projects but can access objects within and across project boundaries. Data Types are used to define the domain model. Developers can specify standard primitive types for the fields within a Data Type and can also specify relationships to other Data Types and their cardinality. Data Stores are abstract representations of real databases that are used in the modelling environment when persistence is needed. During deployment Data Stores are bound to a real, physical implementation of a database. Services are used to implement the Service layer of an application. Operations are discrete application functions defined in a Service. Actions are the model-based implementation of application. Actions are created by sequencing Steps together. Web Controllers are used to implement the Web layer of an application, and they have one or more Conversations. Web Conversations are task-based groupings of logic for handling user event. Conversations are implemented using Actions. Views are Java Server Pages (JSP) that implement the Presentation layer. Exceptions are definitions of certain types of errors that the developer may want to surface as the models become code and are executed. 2. Project Meta-data Model Everything you create in Skyway Builder will manifest itself as project meta-data, and meta-data has a hierarchy that is referred to as the Skyway Meta-Data Model. This model defines the boundaries of a project. 12

21 Application Development Figure 4.1. Project Meta-Data Model A Folder is an organizational artifact that is able to hold any object that it s parent can, and folders are only used for name-spacing during code generation. The folders may also influence addressable URLs. Skyway Builder provides a domain specific language (DSL) for web applications and services. This metadata is an instantiation of the EMF, a general purpose modeling framework. Here is the developer's view of the Skyway metadata for a particular project. This project can be downloaded as a sample application from Skyway Communtity site [ 13

22 Application Development Figure 4.2. Skyway Navigator 3. Application Layering A web application is logically separated into three layers: the data layer, the service layer, and the web layer. Each layer has a distinct responsibility in the application and should be isolated from other layers. The following diagram summarizes the function of each layer and the Skyway modeling artifacts used to implement this layer. 14

23 Application Development Figure 4.3. Application Layers - High-Level 3.1. Web Layer The web layer is also referred to as the UI layer. The web layer is primarily concerned with presenting the user interface and the behavior of the application (handling user interactions/events). While the web layer can also contain logic, core application logic is usually located in the services layer. The tools for defining the web layer in Skyway Builder are the Web Controller, Web Conversation, Action, and Steps, and they will be described in detail in a following chapter Service Layer The service layer is also referred to as the logic layer or business layer. The service layer represents the core functionality of the application being built. The web layer is the primary consumer of the functionality provided by the service layer. The service layer can also provide interfaces for other applications to consume its functionality. The tools for defining the service layer in Skyway Builder are the Service, Operation, Action, and Steps, and they will be described in detail in a following chapter Data Layer The data layer is also referred to as the persistence layer or domain object layer. The data layer is represented by a domain model; a distinct set of inter-related application objects that embody the functionality and characteristics of the system being built. This layer also encompasses the persistence of the domain model to and from a database. The tools for defining the data layer in Skyway Builder are the Data Type and Data Store artifacts, and they will be described in detail in a following chapter. 15

24 Application Development 4. Development Process 4.1. Development Steps Application development with Skyway Builder generally consists of five steps. Over the next few chapters each step will be described in detail. This diagram is a simplification, and it does not represent the entire software development lifecycle. Figure 4.4. Development Steps Overview High-level Development Steps Defined Project - When starting a new application, the first step is to create a project. Data Layer - The next step is to define the data layer. Services Layer - The next step is to define the services layer. Web Layer - The next step is to define the web layer. Deploy - The final step is to deploy the project. 16

25 Chapter 5. Create Project This chapter will describe the artifacts and configurations associated with defining the Skyway Project. 1. Projects Projects are the top level development artifact within Skyway Builder. All other Skyway artifacts must reside inside a project. In many cases a web application is implemented as a single project, with the project containing any and all artifacts needed to provide its functionality. Since a project can reference development artifacts in other projects, there are cases where an application consists of multiple projects. In addition to its function as a container for development artifacts, a project also represents a group of artifacts for version control and deployment. When putting a project under version control, all the project artifacts must be version controlled in the project's version control configuration. Similarly a project represents a unit of deployment. As a project is deployed, all the development artifacts in the project are deployed together. Summary of Project Uses Top-level Container for development artifacts Version Control Unit of Deployment Note: Unlike Web Projects in Eclipse, a Skyway Project isn't identified with a specific JEE container (i.e. Servlet/JSP or EJB). A Skyway Project is a development abstraction, and the partitioning of its development artifacts across containers is determined at deployment time. Deployment is discussed in greater detail in Chapter 8. The Skyway Navigator will display all the Skyway Projects in an Eclipse Workspace. You can work on multiple Skyway Projects at the same time. 2. Project Configurations 2.1. General Info Project name uniquely identifies the project, and the name is used to for name-spacing the meta-data and generated artifacts. The description might include: Common uses for Project Description a high-level functional description of the project design and/or implementation notes 17

26 Create Project project meta-data (functional owner, developed by, etc...) 2.2. Project Variables Project variables are variables that are available to any and all project artifacts. Project variables are session scoped, so they exist for the life of the user session. Project variable uses: sharing data across all project artifacts holding configuration data other sensitive values that should be protected Since project variables are maintained in a user session, excessive use of project variables may adversely impact the scalability of your application. Therefore it's generally recommended to use of project variables sparingly. The alternative to project variables are Operation and Conversation variables Project Constants Project constants are fixed variables whose values are defined at design-time. A project constant functions like Operation constants and Web Conversation constants, except the Project constants are accessible by all artifacts in the project. This is a great place to keep constants that are shared across the entire project View Mappings There are several places in a project where you may reference a JSP page. Directly referencing Java Server Pages (JSP) can be difficult for team-based development or add maintenance complexity to larger projects. The view mappings configuration provides a way to alias pages so that references to the JSP pages aren't hard-coded in Web Controllers or Web Conversations. The URL (Alias) is the alias used to reference the view resource. 18

27 Chapter 6. Data Layer This chapter will describe the artifacts and configurations associated with implementing the Data Layer. The data layer is concerned with the definition and persistence of the domain model. In this chapter the components of the data layer will be described in greater detail. 1. Domain Model An application typically consists of a distinct set of inter-related application objects that embody the functionality and characteristics of the system being built. All of the application objects are cumulatively referred to as the domain object model. A development effort usually begins with analysis of the problem domain, and domain modeling is frequently the first step in designing an application. Domain modeling is the analysis of data objects that are used in a business, analysis of the attributes of those objects, and the identification of the relationships between these data objects. Figure 6.1. Domain Model (Banking Example) 1.1. Implementing the Domain Model In a Skyway Project the domain model is defined by creating custom data types that encompass the attributes of the domain objects and relating the data types to each other. The domain objects become Data Types, and the object attributes become fields in the respective Data Type. The relationship lines in the data model become the relationships in the Data Types. 19

28 Data Layer Steps for Implementing a Domain Model Create a Data Type for each domain object Add a field to the data type for each attribute of the domain object Define relationships between data types 2. Basic Data Types All applications work with data, and data types specify the kind of data that can be stored and manipulated within a program. Skyway supports a number of fundamental basic data types (scalar data types), which are the simplest data types in a Skyway application. Skyway supports the following basic data types: Table 6.1. Skyway Basic Data Types Name Description ID Use as a unique ID; generates a string of characters that is guaranteed to be unique Text Use to store text or combinations of text and numbers, as well as numbers that do not require calculations (i.e. phone numbers); defaults to 100 but can be up to 2000 characters Integer Use to store whole number data Decimal Use to store numeric data with 1 to 10 decimal places; accurate up to 20 digits on the left side of the decimal separator and up to 10 digits on the right side of the decimal separator Date and Time Use to store date and time data; valid ranges date ranges are between January 1, 1753 and December 31, 9999 Boolean Use to store true or false constant value Large Text Use to store text or combinations of text and numbers that exceed 2000 characters; defaults to 100 but can be up to a maximum length of 2,147,483,647 characters Date Use to store date data; valid ranges date ranges are between January 1, 1753 and December 31, 9999 Time Use to store time data Picture Use to store an image Large Data Storage Use to store variable-length binary data 3. Data Types Data Types are used to define domain objects that will be utilized within an application. You can add object attributes by using the basic data types, and you can also specify relationships to other Data Types and their cardinality. The following figure shows how the Banking Domain Model would possibly be implemented in a Skyway project: 20

29 Data Layer Figure 6.2. Data Types (Banking Example) As described in the Skyway meta-data model, Data Types can be created in a Service or a Web Controller Defining Fields For each attribute of the domain object being implemented, specify a field name and field type. The field type can be any of the supported basic data types described earlier (i.e. Text, Decimal, Integer, etc...) Primary Keys You can specify the field or fields that uniquely identify the object. Composite keys are supported Collections By default a field is scalar; it can store one value of the basic type that is specified. If you mark the field as a collection, the field becomes a composite field that can store one or more values of that data type Defining Relationships Data Types can be related to each other data types in the same data store. Relationships cannot span multiple data stores. When defining a relation for a data type, you must specify the related data type, the relationship type, and the relationship names. Note: While relationships are usually defined between two different data types, a data type can also be related to itself. For example, a "category" data type can have a relationship to itself to represent sub-categories Relationship Type The Relationship Type defines the cardinality of the relationship from the perspective of the current Data Type. The options are: 21

30 Data Layer Table 6.2. Relationship Types Type Description One-to-One a data type is related to a single occurrence of the other data type One-to-Many a data type is related to many occurrences of the other data type; the opposite side of a Many-to-One relationship Many-to-One a data type is related to a single occurrence of the other data type; the opposite side of a One-to-Many relationship Many-to-Many a data type is related to many occurrences of the other data type, and vice versa Bidirectional Relationships When a relationship is added to another data type, a unidirectional relationship is implied. Two independent unidirectional relationships can be linked together to create a bidirectional relationship. If you decide to define a bidirectional relationship, the cardinality and relationship names need to match Relationships Names When defining a relationship between two data objects, the Data Type editor will prompt you for a relationship name and a reverse name. These names will be used for accessing each other's related data. The relationship name is used to identify the relationship from the perspective of the current data type. The reverse name is used to identify the relationship from the target data object type back to the current data type. Once last thing about relationship names, the Data Type editor will default the data type name as the relationship names, but you can very easily changed the name. As a matter of fact it s a good idea to change these relationship names to something more semantically meaningful. While they have no impact on the functionality, these names will be the what you will see as your referencing these relationships in the services you create. So make these names meaningful, and it s recommended that you name them with the appropriate plurality for the relationship type Persistence Mapping The Persistence Mapping panel lets you influence how the a data type is persisted to a database. When a new data type is created, Skyway Builder will automatically create default persistence mapping values based on the definition of the data type. For example: if the data type is named Customer, then the table name will be defaulted to customer. However if you want to use a different table name, you can override the auto-generated persistence configuration. If you're familiar with JPA, then the configuration settings should look pretty familiar. These settings are directly related to JPA annotations. As you make changes to the Persistence Mapping panel, the annotations in the code associated with the data types will be automatically updated. 4. Data Stores Data Stores are abstract representations of real databases (or persistence mechanisms), and they manage persistence for a set of data types. When designing the models there is no need to know the detail of the database (vendor, version, IP, etc.), but simply a need to know that one exists for modeling database activity. When models are deployed, the developer late binds each Data Store to a real, physical implementation of a database. 22

31 Data Layer Figure 6.3. Data Stores (Banking Example) In this example, all associated data types are persisted to the same data store. When a developer wants to access these persisted objects, they will bind their persistent steps to this data store. There are various ways of utilizing data stores for functions related to persistence. You can perform standard data operations (search, update, delete) or named queries. Each of these will be described next Data Operations For every data type added to a Data Store, the developer can perform basic persistence functions using the Modify Data Store and Search Data Store steps. These functions are often referred to as CRUD (create/ insert, read, update, and delete) Named Queries A Named Query is a mechanism for predefining queries for the data types associated with a Data Store. Named queries are defined using either SQL or JPQL (Java Persistence Query Language). JPQL is the query lanaguage of JPA, that resembles SQL queries. The benefits of named queries is that the queries are centralized and they can more easily be re-used. Using the Modify Data Store and Search Data Store steps througout your application can make it more more difficult to manage where and how the data access is occurring because the queries are contained in the generated code. On the other hand named queries are all located with their associated data store. This makes it a lot easier for developer to find the query for re-using, repurposing or optimizing Inputs and Outputs These define the input and output parameters of a particular named query. When this query is invoked, the consumer of the name query is required to map variables to the input and output parameters. 23

32 Data Layer Query Text This defines the query in either SQL or JPQL. Table 6.3. JPA Query Examples Type Query Select SELECT ln FROM LoanAccountInfo ln WHERE ln.accountnumber = ${inaccountnumber} Insert insert into NamedQueryTest values(${key}, ${value}) Update UPDATE NamedQueryTest t SET t.field_2 = ${value} WHERE t.field_1 = ${key} Delete DELETE FROM NamedQueryTest c WHERE c.field_1 = ${inkey} 5. Leveraging Existing Databases There may be occasions where a data model already exists, and you don't want to implement the domain model with Skyway. This can occur when the data model was defined by a different group (not using Skyway Builder) or when building on top of an existing application. In either case, you need a way to leverage the pre-existing data model from Skyway. In Skyway Builder there are essentially two ways implement a data model in a Skyway solution: natively and externally. Using the native approach, the data model is defined in Skyway, and Skyway produces the database table definitions for any supported database management system. Using the external approach, define the data model in a relational database and import the table definitions into Skyway. The following table summarizes the differences with choosing externally defined data models versus natively defined data models. 24

33 Data Layer Table 6.4. Comparison of Native and External Data Models Native External Defined in an object-oriented manner; the patterns Defined in a relational manner with objectfor storing object-oriented data in relational oriented facade; relational schemas don't translate databases are very well defined and handled by the perfectly to objects. ORM framework and JPA provider. Data model created in same application development environment Data model must be defined using separate tools; all developers will need access to DBMS client tools Data model changes are immediately available in the Skyway project Data model must be rediscovered before being available to Skyway project Data model can easily evolve during application development; the initial definition of the data model can be pretty loose All data model changes must be done externally; extra effort required to import data model; therefore you will probably want data model to be well defined Data model changes are version controlled with the other application development artifacts; easier to identify correct data model implementation for earlier versions of application If data model changes are version controlled at all, it will be done separately from project DBMS expertise not needed DBMS expertise needed; DBA may need to get involved too Data model can be deployed to any DBMS; maximum deployment flexibility The data model is tied to the DBMS that it was derived from Sharing project is simply a matter of copying project folder Sharing project requires copying the project folder and providing the ddl for the database While native data models offer maximum flexibility, there are occasions where external data models are the only or most suitable option. Here are some comman scenarios where you would use external data models: Table 6.5. Scenarios for using external data models Scenario Description Application Migration New front-end to existing application database Integration Integration with external systems Applicatoon Interface tables To facilitate external applications integrating with Skyway application at DB level DB Centric Development You just absolutely can't start development without have the data model completely defined in a relational database 5.1. Importing Types Using externally defined tables is accomplished using the Import Types wizard, which can be accessed from the Database Configuration tab in the Data Store Editor. Once the data types are discovered, they can be used just like data types created in Skyway. Here are the general steps for importing data types: 25

34 Data Layer Steps For Importing Types 1. Create Data Store - In a Skyway Project create a data store that will represent your database. 2. Configure DB Connection - Switch to the Database Configuration tab of the Data Store you created, and specify the database connection (in the Database Information section) that contains the tables you want to import. If the a database connection hasn't been defined, you must create the database connection using the Database Explorer, and the specify the connection. 3. Active the Import Types wizard - Click on the Import Types link from the Activities panel of the Database Configuration tab. 4. Select the schema - The schema dropdown will show a list of schemas available from the database connection. Select the schema that contains the tables that should be imported. 5. Select the dialect - The dialect dropdown will show a list of dialects supported by Skyway Builder. Select the schema that matches your database. 6. Select the tables to import - From the tables grid, select the tables that you want to import into the Skyway Builder project. 7. Click Finish - Skyway Builder will analyze the tables and create the data types corresponding the tables that were imported. 6. Using Data Types from Other Sources Data types can originate from other sources too, including java beans, XML schemas and web services Note about java beans and packages Whether packaged in a jar file or code into your project, your java beans must be in package. Otherwise it can't be accessed by other code that is within a package Java Beans Java beans (POJO's) and data types are essentially the same thing. As you create data types in a project, Skyway is actually generating the java beans for you. This works in the reverse direction too. As part of the seemless blending of modelling and coding, you can also use java beans created outside of Skyway Builder. They may exist in java libraries that you include in your project, or they can be java beans classes that you add directly to your project. In either case they would manifest themselves in your Skyway project as data types. Adding Java Beans to your Skyway Project JAR - add jar file to your project (lib folder) and add to project classpath (Properties-->Java Build Path) Custom Coded Beans - Switch to Eclipse Java Persepctives and add custom coded java bean(s) to src folder of Skyway Project. You can use your java bean as a data type. For example, you can add operation or conversation variables. The Skyway type picker has "Java" filter option that is by default disabled. The picker will only show you the data types that were created in the Skyway project. When this option is enabled, you can search and select from all java beans added to project. Since the java bean list can be very long, you need to type a few letters of the java bean in order to start the filtering process. 26

35 Data Layer 6.2. Web Services Whether importing for consumption or contract-first development, the complex types defined in a WSDL will be generated into Skyway data types. When importing a WSDL for the purpose of consuming web services, these data types can be used to from Skyway to pass data to and from the service. When importing a WSDL for the purpose of contract-first development, the data types will be generated to facilitate the implementation of the services. 27

36 Chapter 7. Service Layer This chapter will describe the artifacts and configurations associated with implementing the Service Layer. The Service layer represents the core functionality of the application being built. The primary consumer of the service layer is the web layer of the current project as well as the web/service layers of other projects. The functionality represented by this layer is accessed in an API type manner using structured inputs and outputs. This section will give you an overview of building the service layer of an application using Skyway Builder. 1. Skyway Service A Skyway Service is an artifact that defines a set of functions. Functions are application logic that use structured inputs and outputs for exchanging data. In Skyway development the functions are defined as Operations, and the logic is implemented using Actions. Figure 7.1. Skyway Service Skyway has adopted the SOAP lexicon (services and operations) for describing and implementing the Service layer of an application. This doesn't mean that web services are being used for invocation. Skyway will use java invocation by default, so there isn't any of the additional overhead of web services. However Skyway Services can also be exposed as web services by configuration (see Scope), in which case the Skyway Service concepts map exactly to the equivalent web service concepts. 28

37 Service Layer 2. Operations Service functions are specified as Operations, which represent stateless application logic. In addition to a name and description, the operation definition consists of an operation interface and operation resources. The application logic of an operation is implemented using a sequence of Actions (discussed in a later section), which represent a single thread of execution. An operation doesn t support concurrent threads of execution, thus simplifying modeling by eliminating complex behaviors arising from multithreading. Figure 7.2. Operations 2.1. Operation Interface The operation interface defines the formal contract between the operation and the consumers of the operation. Operation Interface Operation Name - the name visible to others Inputs - a definition of the operation input variables Outputs - a definition of the operation output variables Exceptions - a definition of the exceptions that may be thrown by the operation Operation Name This is the name that consumers use to refer to the operation; a general guideline is to define Operations using a functional verb and noun expression. This usually is a great starting point for determining the appropriate level of granularity, and the consumers of the Operation understand the specific service provided by the Operation Inputs Inputs are a mechanism for exchanging data with the consumer of the operation, and they define part of the operation contract. When a consumer calls an operation, they must provide all the input variables defined by the operation. Input variables are exactly like operation variables, which means any action steps may access the input variable the same way they access operation variables. 29

38 Service Layer Outputs Outputs are another mechanism for exchanging data with the consumer of the operation, and they also define part of the operation contract. When a consumer calls an operation, they must accept all the output variables defined by the operation. Output Variables cannot be manipulated directly by the Operation steps. The output variables are assigned their value by selecting the Assigned To value on the Output sub-tab. Any variable from either the Variables tab or Inputs tab can be assigned to the output variables Exceptions If any exception occurs and it is not listed in the operation interface, the exception will be ignored Operation Resources Operation resources are the set of resources needed in an operation to implement the desired functionality. Operation resources are not part of the operation interface, and the consumers of the operation don't have any visibility into the operation resources. Operation Resources Variables - a set of variables that are available to all Actions Constants - a set of constants that are available to all Actions Actions - a model-based representation of the application logic Entry Point Action - the Action that represents the starting point of the operation; an operation can consist of one or more Actions, and the operation must be configured with the Action that should be called first upon invocation of the operation Variables The variables defined in an Operation are available to all actions in the operation. These variables are used to store data needed by the Operation. Operation variables are declared to hold: Scalar data; basic data types (i.e. Integer, Text, Boolean, etc...) Collection of scalar data Custom data types (i.e. data types created in Skyway, java beans, etc...) Collection of custom data types Operations are stateless, so the scope of operation variables is limited to operation invocation. Operation variables aren't maintained across calls Constants An operation constant is a fixed variable whose value is defined at design-time. An operation constant functions like Project constants and Web Conversations constants, except the operation constants are only accessible to operation actions. This is a great place to keep constants that are only needed in the operation. 30

39 Service Layer Actions The application logic for an operation is implemented using Actions. Actions are described in more detail in the next section Entry Point Action The Entry Point Action represents the starting point of the operation. An operation will consist of at least one or more Actions, and the operation must be configured with the Action that should be called first upon invocation of the operation Recursion Recursion refers to an algorithm that contains itself in one or more of its component steps. This is a common IT pattern with hierarchical data. Skyway supports the recursive invocation of operations and actions. 3. Actions While the operation defines the interface and resources needed for an application function, the functionality is actually implemented (modeled) using Actions. The developer defines the logic to be performed by sequencing steps together. Figure 7.3. Operation Actions An operation must have at least one Action. In order to accomplish more complex tasks the application logic may be implemented using several Actions. By breaking an operation down into smaller pieces, the operation logic may become easier to follow and maintain. For a given operation there will be one action that will serve as the entry point. The entry point Action is defined in the Operation editor. For every call to the operation, the entry point action will invoked first, which can call other actions using the Invoke Action step Steps When implementing actions, there is toolbox (palette) that contains a set of functional steps that are available for implementing application logic. Logic is implemented by selecting steps from the toolbox, dropping them onto the modeling canvas, configuring the steps, and defining the sequence of execution. Whether you are implementing the behavior of the web application in response to a user event or implementing the logic of a service, the same visual approach is used and the same set of steps are available. Steps introduce automation to the application development process. Using steps to implement logic (instead of custom code) is very appealing to developers and architects. First of all it reduces redundancy of application development. Rather than continuously having to write the same code over and over with only minor differences, steps automate the generation of code for the developer. By using steps there 31

40 Service Layer is also more uniformity in the code because all the code was generated in the same consistent manner (using a step template). There will also be less deviation in code as attributed by different developer styles, conventions or preferences. Enterprise architects love steps because they are easy to create, and it ensures that developers are accessing enterprise resources in a prescribed and controlled manner. Steps are added to Skyway Builder thru a plugin architecture. If you have application logic that can benefit from automation, you can add new custom steps to the toolbox. As a matter of fact, all the steps included in Skyway Builder were implemented using the plugin architecture. Figure 7.4. Skyway Builder CE - Action Steps 32

41 Service Layer Data Manipulation Steps Table 7.1. Step Group: Data Manipulation Steps Name Search Collection Description The Search Collection step allows a user to search or read the content of a Collection that has been created in Skyway Builder. Complex expressions can be created using operators, functions, constants, and variables. The Modify Collection step modifies the content of a Collection. It allows a user to add, delete or update objects in a Collection. Modify Collection Search Data Store The Search Data Store step allows a user to search the content of a Data Store that has been created in Skyway Builder. Complex expressions can be created using operators, functions, constants, and variables. The Modify Data Store step modifies the content of a Data Store. It allows a user to add, delete or update objects in a Data Store. Modify Data Store The Execute Named Query step will invoke a named query defined in a Data Store. Named Query Execute SQL The Execute SQL step allows a user to issue SQL statements directly to an underlying RDBMS. This is useful, for example, for calling stored procedures that are defined within the database system. If a user's SQL statement is expected to return data (i.e. single value, single row, multiple rows), a user can assign the data to a variable or Collection using this step. The Variable Editor step allows a user to assign a value to a variable using expressions that include operators, constants, variables, and data store values. Variable Editor The Clear Conversations step allows a user to clear conversations from a web controller. Clear Conversations 33

42 Service Layer Service Steps Table 7.2. Step Group: Service Steps Name Description The Send step allows a user to construct and send HTMLbase using variables created within an Operation or Conversation. Send The Groovy step allows users to enter a script and save it as a part of the step. The script can reference Skyway variables as well as invoke methods on Skyway or Java components such as projects, operations, and actions that have been discovered. Groovy The Invoke Action step allows a user to pass execution of the current Action to another Action within the same Operation. Invoke Action Invoke Operation The Invoke Operation step invokes an operation from the current action. The step is capable of invoking an Skyway operation from the same project, another project, and even another container. Depending on the location of the operation, the Invoke Operation Step will automatically determine the most optimal communication channel. This step allows a user to add message logging to an Operation or Conversation. Log Message Flow Steps Table 7.3. Step Group: Flow Steps Name Description The Decision step allows a user's Operation or Web Module to follow a logic path based on a yes or no validation of the specified criteria. Decision The Decision Range step allows a user's Operation or Web Module to follow any one of a number of possible logic paths based upon the evaluation of the specified criteria. Decision Range The Iterator Start step allows a user to loop through the content of a Collection or Data Store that has been created in Skyway. Iteration Start The Stop step is an optional step used to terminate an Action when there is no certain endpoint. Stop 34

43 Service Layer Exception Steps Table 7.4. Step Group: Exception Steps Name Description Once an exception type has been configured to catch the type of exception thrown, the Catch Exception step is invoked when an exception is thrown from any preceding step. Catch Exception The Throw Exception step allows users to throw a user-defined exception. Throw Exception Transaction Management Steps Table 7.5. Step Group: Transaction Management Steps Name Description This is step to commit the last transaction and start a new transaction. Transaction This step is to rollback a transaction. Rollback 4. Custom Java Code Augmenting the application development process with modeling-based automation can significantly improve development productivity and application quality, however it's important to recognize that modeling-based automation is not an all or nothing proposition. Model-based automation must be complimentary to traditional code-based development. Skyway Builder excels at this by providing a seamless blending of models and code. Skyway Builder let's you drop code into your projects that can be used along-side the model-based components. In the event that your functionality cannot be effectively expressed using models (perhaps due to lacking model-based representations of functionality or efficiency/performance considerations), you can use regular java code and java libraries along with your models. While using java code in conjunction with models is a powerful feature in itself, Skyway Builder goes the extra step of adapting (blending) code-based resources to appear as model-based resources in the modeling environment. For example, if you define POJO's in your project, they can be used just like POJO's derived from models. Another capability afforded by the Skyway Builder application generation engine is that the generated logic/code can be used directly from the developer's custom code. The code generated by Skyway is concise and human-readable, and it's organized, packaged and name-spaced according to project hierarchy. This makes it very easy for developers to find and use the generated functionality from within their custom code. 35

44 Service Layer In addition to supporting the use of custom code, the Groovy step adds dynamic language support to Skyway Builder. If a developer needs to resort to custom code for ant part of their application, the developer can use the Groovy step for their code. The bottom line is that Skyway Builder makes it easy for your model-based and code-based artifacts to coexist and interact. Java developers can now implement the data, service, and web layers of their solution entirely in models or through the blending of models and java code. Custom Java code can be authored along side models, and both can be fully leveraged by one another Embedding Java Code TODO 4.2. Calling Java Libraries TODO 4.3. Using Groovy TODO 5. Web Services 5.1. Consume Web Services There are many ways that applications developed with Skyway Builder can leverage functionality or data of other systems. If the functionality is available as SOAP-based web services, Skyway Builder can invoke those services as easily as if the functionality had been implemented natively using Skyway Builder. Typically a WSDL document (XML) is used to communicate the availability, contract and location of a system's web services. Skyway Builder will discover (or learn about the existence of) these services by the developer importing the WSDL document. As part of the discovery process, modelling artifacts corresponding to the web services defined in the WSDL will be added to the project. These modelling artifacts can then be used to access the functionality of the services. Web services are often used as an integration technology, where the application being produced needs to leverage the functionality of another system. On the other hand, composite applications integrate with services from a variety of systems, as is typically the case in SOA environments. The service layer of a composite application may be entirely implemented by other systems, in which case the composite application only implements the user interface and behavior of the application. The process for consuming web services in Skyway Builder Enterprise Edition is to import the service. From the overview tab of the Project Editor, click on the Import Service hyperlink. The Import WSDL File wizzard will prompt you for the WSDL. You can either specify a URL or load a WSDL from the file system, and then click "Finish". Skyway Builder will parse the WSDL and create model based artifacts from the WSDL components. 36

45 Service Layer Table 7.6. Web Service WSDL to Skyway Mappings WSDL Component Skyway Component Description WSDL Document Skyway Service The entire WSDL document represents a Service, and a Skyway Service will be created to represent the imported service. WSDL Complex Types Data Types Skyway data types will be automatically created for any complex types defined in the WSDL that are needed to interact with the service. WSDL Operations Skyway Operations A Skyway operation will automatically be created for each operation defined in the WSDL. These operations are what a Skyway Builder application will use to invoke the functionality of the service Produce Web Services - Model First Development If the functionality of an application produced with Skyway Builder needs to be accessed by another system, then Skyway Builder can expose it's services and operations as web services. As indicated earlier, Skyway has adopted the SOAP lexicon of services and operations, but that doesn't mean that Skyway exposes and uses SOAP services for invocation. The decision of exposing application logic as SOAP web services is left to the developer to decide based on their requirements. In the event that Skyway Services are configured to be exposed as web services, Skyway Builder will produce the WSDL document that other systems can use to discover the available operations, including the contract and location Produce Web Services - Contract First Development When designing a system that consists of multiple applications communicating with each other using web services, it is common to use contract-first development as way of defining the messages that will be handled between systems. This includes identifying the operations themselves, including the input and output parameterts. This cummulatively referred to as the contract, and it defined as a WSDL document. When it comes time to build the systems, the applications must produce services according the predefined contract. If Skyway Builder is being used to implement the web services, then Skyway Builder would discover the WSDL for the purposes of implementing the services. This is of course different than discovering the web services for the purposed of consuming the services as described in the Consume Web Services section. 37

46 Chapter 8. Building Web Layer This chapter will describe the artifacts and configurations associated with implementing the Web Layer. In Skyway Builder the principle building blocks for web applications are Web Conversations, Actions, and Views. Views render the user interface. Actions process and respond to user events. Related actions are grouped together in a Web Conversation, which provide shared variables. The beginning of this chapter will describe the building blocks. Towards the end of this chapter these building blocks will described in the context of web application patterns. As with any development tool, there are a variety of choices and types of applications that can be built. After describing the basic concepts, it will be easier to understand how the tools provided by Skyway can leveraged effectively for implementing the web layer. 1. Web Controllers Web Controllers are used along with the Web Conversations and JSP pages (located in the WebContent) to implement the Web layer of an application. The Web Controller has essentially two functions: grouping Web Conversations and mapping urls to Actions. The grouping function is pretty self-explanatory, and a web controller will typically have at least one Web Conversation. Figure 8.1. Skyway Web Controller 1.1. URL Action Mapping In addition to serving as the container for Web Conversations, a Web Controller has the very important function of mapping urls to actions and views. Conversations and Actions will be discussed shortly in 38

47 Building Web Layer greater detail, but at this point it's important to know that actions defined in a Web Conversation are used to define the behaviour of the application. Actions can be, but aren't inherently, accessible as a web resource. In order for the action to be accessible from a JSP page in a Skyway application or any other web client, the action must be configured as web resource, and this is accomplished by adding an action mapping in the Web Controller. An action mapping is responsible for defining the url(s) that will trigger an action. When the defined URL is requested from a web control, javascript or web client, the action associated with the url will handle the request. The action mapping will also specify the jsp that will render the response to the request. Every request will have a response, and the action mapping specifies both the action that will handle the request and the jsp that will render the response. Each mapping has four parameters: Table 8.1. Request Mapping Parameters Parameter Description URL The URL being mapped, or intercepted by the MVC framework. Conversation.Action The action that should be invoked for the specified URL; a user can have more than url mapping to the same url View The view that should be rendered following the invocation of the Action; the configuration choices are: A JSP page View alias (defined at project level) Project variable Binding Error View The view that should be rendered if a binding error occurred (OPTIONAL) There are situations where you may have actions that won't have a defined action mapping. For example you may define an action that can be called from other actions, but not as a web resource. If you don't want actions to be accessible as a web resource, then don't add or remove the action mapping. A specific action can also be mapped from multiple urls, in which case the web controller would have multiple action mapping entries for the same action. A call to any of the urls will invoke the same action. Since each action mapping is configured with a jsp for the response, it is possible to have the response handled by a different JSP. By using action mappings, the consumers are bound to a url, and not directly to an action. Action mappings provide a form of loose coupling, where the mapped actions can be changed without impacting the consumers. The configurations needed to achieve the desired page flow pattern are represented in the following diagram: 39

48 Building Web Layer Table 8.2. Request Mapping Parameter Examples URL /userlist.jsp Action View UserRegistration. inituserlist Binding URL: /userlist.jsp Summary: Requests to /userlist.jsp will be mapped to the inituserlist action. When complete, the userlist.jsp view will be rendered. /SaveUser UserRegistration. saveuser URL: /saveconfirm.jsp Summary: Requests to "/SaveUser" will be mapped to the UserRegistration.saveUser action. When complete, the saveconfirm.jsp view will be rendered. /UpdateUser UserRegistration. saveuser URL: / updateconfirm.jsp Summary: Requests to "/UpdateUser" will be mapped to the UserRegistration.saveUser action. When complete, the updateconfirm.jsp view will be rendered. Note: Multiple request URLs can be mapped to the same action (compare to previous example), and the rendered view is based on the request URL. /RegistrationCancel UserRegistration. cancel ALIAS: Home Summary: Requests to "/RegistrationCancel" will be mapped to the UserRegistration.cancel action. When complete, the view alias will resolved to a JSP page. Aliases are defined in Project. /AddTransaction AccountManagement. addtransaction VAR: ViewVar Summary: Requests to "/AddTransaction" will be mapped to the AccountManagement.addTransaction action. When complete, the view to be rendered will be specified by the ViewVar project variable, which is set by the Action based on the result of it's processing. /SaveUser UserRegistration. saveuser /confirmation.jsp Summary: Requests to "/SaveUser" will be mapped to the UserRegistration.saveUser action. When complete, the confirmation.jsp view will be rendered. /SaveUser UserRegistration. saveuser /confirmation.jsp Summary: Requests to "/SaveUser" will be mapped to the UserRegistration.saveUser action. When complete, the confirmation.jsp view will be rendered. 2. Web Conversations There are two principal artifacts related to building dynamic web applications. JSP pages implement the user interfaces, and Web Conversations contain the processing logic for user generated events. The logic is implemented using Actions (which will be described later), and a Web Conversation is the container for the Actions. A Web Conversation also defines the variables and constants that are available to it's Actions. 40

49 Building Web Layer Figure 8.2. Conversation A web application must have at least one Web Conversation, but it will more than likely have multiple Web Conversations. A Web Conversation facilitates the grouping of processing logic around application tasks, which is typically comprised of a series of steps. Therefore each application task is implemented as it's own conversation, and each conversation contains the variables, constants, and Actions needed to orchestrate the task and support the user events associated with the task. These types of Web Conversations will typically be session scoped. When the task is done, the conversation state can be discarded using the Clear Conversations step. 41

50 Building Web Layer Figure 8.3. Conversation Example: Survey Entry While a web application will typically contain several application tasks, the example demonstrates the implementation of a single task called Survey Entry. This task contains: A series of JSP pages for rendering the views associated with the task A Web Conversation which group the actions and variables associated with this task Actions that actually handle the user-generated events from the Views associated with task 2.1. Variables Web Conversation variables are the variables used by Actions. Actions share variables with the other Actions in a Web Conversation. Common uses of Web Conversation Variables Sharing data Actions Maintain conversation state Since JSP pages having access to all Web Conversations, then JSP pages have access to all Web Conversation variables too. However an Action can not access variables in other Conversations Constants A constant is a fixed variable whose value is defined at design-time. 42

51 Building Web Layer 3. Actions Figure 8.4. Web Conversation Actions Actions in the context of a web conversation (as opposed to a service operation) implement the logic for handling user-generated events. The developer defines the logic to be performed by sequencing steps together. A web conversation must have at least one Action. In order to accomplish more complex tasks the application logic may be implemented using several Actions. A user event will be configured to call a specific Action, however other actions in any other web conversation can be invoked using the Invoke Action step. By locating an Action under a Conversation, it is implied that an Action can only access variables defined in the web conversation (as well as Project variables). As described earlies, by default Actions are private and not accessible as web resources to JSP pages. In order for an action to accessible from a JSP page, the Action must be mapped to a URL. This is performed in the URL Action Mapping configuration in the Web Controller. An Action can have multiple mappings defined in the Web Controller. If an Action has at least one mapping, the Action is considered public Steps When implementing actions, there is toolbox (palette) that contains a set of functional steps that are available for implementing application logic. Logic is implemented by selecting steps from the toolbox, dropping them onto the modeling canvas, configuring the steps, and defining the sequence of execution. Whether you are implementing the behavior of the web application in response to a user event or implementing the logic of a service, the same visual approach is used and the same set of steps are available. Steps introduce automation to the application development process. Using steps to implement logic (instead of custom code) is very appealing to developers and architects. First of all it reduces redundancy of application development. Rather than continuously having to write the same code over and over with only minor differences, steps automate the generation of code for the developer. By using steps there is also more uniformity in the code because all the code was generated in the same consistent manner (using a step template). There will also be less deviation in code as attributed by different developer styles, conventions or preferences. Enterprise architects love steps because they are easy to create, and it ensures that developers are accessing enterprise resources in a prescribed and controlled manner. Steps are added to Skyway Builder thru a plugin architecture. If you have application logic that can benefit from automation, you can add new custom steps to the toolbox. As a matter of fact, all the steps included in Skyway Builder were implemented using the plugin architecture. 43

52 Building Web Layer Figure 8.5. Skyway Conversation - Action Steps These steps are identical to the steps used to implement Operation Actions. The steps were described in the Service Layer chapter, and they will not be described again here. 4. Building Views Figure 8.6. Skyway Site A site represents all the web resources in a project, including html, css, javascript, images, flash control, and JSP files. Views are implemented as JSP pages JSP Pages The user interface in Skyway applications is implemented using JSP, which offers a lot of inherent functionality to help web developers build web applications. JSP functionality is fully leveragable for Skyway applications, and Skwyay Builder adds some additional functionality make building user interfaces even easier. 44

53 Building Web Layer 4.2. Web Controls Skyway Builder provides a custom tag library to implement the user interface. The Skyway web controls are found in the palette of the JSP editor, and the controls can be dragged onto the page. Every Skyway web control has a properties panel, which makes it easy to bind the controls to Web Conversation variables and actions (URL Action Mappings). Table 8.3. Skyway Web Controls - Part 1 Web Control Description Button When placed inside a Skyway Form, the Skyway Button web control can be used to submit the user input on the form. The button label can be configured with a static value or a Skyway variable. This control also supports variable assignments and Actions. Checkbox The Skyway Checkbox web control binds a boolean variable to a checkbox on a web page. A checked Skyway Checkbox means that the boolean variable is set to "true". An unchecked Skyway Checkbox means that the boolean variable is set to "false". Conditional Display The Skyway Conditional Display web control allows you to display or not display a section of a web page based on the results of one or many true/false test conditions. If the conditions evaluate to "true", the content is displayed, otherwise the content is omitted from the web page Dropdown The Skyway Dropdown web control is a Skyway Form element that displays multiple static or variable (collection) values in listbox or dropdown format. This web control can be configured to give the user the option of selecting one or many of the dropdown values. At runtime, selection(s) are written to either a variable or a collection of variables. Form The Skyway Form web control is where controls that accept user input are placed so that the input can be submitted to the server for processing. Examples of web controls that accept user input are Skyway Input Field, Skyway Checkbox, Skyway Dropdown and Skyway Text Area. These controls must be placed within the dashed form boundary after adding a Skyway Form control to a page within the HTML Editor. Hyperlink The Skyway Hyperlink web control displays either a static or variable value, and the click event for a hyperlink can be used to assign values to variables and invoke web events. Additionally, it can be used to move the user to the next step in the web conversation without submitting other form fields. Image The Skyway Image web control allows you to display a picture or image on a web page. This web control can display either a static value or a variable, and if required, the user has the ability to modify the appearance of the image. Additionally, Skyway Image controls can be configured to display based on the results of one or many true/false test conditions. If the conditions evaluate to "true", the image is displayed, otherwise the image is omitted from the web page. Input Field The Skyway Input Field web control is a Skyway Form element that binds a variable to an Input Field on a web page. At runtime, if the Input Field variable has been initialized, the value of the variable is displayed in the Input Field. Additionally, when a form containing an Input Field is submitted at runtime, the user input is stored back to the bound variable. 45

54 Building Web Layer Table 8.4. Skyway Web Controls - Part 2 Web Control Description Iterator The Skyway Iterator web control is used to iterate through the rows of a collection and repeat the enclosed web controls once for each row in the collection. Label The Skyway Label web control allows you to display the contents of a variable on a web page. The variable can be a top-level primitive variable or a field within a complex Data Type. Layer The Skyway Layer web control is an area of content; at runtime, it emits a DIV or SPAN tag, allowing a user to apply CSS styles to specific regions of the page, and/or to use these regions to dynamically change the display of a page. These layers can be loaded or hidden by actions. Radio Button The Skyway Option web control is a Skyway Form element that displays multiple static or variable (collection) values as a set of radio buttons. The web control allows a single selection to be made from the set of options, and at runtime, the selection is written to a variable. Text Area Similar to the Skyway Input Field web control, the Skyway Text Area control is a Skyway Form element that binds a variable to a multi-line Input Field on a web page. Unlike the Input Field, the Text Area control includes a scroll bar and is used to display larger sets of data. At runtime, if the text area variable has been initialized, the value of the variable is displayed in the web control. Additionally, when a form containing a text area is submitted at runtime, the user input is stored back to the bound variable. Calendar Picker This control allows a user to include a calender picker to be accessed within selected input fields Events and Commands Skyway Web controls can be configured to associate logic with the different events supported by the web control. When configuring a web control that supports events, you must first select the Event and then configure the logic to be performed in response the event. The logic is implemented as Skyway Commands, and there are various Skyway Commands available to the web developer. 46

55 Building Web Layer Table 8.5. Event Descriptions Event Description onblur Web control loses focus onchange Web control value has changed due to user action onclick Web control clicked ondbclick Web control double-clicked onfocus Web control receives focus onkeydown Keyboard key pressed in web control onkeypress Combination of keydown and keyuppressed in web control onkeyup Keyboard key released in web control onmousedown Mouse button is pressed over a web control onmouseout Mouse pointer is moved off a web control onmouseover Mouse pointer is hovered over a web control onmouseup Mouse button is released over a web control The Events properties panel for a web control will start empty, and the developer will add events based on the need to associate behavior and/or logic to the web control using Skyway Commands. An Event will have at least one Command (otherwise the developer wouldn't have added an Event in the first place), and an event can be configured with multiple Commands. There is significance to the order of the commands, which can be re-ordered using the up and down buttons. When the event is triggered by the end-user of the application, the commands will execute in the order that they are defined. 47

56 Building Web Layer Table 8.6. Skyway Commands - Part 1 Command Name Description Change CSS Class This action applies or removes a CSS class to/from an element. More than one element can be specified by separating them with commas. And more than one CSS class can be specified by separating them with commas. The styles must be defined separately in a style sheet or an inline style block on the page. Change Style This reloads the current page. This also supports the auto-scroll feature. This action is useful for refreshing a page when data has changed, etc. If you use this action, it should be the last action in your sequence. Change Visibility This explicitly shows or hides an element by removing its display attribute. You can use a single Change Visibility action to hide and show multiple elements. You can specify more than one layer by separating them with commas. Custom Script Raw JavaScript can be typed into this action. Skyway supports round trip HTML with this action. If the user switches to code view in the HTML editor and manually enters JavaScript into an event attribute, this JavaScript will be parsed and placed into a Custom Script action when the user re-opens the wizard for the control. The user should make sure he puts a semi-colon after any custom JavaScript entered (this is standard). You can also wrap actions inside of conditional statements. Set Variables This allows a user to set the variable assignment. Enter the expression directly into the Set Variables text area containing the variable path and the value or click the Insert... button to select the desired variable to be inserted. If a variable is included it must be an EL Expression. Click here for a tutorial on EL Expressions. 48

57 Building Web Layer Table 8.7. Skyway Commands - Part 2 Command Name Description Load URL This invokes a Server Action. By default, if the element is a form control (like button), the owning form of the control will be submitted with the event. The event can be invoked asynchronously, which means the current page will not be reloaded. If the user wishes to reload the current page, they can select the auto-scroll feature which will automatically scroll the page (after reloading) so that the originating component (the one that fired the event) is in view. This loads a Skyway component into a target element on the page. A target element can be any body tag, such as a DIV or SPAN region, or a table cell (TD). NOTE: If you use this command to load a component that is going to overwrite the control firing the event, then it must be the last command in the sequence. In other words, you can configure a button or control that will reload itself or overwrite itself. But when you do this, it must be the last thing you do. Move Element This moves an element to an x,y coordinate position. There is an option to move the element to the coordinates of the triggering mouse event, which is useful for pop-ups. This action makes the element absolutely positioned, which removes the element from the natural layout flow of the page. Reload This reloads the current page. This also supports the auto-scroll feature. This action is useful for refreshing a page when data has changed, etc. If you use this action, it should be the last action in your sequence. Submit Form This action submits the named form. Only one form can be submitted per action. You can, however, have many Submit Form actions on a single event. This lets you bind multiple forms to a single submit button, which is a really nice feature. Swap Image This action changes the SRC of one image to another. This action is good for rollovers. Typically, the user would drop images onto the page (using the skyway image wizard) and make them invisible. Then, the user can change the SRC of a visible image to any of the other hidden ones. Toggle CSS Classes This action lets you toggle a CSS class on an element. If the element already has the class, it will be removed. If the element does not have the class, it will be added. This is a great action to use when you don't want to maintain style state. For example, you just want to display a down arrow if an up arrow is displayed or vice versa. You can specify more than one element and more than one style by separating them with commas in the input fields. Move Element This toggles the visibility of an element by setting its CSS display attribute. If the element is visible, the display will be set to none. If the element is not visible, the display attribute will be removed, causing the element to be displayed in its natural state, either inline or blocking. A DIV element is naturally blocking, for example, and a SPAN element is naturally inline. CSS Note: the display attribute can be set to inline, blocking or none. When set to none, the element is not visible and does not take up any space on the page. This differs from the visibility attribute, which can make an element invisible but it will still take up space on the page. Our visibility actions control the display attribute, as this is the desired behavior most of the time. You can specify more than one layer by separating them with commas. The Events properties panel makes it very easy for a developer to implement the application without getting bogged down with the details of html or javascript. However it's worthwhile to take a quick peek at how 49

58 Building Web Layer events and commands manifest themselves in JSP code. When you first start using Skyway Builder, you are encouraged to implement your web controls using the properties panel. As you become more proficient with Skyway Builder, you might start configuring the web controls directly in the JSP code. This fragment of JSP code is intended to show the layering web controls, events and commands. The implementation details have been intentionally excluded. Example 8.1. Event and Command - JSP Fragment <skyway:button label="click Here" type="submit"> <skyway:event event="onclick"> <skyway:submitform /> <skyway:loadurl /> </skyway:event> </skyway:button> The web control tag ( <skyway:button> ) defines the web control, and all event and command configurations are wrapped by the web control tag. The events are embedded in the web control using an event tag ( <skyway:event> ), which wraps all the commands associated with the event. Finally the command tags ( <skyway:command> ) define the Commands that should be executed for the event Using CSS Cascading Style Sheets (CSS) is a language for describing how an application should formatted. While there are a variety of options for formatting web pages, CSS is the pre-dominant choice because it's a standard supported by all modern web browsers, and it facilitates the separation of the structure of the page and the presentation (or style) of the page. There isn't really any special considerations regarding using CSS with Skyway applications. CSS can be used in exactly that same manner as classic web development. Some approaches to using CSS include: Adding inline CSS to broadly format a web application or format specific sections of a web application. Defining CSS in separate stylesheet files (.css) that are linked into the JSP page Configuring web controls with a CSS class that will inherit the style defined elsewhere (inline CSS or stylesheet) Most Skyway web controls have style properties panel that can be used to specify a CSS class and/or specify an inline style. In the case of inline styles, at runtime the visual rendering of the web control will be influenced by the embedded style. In the case of class attributes, the visual rendering of the web control (once again at runtime) will be influenced by a class definition. 50

59 Building Web Layer When defining the inline style, you can specify the style information directly into the Inline Style section of the style panel. Alternatively you can click on the Style Editor button to configure the style using a specialized CSS editor. The following JSP fragment shows how external CSS files can be linked into a web application. Example 8.2. Linking to external CSS files <head> <link href="${webcontextroot}/css/styles.css" rel="stylesheet" type="text/css" /> </head> The link tag ( <link> ) is a standard html tag for linking a stylesheet to a source HTML document. The href attribute specifies the location of the stylesheet. Typically the stylesheet of a web application will be located in the web application, and in the case of a Skyway project, the stylesheet will be added somewhere in the web content folder. The ${webcontextroot} variable is a convenient way to reference at runtime the root context of the web applicaiton. Since in this example the css file was added to a "css" folder in the web content folder, the reference to the css folder is appended to the url along with the name of the css file. Almost all of the sample projects on the Skyway Community site make use of CSS. Those projects would be a good reference for best practices in using CSS within a web application Integrating additional web resources The WebContents folder in a Skyway Project gives a web developer a lot of flexibility to organize the web content in any manner they desire. When creating a new project, Skyway will automatically add some folders and files to the WebContents folder. When using Skyway Builder Enterprise Edition, some additional folders and files are added. However a web developer can add whatever files they want to the WebContents folder. The files are usually related to the design of the web pages, and some typical items a developer may add are CSS files (as described earlier), javascript libraries, images, and flash controls. The approach for adding files to the WebContents folder is always the same: Copy the files into the WebContents folder. The files can organized using whatever folder structure is desire. Reference the files within the application by URL. Next some common examples will be described. 51

60 Building Web Layer Linking Images In web applications it is common to have a set of graphics that are re-used through-out an application. Some examples include banners, buttons, icons, and background images. By adding these images to a folder (i.e. images) in WebContents, the images will be automatically included in the deployed application. To reference these images from your application, you will need to access them by URL. For example if you add an image called logo.jpg to the images folder in WebContents, the image can be loaded into a JSP page using the following syntax: Example 8.3. Linking to images <body> <img src="${webcontextroot}/images/logo.jpg"/> </body> You will note that the ${webcontextroot} variable is used to prepend the context path to the specified URL. The remainder of the URL is based on the folder (images) and the file name (logo.jpg) Linking Javascript Javascript is a very powerful technology for specifying client-side logic that runs in the web browser. While a web developer using Skyway may not specify any javascript, applications produced with Skyway Builder make extensive use of Javascript. Many of Skyway's web controls will automatically emit javascript based on the configuration of the web control specified by the web developer. One of the WebContents folders that is automatically created with a new project is the "js" folder. This folder is used to store the javascript files used by Skyway's web controls. In the folder there are three javascript files. The prototype.js file is used to support Skyway's AJAX functionality, and the other two libraries are light-weight javascript libraries from Skyway for bridging the prototype library with Skyway's web controls. If you have some additional 3rd party or custom javascript libraries that you want to include in the web application, you can add them to the js folder (or any folder for that matter) and load them from your web application. For example if you add the script.aculo.us javascript library (scriptaculous.js) to the js folder in WebContents, the javascript library can be loaded into a JSP page using one of the following references: Example 8.4. Linking to javascript libraries <script src="${webcontextroot}/js/scriptaculous.js" type="text/javascript"/> </script> -or<skyway:javascript src="scriptaculous.js"></skyway:javascript> The first example uses the standard html <script> tag, and the src is specified using the ${webcontextroot} variable along with the a reference to the "js" folder and the filename. The second example uses the <skyway:javascript> JSP tag. The advantage of the JSP tag is that you only need to specify the name of the 52

61 Building Web Layer javascript file. The tag automatically derive the URL from the context root (so there's no need to specify the ${webcontextroot} variable), and it will automatically look in the js folder. 5. Model-View-Controller The most common way of describing design of dynamic web applications is to use the model-viewcontroller (MVC) architectural pattern. First the MVC layers will be described in the context of Skywaybased development, and then the interactions between the layers will be described Model-View-Controller Layers The model-view-controller (MVC) architectural pattern prescribes splitting and application into separate layers: the domain logic/model layer (model), the presentation layer (view), and user interaction layer (controller). The follow diagram is the classic MVC model for web applications. This MVC model is a logic view of the structure of an application. While the model can apply to all web technologies, the diagram is intentionally void of technology implementation details. The following sections show how the MVC is implemented using Skyway Builder JSP (View) Views are implemented as JSP pages, and Skyway provides various web controls for presenting data and soliciting input from user. The data available to a View is defined in a Web Conversation, which is configured with variables and constants that are available to all views in a project Web Controller/Conversations (Controller) If you look at the logic typically found in a web application, the logic is associated with either the behaviour of the application or business logic. The MVC pattern prescribes that the controller layer should be focussed on implementing the behaviour of the application. While a Web Conversation and associated Actions can be used to implement the behavior and business logic, the best practice is to exclude the business logic from the controller layer. However sometimes it's more practical (as in the case of prototyping) to implement the business logic in the controller. Each approach will be described. As shown in the following diagram, the first option is to put all the processing logic (behaviour and business logic) in the Web Conversation Actions. 53

62 Building Web Layer 1. The end-user can invoke events from the user interface. The events are passed to the controller layer, which processes the events per the specified behavior of the application. 2. In processing a user generated event, the controller interacts with the model, which contains the domain logic and domain model. 3. After the model has been updated, the Controller is responsible for determining the view to be returned (if any) to the end-user. Another option is to introduce a Service layer to the application. The service layer contains all the business logic, and the "Controller" Actions merely orchestrate the calls to the service layer. In this case, the role of "Controller" actions is limited to defining only the behavior of the application. The core application business logic is defined in the Service layer. 1. The end-user can invoke events from the user interface. The events are passed to the controller layer, which processes the events per the specified behavior of the application. 2. In processing a user generated event, the controller interacts with the model, which contains the domain logic and domain model. 3. After the model has been updated, the Controller is responsible for determining the view to be returned (if any) to the end-user. 54

63 Building Web Layer Data and Services (Model) The Model refers to the domain logic and domain model. As decribed in the Actions section, there are two fundamental choices for implementing Models. Actions can partly implement the model by implementing the domain logic themselves and manipulating the domain model directly. The alternative is to implement the model using a Service layer, which implements the domain logic and domain model changes. As described in an earlier chapter, the Service Layer can be implemented using Skyway Services that are located in the Skyway Project. The Service Layer can also be implemented in a variety of other manners, but in all cases there is a model. Some alternate service implementation examples include: Skyway Services located in other Skyway projects Web Services (i.e. to wire web application into BPM services) Java Implementations REST-full services from 3rd Parties 5.2. Model-View-Controller Interactions This section takes a closer look the interactions that occur between the model-view-controller layers in regards to Skyway Builder JSP to Action To associate JSP and Actions, configure a web control to invoke a URL in response to a user generated event. Skyway's web controls support all the relevant standard events (i.e. onclick, onblur, onfocus), and the controls can be configured to fire one or more Load URL commands for each event. Furthermore since a Web Conversation Action is addressable by URL (assuming there is a URL Action Mapping entry in the Web Controller), just about any 3rd-party or custom web control can invoke Actions Action to Model Depending on whether the domain logic is implemented in the Model or Action, an action invokes changes on the model through a service layer or through direct access to the domain model. To wire an Action to a service layer, the Action can use the invoke operation step. To wire an Action to the domain model, the Action can use the data access steps Model to Action In all cases model changes are communicated back to an Action via updated Web Conversation variables Action to JSP When an Action is done responding to the user event, the model updates need to be represented to the user through a JSP. The Action is responsible for determining the view, and there are several scenarios: No View - There are scenarios where there are no views specified. For example, the Action may be responding to a user generated event for which there's no presentation impact. One view - In this scenario, any and all Action invocations will result in a specific View being updated. 55

64 Building Web Layer Multiple Views - In this scenario, the Action can specify one of several possible Views. Under certain conditions the Action may direct a particular View to be rendered. In other conditions, the Action may direct another View to be rendered. 6. UI Composition Patterns For implementing user interfaces, Skyway uses Java Server Pages (JSP), a Java-based technology for the dynamic creation of content (i.e. html) to be delivered over HTTP. There are various ways of leveraging JSP to design user interfaces, and this section describes two patterns for composing user interfaces Page Centric Pattern The page centric pattern is a course-grained technique for utilizing JSP to compose a user interface. In this technique a single JSP implements the whole HTML page appearing in a web browser. At any point in time, the html content being viewed by the end-user of the web application was produced by a single JSP. As the end-user interacts with the application, they will be taken to different pages, which are each rendered by a different JSP. Figure 8.7. Page Centric Pattern In this pattern, every page in a userr web application is implemented using a single JSP Page Composition Pattern Another pattern for composing user interfaces using JSP is to decompose the end-user pages into finergrained units of dynamic content that are implemented individually using JSP. Each fine-grained unit is visually and functionally distinct, and they are typically a rectangular and easily identifiable element of a user interface. 56

65 Building Web Layer Figure 8.8. Page Composition Pattern If using this pattern, a user will need a way of assembling the units into a full user interface. Just because a UI is decomposed into fine-grained units, doesn't mean that the end-users need to consume them as fine-grained units. So the second part of this pattern is to define a JSP that composes a page from the elementary units. There are various mechanisms available in JSP for doing this, including JSP include, dynamic htm; loading (AJAX), and the Skyway embed JSP web control. Since the focus of this section is on the composition pattern, the implementation techniques will be described later in this guide. It's also worth mentioning that this pattern can leverage standard HTML features for structuring the fine-grained content into a full page, including tables, div/span and CSS. At runtime the composite JSP will render the fully composed user interface. The benefits of this pattern over the page-centric pattern are : Promote maximum reusability because the elementary units can be reused in other user interfaces Easier maintainability because updates are limited to one view (rather than updating the duplicated content in multiple views) Works well for both traditional and AJAX-based applications 7. Page Flow Patterns The previous sections describe the patterns for composing the user interface. This section describes the patterns for implementing page flow. 57

66 Building Web Layer Figure 8.9. Page Flow Patterns Page Flow Patterns Page-to-Page Page-to-Action Page Composition Page Composition (AJAX) For all the identified page flow patterns there is a distinguishable application flow concept: For every Action there is a View. In all cases a view is rendered after the invocation of an Action. As is the case with the Page to Page pattern, the view might be the originally requested web resource. With the other patterns, the view is determined by the processing that occurred in the action and optionally the requested URL Page-to-Page Pattern In this pattern, for a given JSP URL there can be an Action invocation (pre-load). When the Action has completed, the requested page will be rendered Page-to-Action Pattern In this pattern a user-generated event is configured to invoke an Action that processes the user event. When the Action is done, a JSP is rendered. In this scenario the JSP can be any JSP, and the JSP may be dynamically determined by the outcome of the Action. 58