skyway builder developer's guide · 2011-11-08 · java_persistence_api] 2.2.2. spring...

Skyway Builder Developer's Guide

June 24, 2008

Skyway Software

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

PublishedCopyright © 2008 Skyway Software

Abstract

Skyway Builder, a component of Skyway Visual Perspectives, is a model-driven development and deploymentplatform that enables developers to build and deliver Rich Internet Applications (RIAs) and Web Services fasterusing the Spring Framework with Hibernate for data persistence. This user guide is intended to introduce users tothe Skyway Builder environment and introduce the general development approach and design options. The SkywayBuilder embedded help will describe the steps and configuration options in more detail, and it is recommended as acompanion to this user guide.

iv

Table of Contents1. Skyway Visual Perspectives .............................................................................................. 1

1. Skyway Builder ...................................................................................................... 12. Architecture Overview ..................................................................................................... 2

1. Design-time Architecture .......................................................................................... 21.1. Key Technologies Used ................................................................................. 2

2. Execution-time Architecture ...................................................................................... 32.1. Deployment ................................................................................................. 42.2. Key Technologies Used ................................................................................. 5

3. Environment Overview .................................................................................................... 81. Eclipse Concepts .................................................................................................... 82. Skyway Builder Versions ......................................................................................... 83. Skyway Buider's Eclipse-based Components ................................................................ 9

3.1. Skyway Views ........................................................................................... 103.2. Skyway Toolbars and Menus ........................................................................ 103.3. Editors ...................................................................................................... 11

4. Application Development ............................................................................................... 121. Skyway Development Artifacts ................................................................................ 122. Project Meta-data Model ........................................................................................ 123. Application Layering ............................................................................................. 14

3.1. Web Layer ................................................................................................ 153.2. Service Layer ............................................................................................. 153.3. Data Layer ................................................................................................ 15

4. Development Process ............................................................................................. 164.1. Development Steps ..................................................................................... 16

5. Create Project ............................................................................................................... 171. Projects ............................................................................................................... 172. Project Configurations ............................................................................................ 17

2.1. General Info .............................................................................................. 172.2. Project Variables ........................................................................................ 182.3. Project Constants ........................................................................................ 182.4. View Mappings .......................................................................................... 18

6. Data Layer ................................................................................................................... 191. Domain Model ...................................................................................................... 19

1.1. Implementing the Domain Model ................................................................... 192. Basic Data Types .................................................................................................. 203. Data Types .......................................................................................................... 20

3.1. Defining Fields ........................................................................................... 213.2. Defining Relationships ................................................................................. 213.3. Persistence Mapping .................................................................................... 22

4. Data Stores .......................................................................................................... 224.1. Data Operations .......................................................................................... 234.2. Named Queries ........................................................................................... 23

5. Leveraging Existing Databases ................................................................................ 245.1. Importing Types ......................................................................................... 25

6. Using Data Types from Other Sources ...................................................................... 266.1. Java Beans ................................................................................................ 266.2. Web Services ............................................................................................. 27

7. Service Layer ............................................................................................................... 281. Skyway Service .................................................................................................... 282. Operations ........................................................................................................... 29

2.1. Operation Interface ..................................................................................... 29

Skyway Builder Developer's Guide

v

2.2. Operation Resources .................................................................................... 302.3. Recursion .................................................................................................. 31

3. Actions ................................................................................................................ 313.1. Steps ........................................................................................................ 31

4. Custom Java Code ................................................................................................. 354.1. Embedding Java Code ................................................................................. 364.2. Calling Java Libraries .................................................................................. 364.3. Using Groovy ............................................................................................ 36

5. Web Services ....................................................................................................... 365.1. Consume Web Services ............................................................................... 365.2. Produce Web Services - Model First Development ............................................ 375.3. Produce Web Services - Contract First Development ......................................... 37

8. Building Web Layer ...................................................................................................... 381. Web Controllers .................................................................................................... 38

1.1. URL Action Mapping .................................................................................. 382. Web Conversations ................................................................................................ 40

2.1. Variables ................................................................................................... 422.2. Constants .................................................................................................. 42

3. Actions ................................................................................................................ 433.1. Steps ........................................................................................................ 43

4. Building Views ..................................................................................................... 444.1. JSP Pages .................................................................................................. 444.2. Web Controls ............................................................................................. 454.3. Using CSS ................................................................................................. 504.4. Integrating additional web resources ............................................................... 51

5. Model-View-Controller .......................................................................................... 535.1. Model-View-Controller Layers ...................................................................... 535.2. Model-View-Controller Interactions ............................................................... 55

6. UI Composition Patterns ......................................................................................... 566.1. Page Centric Pattern .................................................................................... 566.2. Page Composition Pattern ............................................................................ 56

7. Page Flow Patterns ................................................................................................ 577.1. Page-to-Page Pattern ................................................................................... 587.2. Page-to-Action Pattern ................................................................................. 587.3. Page Composition Pattern ............................................................................ 597.4. Page Composition (AJAX) Pattern ................................................................. 59

9. Deploying Applications .................................................................................................. 601. Deployment Explained ........................................................................................... 602. Runtime Architecture ............................................................................................. 603. Deployment Models ............................................................................................... 604. Community Edition Deployment Options ................................................................... 60

4.1. Option 1 ................................................................................................... 604.2. Option 2 ................................................................................................... 60

5. Enterprise Edition Deployment Options ..................................................................... 605.1. Option 1 ................................................................................................... 615.2. Option 2 ................................................................................................... 61

6. Changing Databases ............................................................................................... 617. Run Application .................................................................................................... 61

10. Security ..................................................................................................................... 621. Securing Project Resources ..................................................................................... 622. Securing Services .................................................................................................. 623. Authorization ........................................................................................................ 62

vi

List of Figures1.1. Skyway Visual Perspectives ........................................................................................... 12.1. Design-time Architecture ............................................................................................... 22.2. Execution-time Architecture ........................................................................................... 42.3. Web Only Deployment (WAR) ....................................................................................... 52.4. Full JEE Deployment (EAR/WAR/EJB3) .......................................................................... 53.1. Skyway Toolbar ......................................................................................................... 104.1. Project Meta-Data Model ............................................................................................. 134.2. Skyway Navigator ...................................................................................................... 144.3. Application Layers - High-Level ................................................................................... 154.4. Development Steps Overview ....................................................................................... 166.1. Domain Model (Banking Example) ................................................................................ 196.2. Data Types (Banking Example) ..................................................................................... 216.3. Data Stores (Banking Example) ..................................................................................... 237.1. Skyway Service .......................................................................................................... 287.2. Operations ................................................................................................................. 297.3. Operation Actions ....................................................................................................... 317.4. Skyway Builder CE - Action Steps ................................................................................ 328.1. Skyway Web Controller ............................................................................................... 388.2. Conversation .............................................................................................................. 418.3. Conversation Example: Survey Entry ............................................................................. 428.4. Web Conversation Actions ........................................................................................... 438.5. Skyway Conversation - Action Steps .............................................................................. 448.6. Skyway Site ............................................................................................................... 448.7. Page Centric Pattern .................................................................................................... 568.8. Page Composition Pattern ............................................................................................ 578.9. Page Flow Patterns ..................................................................................................... 58

vii

List of Tables3.1. Skyway Builder Editions ............................................................................................... 93.2. Skyway Builder Distribution/Download Methods ............................................................... 96.1. Skyway Basic Data Types ............................................................................................ 206.2. Relationship Types ...................................................................................................... 226.3. JPA Query Examples .................................................................................................. 246.4. Comparison of Native and External Data Models .............................................................. 256.5. Scenarios for using external data models ......................................................................... 257.1. Step Group: Data Manipulation Steps ............................................................................. 337.2. Step Group: Service Steps ............................................................................................ 347.3. Step Group: Flow Steps ............................................................................................... 347.4. Step Group: Exception Steps ........................................................................................ 357.5. Step Group: Transaction Management Steps .................................................................... 357.6. Web Service WSDL to Skyway Mappings ...................................................................... 378.1. Request Mapping Parameters ........................................................................................ 398.2. Request Mapping Parameter Examples ........................................................................... 408.3. Skyway Web Controls - Part 1 ...................................................................................... 458.4. Skyway Web Controls - Part 2 ...................................................................................... 468.5. Event Descriptions ...................................................................................................... 478.6. Skyway Commands - Part 1 ......................................................................................... 488.7. Skyway Commands - Part 2 ......................................................................................... 49

viii

List of Examples8.1. Event and Command - JSP Fragment ............................................................................. 508.2. Linking to external CSS files ........................................................................................ 518.3. Linking to images ....................................................................................................... 528.4. Linking to javascript libraries ....................................................................................... 52

1

Chapter 1. Skyway Visual PerspectivesSkyway Visual Perspectives (SVP) is a family of Eclipse-based tools, and SVP aims to deliver an easy-to-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 OrientedArchtiecture (SOA) ecosystem.

Figure 1.1. Skyway Visual Perspectives

1. Skyway BuilderSkyway Builder, fully integrated into Eclipse, is a model-driven development and deployment platformthat enables organizations to build and deliver Rich Internet Applications (RIAs) and Web services fasterthan 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 applicationservers at the push of a button. Developers maintain maximum design and development flexibility viamodeling capabilities or via traditional coding techniques in their efforts to build rich and meaningfulweb applications because they are no longer bogged down by the redundant, tedious tasks of today’ssoftware delivery. Solutions built with Skyway Community Edition (CE) are based on common Eclipsestandards, including EMF, GMF, and WTP, and all solutions are deployed using the Spring Frameworkwith Hibernate data persistence.

2

Chapter 2. Architecture Overview

1. Design-time ArchitectureSkyway Visual Workspace is a set of Eclipse plugins. Eclipse provides a workspace where SkywayBuilder's functionality can run side-by-side with plugins from other sources. In addition to leveragingthe Eclipse plug-in architecture, Skyway Builder is implemented using the technology of various otherEclipse technologies, including the Eclipse Modeling Project, the Web Tools Project, and the DataTools 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.

1.1.1. Eclipse IDE and Workspace

Skyway Builder leverages the Eclipse plugin architecture for adding modelingcapabilities to Eclipse.

— Eclipse Web Tools Platform Project Site [http://www.eclipse.org/webtools/]

http://www.eclipse.org/webtools/


Architecture Overview

3

1.1.2. Eclipse Modeling Framework (EMF) Project

Skyway Builder leverages a lot of Eclipse technologies. While EMF is a general purpose modelingframework, 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 toolsand other applications based on a structured data model. From a model specificationdescribed in XMI, EMF provides tools and runtime support to produce a set of Javaclasses for the model, along with a set of adapter classes that enable viewing andcommand-based editing of the model, and a basic editor.

— EMF Project Site [http://www.eclipse.org/modeling/emf/]

1.1.3. Eclipse Web Tools Platform (WTP) Project

The Eclipse Web Tools Platform (WTP) project extends the Eclipse platform with toolsfor developing Web and Java EE applications. It includes source and graphical editorsfor 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 [http://www.eclipse.org/webtools/]

1.1.4. Eclipse Data Tools Project (DTP)

For database connections— Eclipse JEE Tools Project Site [http://www.eclipse.org/webtools/jee/]

2. Execution-time ArchitectureSkyway Builder generates ready-to-run Spring-based web applications and services. The generatedapplications, which can be deployed to open-source and commercial JEE application servers, makeextensive of Spring technologies and projects, including Spring Core and spring MVC.

http://www.eclipse.org/modeling/emf/

http://www.eclipse.org/modeling/emf/



http://www.eclipse.org/webtools/jee/

http://www.eclipse.org/webtools/jee/


4

Figure 2.2. Execution-time Architecture

2.1. Deployment

The development artifacts used in model-centric development with Skyway Builder are higher-leveldevelopment concepts than JEE. While these artifacts will ultimately be generated and deployed as JEEcomponents, familiarity with JEE components isn't required when developing with Skyway Builder. InJEE there are essentially two deployment scenarios, web-only and web/ejb3, and Skyway Builder supportsboth deployment scenarios.

Unlike typical JEE development, the deployment scenario doesn't need to be determined at the beginningof the development process. A developer will build the application in exactly the same manner, and thedeployment will be configured when the application is ready to run. Whether a developer is deployingto a sandbox or to a production server, the process is exactly the same. The developer will specify theruntime infrastructure, and the models will be generated into JEE applications matching the configuredinfrastructure.

2.1.1. Web Only Deployment (WAR)

Web-only deployments (WAR), which has been popularized by the Spring framework, consists ofdeploying applications to a servlet container and augmenting the application with transaction managementand persistence functions.


5

Figure 2.3. Web Only Deployment (WAR)

2.1.2. Full JEE Deployment (EAR/WAR/EJB3)

Full JEE deployment is a configuration where components are distributed between the servlet and EJBcontainers.

Figure 2.4. Full JEE Deployment (EAR/WAR/EJB3)

2.2. Key Technologies UsedHere is a listing and brief description of the key runtime technologies used.

2.2.1. Java Persistance API (JPA)

The Java Persistence API, sometimes referred to as JPA, is a Java programming languageframework that allows developers to manage relational data in Java Platform, StandardEdition and Java Platform, Enterprise Edition applications.

Persistence consists of three areas:


6

1. the API, defined in the javax.persistence package

2. the Java Persistence Query Language

3. object/relational metadata

— Eclipse JEE Tools Project Site [http://en.wikipedia.org/wiki/Java_Persistence_API]

2.2.2. Spring Framework

Spring is a Java/J2EE application framework.

Features of Spring:

• The most complete lightweight container, providing centralized, automatedconfiguration 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 andleverage, and improves application testability and scalability by allowing softwarecomponents to be first developed and tested in isolation, then scaled up fordeployment in any environment (J2SE or J2EE).

• A common abstraction layer for transaction management, allowing for pluggabletransaction managers, and making it easy to demarcate transactions without dealingwith low-level issues. Generic strategies for JTA and a single JDBC DataSource areincluded. In contrast to plain JTA or EJB CMT, Spring's transaction support is nottied to J2EE environments.

• A JDBC abstraction layer that offers a meaningful exception hierarchy (no morepulling vendor codes out of SQLException), simplifies error handling, and greatlyreduces the amount of code you'll need to write. You'll never need to write anotherfinally block to use JDBC again. The JDBC-oriented exceptions comply to Spring'sgeneric DAO exception hierarchy.

• Integration with Toplink, Hibernate, JDO, and iBATIS SQL Maps: in terms ofresource holders, DAO implementation support, and transaction strategies. First-classHibernate support with lots of IoC convenience features, addressing many typicalHibernate integration issues. All of these comply to Spring's generic transaction andDAO exception hierarchies.

• AOP functionality, fully integrated into Spring configuration management. You canAOP-enable any object managed by Spring, adding aspects such as declarativetransaction management. With Spring, you can have declarative transactionmanagement without EJB... even without JTA, if you're using a single database inTomcat or another web container without JTA support.

• A flexible MVC web application framework, built on core Spring functionality. Thisframework is highly configurable via strategy interfaces, and accommodates multipleview technologies like JSP, Velocity, Tiles, iText, and POI. Note that a Spring middletier can easily be combined with a web tier based on any other web MVC framework,like Struts, WebWork, or Tapestry.

http://en.wikipedia.org/wiki/Java_Persistence_API




7

You can use all of Spring's functionality in any J2EE server, and most of it also in non-managed environments. A central focus of Spring is to allow for reusable business anddata access objects that are not tied to specific J2EE services. Such objects can be reusedacross J2EE environments (web or EJB), standalone applications, test environments, etcwithout any hassle.

Spring's layered architecture gives you a lot of flexibility. All its functionality buildson lower levels. So you can e.g. use the JavaBeans configuration management withoutusing the MVC framework or AOP support. But if you use the web MVC framework orAOP support, you'll find they build on the configuration framework, so you can applyyour knowledge about it immediately.

— Spring Framework - About [http://www.springframework.org/about]

2.2.3. Hibernate

Spring uses Hibernate for persistence framework.

Hibernate is a powerful, high performance object/relational persistence and queryservice. 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), aswell as in native SQL, or with an object-oriented Criteria and Example API.

— Hibernate [http://www.hibernate.org/]

http://www.springframework.org/about

http://www.springframework.org/about

http://www.hibernate.org/

http://www.hibernate.org/

8

Chapter 3. Environment Overview

1. Eclipse ConceptsThis 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 variouscomponents to it, including editors, views and perspectives.

• Editors - Editors are located in the main section of the workbench. Eclipse Editors are added to Eclipseby 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 beingperformed within the editor. Views can also provide context-sensitive data related to the activity. Viewsare added to Eclipse by Eclipse plug-ins.

• Perspective - A perspective is a visual container of views, editors, and menu/toolbar commands thatare configured for a particular task. Perspectives are added to Eclipse by Eclipse plug-ins. A perspectivealso specifies the default layout of the views that can be used as-is, or you can customize the perspectiveaccording 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. Sinceyou 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 Eclipseto use your selected workspace as the default workspace, so that you won't be prompted everytime youstart-up Eclipse.

• Project - A project is a container for resources associated with the activity being performed by a userof a particular plug-in or set of plugins. Projects are associated with one and only one workspace, andthe type of project is determined by project natures.

• Natures - Project natures describe behavioral aspects of a project. Natures associated a project withplugins.

• Wizards - During the creation of the new artifacts, wizards are used to prompt the user for requiredinformation (i.e. name) and optional information.

• Preferences - Preferences provide a standard dialog for managing the preferences of Eclipse plug-insthat are installed in the workbench,

2. Skyway Builder VersionsThe following table describes the different versions of Skyway Builder that are available.

Environment Overview

9

Table 3.1. Skyway Builder Editions

Edition Description

Skyway Builder Community Edition (CE) the community edition of Skyway Builder; open-source

• build complete JEE web applications based onSpring Framework

• web-only deployment (WAR files for servlet/jspcontainer)

• deploy to open-source application servers(Tomcat, Jetty, JBoss)

Skyway Builder Enterprise Edition (EE) the enterprise edtion of Skyway Builder; addsenterprise features to the community edition

• consume and produce web services; contract-first web services development

• graphically define transaction boundaries(transaction management)

• simplified security authentication; use LDAP,simple DB or any other Spring-supportedsecurity realm

• web/ejb3 deployment (EAR files for servlet andejb containers)

• deploy to commercial application servers

• includes enterprise-class JDBC drivers forcommercial 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 Skywayplugins

Skyway Builder Eclipse Plugin for adding Skyway plugins and perspective toexisting installation of Eclipse 3.3

Source Code available for download; create your own build

More information can be found at the Skyway Communtity site [www.skywayperspectives.org].

3. Skyway Buider's Eclipse-based ComponentsSkyway Builder is a set of Eclipse plugins that provides functionality to build web applications. In additionto enabling developers to leverage Skyway's functionality in a familiar environment, it also let's SkywayBuilder co-exist with other tools (plug-ins) in one integrated environment.

www.skywayperspectives.org



10

As described earlier, an Eclipse perspective is a visual container of views, editors, and menu/toolbarcommands that are configured for a particular task. The Skyway Builder Perspective represents aset of views, editors and menu/toolbar commands for the model-driven development of dynamic webapplications based on the Spring framework and Hibernate persistence.

The various components of Skyway Builder Perspectives will be described next.

3.1. Skyway Views

3.1.1. Skyway Navigator

The Skyway Navigator is an Eclipse view for navigating the resources of a Skyway Project.

3.2. Skyway Toolbars and Menus

3.2.1. Skyway Toolbar

When using the Skyway Builder perspective, the Skyway Toolbar provides toolbar access to Skywayfunctions, including creation, deployment and execution.

Figure 3.1. Skyway Toolbar


11

3.2.2. Skyway Menus

3.3. Editors

3.3.1. Skyway Editors

Just about every Skyway-related resource has an Editor for configuring and modelling the implementationof the artifact.

Skyway Editors

• Project Editor

• Service Editor

• Operation Editor

• Action Editor

• Web Controller Editor

• Web Conversation Editor

• Data Type Editor

• Data Store Editor

12

Chapter 4. Application Development

1. Skyway Development ArtifactsWithin Skyway Visual Perspectives, there are graphical (and abstract) representations of object types andactions that can be taken against these types. These object types often have direct correlations to Javaartifacts 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 madewithin 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 forthe 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 environmentwhen persistence is needed. During deployment Data Stores are bound to a real, physical implementationof 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 Stepstogether.

• Web Controllers are used to implement the Web layer of an application, and they have one or moreConversations.

• Web Conversations are task-based groupings of logic for handling user event. Conversations areimplemented 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 modelsbecome code and are executed.

2. Project Meta-data ModelEverything you create in Skyway Builder will manifest itself as project meta-data, and meta-data has ahierarchy that is referred to as the Skyway Meta-Data Model. This model defines the boundaries of aproject.

Application Development

13

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 areonly 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. Thismetadata 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 bedownloaded as a sample application from Skyway Communtity site [www.skywayperspectives.org].




14

Figure 4.2. Skyway Navigator

3. Application LayeringA web application is logically separated into three layers: the data layer, the service layer, and the weblayer. 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 toimplement this layer.


15

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 presentingthe user interface and the behavior of the application (handling user interactions/events). While the weblayer 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.

3.2. Service Layer

The service layer is also referred to as the logic layer or business layer. The service layer represents thecore functionality of the application being built. The web layer is the primary consumer of the functionalityprovided by the service layer. The service layer can also provide interfaces for other applications toconsume 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.

3.3. Data Layer

The data layer is also referred to as the persistence layer or domain object layer. The data layeris represented by a domain model; a distinct set of inter-related application objects that embody thefunctionality and characteristics of the system being built. This layer also encompasses the persistence ofthe 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, andthey will be described in detail in a following chapter.


16

4. Development Process

4.1. Development StepsApplication development with Skyway Builder generally consists of five steps. Over the next few chapterseach 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.

17

Chapter 5. Create Project

This chapter will describe the artifacts and configurations associated with defining the Skyway Project.

1. ProjectsProjects are the top level development artifact within Skyway Builder. All other Skyway artifacts mustreside inside a project. In many cases a web application is implemented as a single project, with theproject containing any and all artifacts needed to provide its functionality. Since a project can referencedevelopment 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 ofartifacts for version control and deployment. When putting a project under version control, all the projectartifacts must be version controlled in the project's version control configuration. Similarly a projectrepresents a unit of deployment. As a project is deployed, all the development artifacts in the project aredeployed 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 partitioningof its development artifacts across containers is determined at deployment time. Deployment isdiscussed in greater detail in Chapter 8.

The Skyway Navigator will display all the Skyway Projects in an Eclipse Workspace. You can work onmultiple Skyway Projects at the same time.

2. Project Configurations

2.1. General InfoProject name uniquely identifies the project, and the name is used to for name-spacing the meta-data andgenerated artifacts. The description might include:

Common uses for Project Description

• a high-level functional description of the project

• design and/or implementation notes

Create Project

18

• project meta-data (functional owner, developed by, etc...)

2.2. Project VariablesProject variables are variables that are available to any and all project artifacts. Project variables aresession 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 adverselyimpact the scalability of your application. Therefore it's generally recommended to use of project variablessparingly. The alternative to project variables are Operation and Conversation variables.

2.3. Project ConstantsProject constants are fixed variables whose values are defined at design-time. A project constant functionslike Operation constants and Web Conversation constants, except the Project constants are accessible byall artifacts in the project. This is a great place to keep constants that are shared across the entire project.

2.4. View MappingsThere are several places in a project where you may reference a JSP page. Directly referencing Java ServerPages (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'thard-coded in Web Controllers or Web Conversations.

The URL (Alias) is the alias used to reference the view resource.

19

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 thecomponents of the data layer will be described in greater detail.

1. Domain ModelAn application typically consists of a distinct set of inter-related application objects that embody thefunctionality and characteristics of the system being built. All of the application objects are cumulativelyreferred to as the domain object model.

A development effort usually begins with analysis of the problem domain, and domain modeling isfrequently the first step in designing an application. Domain modeling is the analysis of data objects thatare used in a business, analysis of the attributes of those objects, and the identification of the relationshipsbetween 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 theattributes of the domain objects and relating the data types to each other. The domain objects become DataTypes, and the object attributes become fields in the respective Data Type. The relationship lines in thedata model become the relationships in the Data Types.

Data Layer

20

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 TypesAll applications work with data, and data types specify the kind of data that can be stored and manipulatedwithin a program. Skyway supports a number of fundamental basic data types (scalar data types), whichare 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 beunique

Text Use to store text or combinations of text and numbers, as well as numbersthat do not require calculations (i.e. phone numbers); defaults to 100 but canbe 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 20digits on the left side of the decimal separator and up to 10 digits on the rightside of the decimal separator

Date and Time Use to store date and time data; valid ranges date ranges are between January1, 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 exceed2000 characters; defaults to 100 but can be up to a maximum length of2,147,483,647 characters

Date Use to store date data; valid ranges date ranges are between January 1, 1753and 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 TypesData Types are used to define domain objects that will be utilized within an application. You can addobject attributes by using the basic data types, and you can also specify relationships to other Data Typesand their cardinality.

The following figure shows how the Banking Domain Model would possibly be implemented in a Skywayproject:

Data Layer

21

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.

3.1. Defining FieldsFor each attribute of the domain object being implemented, specify a field name and field type. The fieldtype can be any of the supported basic data types described earlier (i.e. Text, Decimal, Integer, etc...).

3.1.1. Primary Keys

You can specify the field or fields that uniquely identify the object. Composite keys are supported.

3.1.2. Collections

By default a field is scalar; it can store one value of the basic type that is specified. If you mark the fieldas a collection, the field becomes a composite field that can store one or more values of that data type.

3.2. Defining RelationshipsData Types can be related to each other data types in the same data store. Relationships cannot spanmultiple data stores. When defining a relation for a data type, you must specify the related data type, therelationship type, and the relationship names.

Note:

While relationships are usually defined between two different data types, a data type can also berelated to itself. For example, a "category" data type can have a relationship to itself to representsub-categories.

3.2.1. Relationship Type

The Relationship Type defines the cardinality of the relationship from the perspective of the current DataType. The options are:

Data Layer

22

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 oppositeside of a Many-to-One relationship

Many-to-One a data type is related to a single occurrence of the other data type; theopposite side of a One-to-Many relationship

Many-to-Many a data type is related to many occurrences of the other data type, and viceversa

3.2.2. Bidirectional Relationships

When a relationship is added to another data type, a unidirectional relationship is implied. Two independentunidirectional relationships can be linked together to create a bidirectional relationship. If you decide todefine a bidirectional relationship, the cardinality and relationship names need to match.

3.2.3. Relationships Names

When defining a relationship between two data objects, the Data Type editor will prompt you for arelationship 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 currentdata type.

Once last thing about relationship names, the Data Type editor will default the data type name as therelationship names, but you can very easily changed the name. As a matter of fact it’s a good idea tochange these relationship names to something more semantically meaningful. While they have no impacton the functionality, these names will be the what you will see as your referencing these relationships inthe services you create. So make these names meaningful, and it’s recommended that you name them withthe appropriate plurality for the relationship type.

3.3. Persistence MappingThe Persistence Mapping panel lets you influence how the a data type is persisted to a database. Whena new data type is created, Skyway Builder will automatically create default persistence mapping valuesbased on the definition of the data type. For example: if the data type is named Customer, then the tablename will be defaulted to customer. However if you want to use a different table name, you can overridethe auto-generated persistence configuration.

If you're familiar with JPA, then the configuration settings should look pretty familiar. These settings aredirectly related to JPA annotations. As you make changes to the Persistence Mapping panel, the annotationsin the code associated with the data types will be automatically updated.

4. Data StoresData Stores are abstract representations of real databases (or persistence mechanisms), and they managepersistence for a set of data types. When designing the models there is no need to know the detailof the database (vendor, version, IP, etc.), but simply a need to know that one exists for modelingdatabase activity. When models are deployed, the developer late binds each Data Store to a real, physicalimplementation of a database.

Data Layer

23

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 toaccess 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 performstandard data operations (search, update, delete) or named queries. Each of these will be described next.

4.1. Data OperationsFor every data type added to a Data Store, the developer can perform basic persistence functions using theModify Data Store and Search Data Store steps. These functions are often referred to as CRUD (create/insert, read, update, and delete).

4.2. Named QueriesA 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 thequery 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 moremore difficult to manage where and how the data access is occurring because the queries are contained inthe generated code. On the other hand named queries are all located with their associated data store. Thismakes it a lot easier for developer to find the query for re-using, repurposing or optimizing.

4.2.1. 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.

Data Layer

24

4.2.2. 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 DatabasesThere may be occasions where a data model already exists, and you don't want to implement the domainmodel with Skyway. This can occur when the data model was defined by a different group (not usingSkyway Builder) or when building on top of an existing application. In either case, you need a way toleverage the pre-existing data model from Skyway.

In Skyway Builder there are essentially two ways implement a data model in a Skyway solution: nativelyand externally. Using the native approach, the data model is defined in Skyway, and Skyway produces thedatabase 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 followingtable summarizes the differences with choosing externally defined data models versus natively defineddata models.

Data Layer

25

Table 6.4. Comparison of Native and External Data Models

Native External

Defined in an object-oriented manner; the patternsfor storing object-oriented data in relationaldatabases are very well defined and handled by theORM framework and JPA provider.

Defined in a relational manner with object-oriented facade; relational schemas don't translateperfectly to objects.

Data model created in same applicationdevelopment environment

Data model must be defined using separate tools;all developers will need access to DBMS clienttools

Data model changes are immediately available inthe Skyway project

Data model must be rediscovered before beingavailable to Skyway project

Data model can easily evolve during applicationdevelopment; the initial definition of the datamodel 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 bewell defined

Data model changes are version controlled withthe other application development artifacts; easierto identify correct data model implementation forearlier 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 getinvolved too

Data model can be deployed to any DBMS;maximum deployment flexibility

The data model is tied to the DBMS that it wasderived from

Sharing project is simply a matter of copyingproject folder

Sharing project requires copying the project folderand providing the ddl for the database

While native data models offer maximum flexibility, there are occasions where external data models are theonly 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 Interfacetables

To facilitate external applications integrating with Skyway application at DBlevel

DB CentricDevelopment

You just absolutely can't start development without have the data modelcompletely defined in a relational database

5.1. Importing Types

Using externally defined tables is accomplished using the Import Types wizard, which can be accessedfrom the Database Configuration tab in the Data Store Editor. Once the data types are discovered, theycan be used just like data types created in Skyway.

Here are the general steps for importing data types:

Data Layer

26

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 tablesyou want to import. If the a database connection hasn't been defined, you must create the databaseconnection 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 theDatabase Configuration tab.

4. Select the schema - The schema dropdown will show a list of schemas available from the databaseconnection. 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 theSkyway Builder project.

7. Click Finish - Skyway Builder will analyze the tables and create the data types corresponding the tablesthat were imported.

6. Using Data Types from Other SourcesData 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.

6.1. Java BeansJava 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 ofthe seemless blending of modelling and coding, you can also use java beans created outside of SkywayBuilder. They may exist in java libraries that you include in your project, or they can be java beans classesthat you add directly to your project. In either case they would manifest themselves in your Skyway projectas 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 srcfolder 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 showyou the data types that were created in the Skyway project. When this option is enabled, you can searchand select from all java beans added to project. Since the java bean list can be very long, you need to typea few letters of the java bean in order to start the filtering process.

Data Layer

27

6.2. Web ServicesWhether importing for consumption or contract-first development, the complex types defined in a WSDLwill be generated into Skyway data types. When importing a WSDL for the purpose of consuming webservices, these data types can be used to from Skyway to pass data to and from the service. When importinga WSDL for the purpose of contract-first development, the data types will be generated to facilitate theimplementation of the services.

28

Chapter 7. Service Layer

This chapter will describe the artifacts and configurations associated with implementing the ServiceLayer.

The Service layer represents the core functionality of the application being built. The primary consumer ofthe 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 andoutputs.

This section will give you an overview of building the service layer of an application using Skyway Builder.

1. Skyway ServiceA Skyway Service is an artifact that defines a set of functions. Functions are application logic that usestructured inputs and outputs for exchanging data. In Skyway development the functions are defined asOperations, 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 theService layer of an application. This doesn't mean that web services are being used for invocation. Skywaywill use java invocation by default, so there isn't any of the additional overhead of web services. HoweverSkyway Services can also be exposed as web services by configuration (see Scope), in which case theSkyway Service concepts map exactly to the equivalent web service concepts.

Service Layer

29

2. OperationsService functions are specified as Operations, which represent stateless application logic. In additionto a name and description, the operation definition consists of an operation interface and operationresources. The application logic of an operation is implemented using a sequence of Actions (discussedin a later section), which represent a single thread of execution. An operation doesn’t supportconcurrent threads of execution, thus simplifying modeling by eliminating complex behaviors arising frommultithreading.

Figure 7.2. Operations

2.1. Operation InterfaceThe operation interface defines the formal contract between the operation and the consumers of theoperation.

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

2.1.1. Operation Name

This is the name that consumers use to refer to the operation; a general guideline is to define Operationsusing a functional “verb and noun” expression. This usually is a great starting point for determiningthe appropriate level of granularity, and the consumers of the Operation understand the specific serviceprovided by the Operation.

2.1.2. Inputs

Inputs are a mechanism for exchanging data with the consumer of the operation, and they define partof the operation contract. When a consumer calls an operation, they must provide all the input variablesdefined by the operation.

Input variables are exactly like operation variables, which means any action steps may access the inputvariable the same way they access operation variables.

Service Layer

30

2.1.3. Outputs

Outputs are another mechanism for exchanging data with the consumer of the operation, and they alsodefine part of the operation contract. When a consumer calls an operation, they must accept all the outputvariables defined by the operation.

Output Variables cannot be manipulated directly by the Operation steps. The output variables are assignedtheir value by selecting the Assigned To value on the Output sub-tab. Any variable from either theVariables tab or Inputs tab can be assigned to the output variables.

2.1.4. Exceptions

If any exception occurs and it is not listed in the operation interface, the exception will be ignored.

2.2. Operation ResourcesOperation 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 haveany 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 canconsist of one or more Actions, and the operation must be configured with the Action that should becalled first upon invocation of the operation.

2.2.1. Variables

The variables defined in an Operation are available to all actions in the operation. These variables areused 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. Operationvariables aren't maintained across calls.

2.2.2. Constants

An operation constant is a fixed variable whose value is defined at design-time. An operation constantfunctions like Project constants and Web Conversations constants, except the operation constants are onlyaccessible to operation actions. This is a great place to keep constants that are only needed in the operation.

Service Layer

31

2.2.3. Actions

The application logic for an operation is implemented using Actions. Actions are described in more detailin the next section.

2.2.4. Entry Point Action

The Entry Point Action represents the starting point of the operation. An operation will consist of at leastone or more Actions, and the operation must be configured with the Action that should be called first uponinvocation of the operation.

2.3. RecursionRecursion refers to an algorithm that contains itself in one or more of its component steps. This is a commonIT pattern with hierarchical data. Skyway supports the recursive invocation of operations and actions.

3. ActionsWhile the operation defines the interface and resources needed for an application function, the functionalityis actually implemented (modeled) using Actions. The developer defines the logic to be performed bysequencing steps together.

Figure 7.3. Operation Actions

An operation must have at least one Action. In order to accomplish more complex tasks the applicationlogic may be implemented using several Actions. By breaking an operation down into smaller pieces, theoperation logic may become easier to follow and maintain. For a given operation there will be one actionthat will serve as the entry point. The entry point Action is defined in the Operation editor. For every callto the operation, the entry point action will invoked first, which can call other actions using the InvokeAction step.

3.1. StepsWhen implementing actions, there is toolbox (palette) that contains a set of functional steps that areavailable 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 orimplementing 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 redundancyof application development. Rather than continuously having to write the same code over and over withonly minor differences, steps automate the generation of code for the developer. By using steps there

Service Layer

32

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 ensuresthat 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 benefitfrom automation, you can add new custom steps to the toolbox. As a matter of fact, all the steps includedin Skyway Builder were implemented using the plugin architecture.

Figure 7.4. Skyway Builder CE - Action Steps

Service Layer

33

3.1.1. Data Manipulation Steps

Table 7.1. Step Group: Data Manipulation Steps

Name Description

Search Collection

The Search Collection step allows a user to search or read thecontent of a Collection that has been created in Skyway Builder.Complex expressions can be created using operators, functions,constants, and variables.

Modify Collection

The Modify Collection step modifies the content of a Collection. Itallows a user to add, delete or update objects in a Collection.

Search Data Store

The Search Data Store step allows a user to search the content ofa Data Store that has been created in Skyway Builder. Complexexpressions can be created using operators, functions, constants, andvariables.

Modify Data Store

The Modify Data Store step modifies the content of a Data Store. Itallows a user to add, delete or update objects in a Data Store.

Named Query

The Execute Named Query step will invoke a named query definedin a Data Store.

Execute SQL

The Execute SQL step allows a user to issue SQL statementsdirectly to an underlying RDBMS. This is useful, for example,for calling stored procedures that are defined within the databasesystem. 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 toa variable or Collection using this step.

Variable Editor

The Variable Editor step allows a user to assign a value to a variableusing expressions that include operators, constants, variables, anddata store values.

Clear Conversations

The Clear Conversations step allows a user to clear conversationsfrom a web controller.

Service Layer

34

3.1.2. Service Steps

Table 7.2. Step Group: Service Steps

Name Description

Send Email

The Send E-mail step allows a user to construct and send HTML-base e-mail using variables created within an Operation orConversation.

Groovy

The Groovy step allows users to enter a script and save it as a partof the step. The script can reference Skyway variables as well asinvoke methods on Skyway or Java components such as projects,operations, and actions that have been discovered.

Invoke Action

The Invoke Action step allows a user to pass execution of thecurrent Action to another Action within the same Operation.

Invoke Operation

The Invoke Operation step invokes an operation from the currentaction. The step is capable of invoking an Skyway operation fromthe same project, another project, and even another container.Depending on the location of the operation, the Invoke OperationStep will automatically determine the most optimal communicationchannel.

Log Message

This step allows a user to add message logging to an Operation orConversation.

3.1.3. Flow Steps

Table 7.3. Step Group: Flow Steps

Name Description

Decision

The Decision step allows a user's Operation or Web Module tofollow a logic path based on a yes or no validation of the specifiedcriteria.

Decision Range

The Decision Range step allows a user's Operation or Web Moduleto follow any one of a number of possible logic paths based uponthe evaluation of the specified criteria.

Iteration Start

The Iterator Start step allows a user to loop through the content of aCollection or Data Store that has been created in Skyway.

Stop

The Stop step is an optional step used to terminate an Action whenthere is no certain endpoint.

Service Layer

35

3.1.4. Exception Steps

Table 7.4. Step Group: Exception Steps

Name Description

Catch Exception

Once an exception type has been configured to catch the type ofexception thrown, the Catch Exception step is invoked when anexception is thrown from any preceding step.

Throw Exception

The Throw Exception step allows users to throw a user-definedexception.

3.1.5. Transaction Management Steps

Table 7.5. Step Group: Transaction Management Steps

Name Description

Transaction

This is step to commit the last transaction and start a newtransaction.

Rollback

This step is to rollback a transaction.

4. Custom Java CodeAugmenting the application development process with modeling-based automation can significantlyimprove development productivity and application quality, however it's important to recognize thatmodeling-based automation is not an all or nothing proposition. Model-based automation must becomplimentary to traditional code-based development. Skyway Builder excels at this by providing aseamless blending of models and code.

Skyway Builder let's you drop code into your projects that can be used along-side the model-basedcomponents. In the event that your functionality cannot be effectively expressed using models (perhapsdue 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 theextra step of adapting (blending) code-based resources to appear as model-based resources in the modelingenvironment. For example, if you define POJO's in your project, they can be used just like POJO's derivedfrom models.

Another capability afforded by the Skyway Builder application generation engine is that the generatedlogic/code can be used directly from the developer's custom code. The code generated by Skyway is conciseand human-readable, and it's organized, packaged and name-spaced according to project hierarchy. Thismakes it very easy for developers to find and use the generated functionality from within their custom code.

Service Layer

36

In addition to supporting the use of custom code, the Groovy step adds dynamic language support toSkyway Builder. If a developer needs to resort to custom code for ant part of their application, the developercan 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 co-exist and interact. Java developers can now implement the data, service, and web layers of their solutionentirely in models or through the blending of models and java code. Custom Java code can be authoredalong side models, and both can be fully leveraged by one another.

4.1. 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 dataof other systems. If the functionality is available as SOAP-based web services, Skyway Builder can invokethose 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 ofa system's web services. Skyway Builder will discover (or learn about the existence of) these servicesby the developer importing the WSDL document. As part of the discovery process, modelling artifactscorresponding to the web services defined in the WSDL will be added to the project. These modellingartifacts 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 needsto leverage the functionality of another system. On the other hand, composite applications integrate withservices from a variety of systems, as is typically the case in SOA environments. The service layer ofa composite application may be entirely implemented by other systems, in which case the compositeapplication 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 WSDLFile wizzard will prompt you for the WSDL. You can either specify a URL or load a WSDL from the filesystem, and then click "Finish". Skyway Builder will parse the WSDL and create model based artifactsfrom the WSDL components.

Service Layer

37

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 representthe imported service.

WSDL Complex Types Data Types Skyway data types will be automatically createdfor any complex types defined in the WSDL thatare needed to interact with the service.

WSDL Operations Skyway Operations A Skyway operation will automatically be createdfor each operation defined in the WSDL. Theseoperations are what a Skyway Builder applicationwill use to invoke the functionality of the service.

5.2. Produce Web Services - Model First DevelopmentIf the functionality of an application produced with Skyway Builder needs to be accessed by anothersystem, 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 Skywayexposes and uses SOAP services for invocation. The decision of exposing application logic as SOAP webservices is left to the developer to decide based on their requirements. In the event that Skyway Servicesare configured to be exposed as web services, Skyway Builder will produce the WSDL document thatother systems can use to discover the available operations, including the contract and location.

5.3. Produce Web Services - Contract First DevelopmentWhen designing a system that consists of multiple applications communicating with each other using webservices, it is common to use contract-first development as way of defining the messages that will behandled between systems. This includes identifying the operations themselves, including the input andoutput 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 predefinedcontract. If Skyway Builder is being used to implement the web services, then Skyway Builder woulddiscover the WSDL for the purposes of implementing the services. This is of course different thandiscovering the web services for the purposed of consuming the services as described in the ConsumeWeb Services section.

38

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 actionsare 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 thesebuilding 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 basicconcepts, it will be easier to understand how the tools provided by Skyway can leveraged effectively forimplementing the web layer.

1. Web ControllersWeb 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: groupingWeb Conversations and mapping urls to Actions. The grouping function is pretty self-explanatory, and aweb controller will typically have at least one Web Conversation.

Figure 8.1. Skyway Web Controller

1.1. URL Action MappingIn addition to serving as the container for Web Conversations, a Web Controller has the very importantfunction of mapping urls to actions and views. Conversations and Actions will be discussed shortly in

Building Web Layer

39

greater detail, but at this point it's important to know that actions defined in a Web Conversation are used todefine 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 inthe Web Controller.

An action mapping is responsible for defining the url(s) that will trigger an action. When the defined URLis requested from a web control, javascript or web client, the action associated with the url will handle therequest. The action mapping will also specify the jsp that will render the response to the request. Everyrequest will have a response, and the action mapping specifies both the action that will handle the requestand 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 canhave more than url mapping to the same url

View The view that should be rendered following the invocation of theAction; the configuration choices are:

• A JSP page

• View alias (defined at project level)

• Project variable

Binding Error View The view that should be renderedif a binding error occurred(OPTIONAL)

There are situations where you may have actions that won't have a defined action mapping. For exampleyou may define an action that can be called from other actions, but not as a web resource. If you don't wantactions 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 havemultiple 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 responsehandled by a different JSP.

By using action mappings, the consumers are bound to a url, and not directly to an action. Action mappingsprovide a form of loose coupling, where the mapped actions can be changed without impacting theconsumers.

The configurations needed to achieve the desired page flow pattern are represented in the followingdiagram:

Building Web Layer

40

Table 8.2. Request Mapping Parameter Examples

URL Action View Binding

/userlist.jsp UserRegistration.initUserList

URL: /userlist.jsp

Summary: Requests to /userlist.jsp will be mapped to the initUserList action. When complete, theuserlist.jsp view will be rendered.

/SaveUser UserRegistration.saveUser

URL: /saveconfirm.jsp

Summary: Requests to "/SaveUser" will be mapped to the UserRegistration.saveUser action. Whencomplete, 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. Whencomplete, the updateconfirm.jsp view will be rendered.

Note: Multiple request URLs can be mapped to the same action (compare to previous example), andthe 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.addTransactionaction. 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.


/confirmation.jsp

Summary: Requests to "/SaveUser" will be mapped to the UserRegistration.saveUser action. Whencomplete, the confirmation.jsp view will be rendered.


/confirmation.jsp

Summary: Requests to "/SaveUser" will be mapped to the UserRegistration.saveUser action. Whencomplete, the confirmation.jsp view will be rendered.

2. Web ConversationsThere are two principal artifacts related to building dynamic web applications. JSP pages implement theuser interfaces, and Web Conversations contain the processing logic for user generated events. The logicis implemented using Actions (which will be described later), and a Web Conversation is the container forthe Actions. A Web Conversation also defines the variables and constants that are available to it's Actions.

Building Web Layer

41

Figure 8.2. Conversation

A web application must have at least one Web Conversation, but it will more than likely have multipleWeb Conversations.

A Web Conversation facilitates the grouping of processing logic around application tasks, which istypically comprised of a series of steps. Therefore each application task is implemented as it's ownconversation, and each conversation contains the variables, constants, and Actions needed to orchestratethe task and support the user events associated with the task. These types of Web Conversations willtypically be session scoped. When the task is done, the conversation state can be discarded using the ClearConversations step.

Building Web Layer

42

Figure 8.3. Conversation Example: Survey Entry

While a web application will typically contain several application tasks, the example demonstrates theimplementation 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 otherActions 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 WebConversation variables too. However an Action can not access variables in other Conversations.

2.2. Constants

A constant is a fixed variable whose value is defined at design-time.

Building Web Layer

43

3. Actions

Figure 8.4. Web Conversation Actions

Actions in the context of a web conversation (as opposed to a service operation) implement the logicfor handling user-generated events. The developer defines the logic to be performed by sequencing stepstogether.

A web conversation must have at least one Action. In order to accomplish more complex tasks theapplication logic may be implemented using several Actions. A user event will be configured to call aspecific Action, however other actions in any other web conversation can be invoked using the InvokeAction step.

By locating an Action under a Conversation, it is implied that an Action can only access variables definedin 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. Inorder for an action to accessible from a JSP page, the Action must be mapped to a URL. This is performedin the URL Action Mapping configuration in the Web Controller. An Action can have multiple mappingsdefined in the Web Controller. If an Action has at least one mapping, the Action is considered public.

3.1. Steps

When implementing actions, there is toolbox (palette) that contains a set of functional steps that areavailable 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 orimplementing 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 redundancyof application development. Rather than continuously having to write the same code over and over withonly minor differences, steps automate the generation of code for the developer. By using steps thereis 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 ensuresthat 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 benefitfrom automation, you can add new custom steps to the toolbox. As a matter of fact, all the steps includedin Skyway Builder were implemented using the plugin architecture.

Building Web Layer

44

Figure 8.5. Skyway Conversation - Action Steps

These steps are identical to the steps used to implement Operation Actions. The steps were described inthe 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.

4.1. JSP Pages

The user interface in Skyway applications is implemented using JSP, which offers a lot of inherentfunctionality to help web developers build web applications. JSP functionality is fully leveragablefor Skyway applications, and Skwyay Builder adds some additional functionality make building userinterfaces even easier.

Building Web Layer

45

4.2. Web Controls

Skyway Builder provides a custom tag library to implement the user interface. The Skyway web controlsare found in the palette of the JSP editor, and the controls can be dragged onto the page. Every Skywayweb control has a properties panel, which makes it easy to bind the controls to Web Conversation variablesand 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 beused to submit the user input on the form. The button label can be configuredwith a static value or a Skyway variable. This control also supports variableassignments and Actions.

Checkbox The Skyway Checkbox web control binds a boolean variable to a checkboxon a web page. A checked Skyway Checkbox means that the booleanvariable is set to "true". An unchecked Skyway Checkbox means that theboolean variable is set to "false".

Conditional Display The Skyway Conditional Display web control allows you to display or notdisplay a section of a web page based on the results of one or many true/falsetest 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 displaysmultiple static or variable (collection) values in listbox or dropdown format.This web control can be configured to give the user the option of selectingone or many of the dropdown values. At runtime, selection(s) are written toeither a variable or a collection of variables.

Form The Skyway Form web control is where controls that accept user inputare 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. Thesecontrols must be placed within the dashed form boundary after adding aSkyway 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 variablesand invoke web events. Additionally, it can be used to move the user to thenext 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 aweb page. This web control can display either a static value or a variable, andif required, the user has the ability to modify the appearance of the image.Additionally, Skyway Image controls can be configured to display basedon the results of one or many true/false test conditions. If the conditionsevaluate to "true", the image is displayed, otherwise the image is omittedfrom the web page.

Input Field The Skyway Input Field web control is a Skyway Form element that bindsa variable to an Input Field on a web page. At runtime, if the Input Fieldvariable has been initialized, the value of the variable is displayed in theInput Field. Additionally, when a form containing an Input Field is submittedat runtime, the user input is stored back to the bound variable.

Building Web Layer

46

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 acollection and repeat the enclosed web controls once for each row in thecollection.

Label The Skyway Label web control allows you to display the contents of avariable on a web page. The variable can be a top-level primitive variable ora field within a complex Data Type.

Layer The Skyway Layer web control is an area of content; at runtime, it emits aDIV or SPAN tag, allowing a user to apply CSS styles to specific regions ofthe page, and/or to use these regions to dynamically change the display of apage. These layers can be loaded or hidden by actions.

Radio Button The Skyway Option web control is a Skyway Form element that displaysmultiple static or variable (collection) values as a set of radio buttons. Theweb control allows a single selection to be made from the set of options, andat runtime, the selection is written to a variable.

Text Area Similar to the Skyway Input Field web control, the Skyway Text Areacontrol is a Skyway Form element that binds a variable to a multi-line InputField on a web page. Unlike the Input Field, the Text Area control includesa scroll bar and is used to display larger sets of data. At runtime, if the textarea variable has been initialized, the value of the variable is displayed in theweb control. Additionally, when a form containing a text area is submitted atruntime, 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 withinselected input fields

4.2.1. Events and Commands

Skyway Web controls can be configured to associate logic with the different events supported by theweb control. When configuring a web control that supports events, you must first select the Event andthen configure the logic to be performed in response the event. The logic is implemented as SkywayCommands, and there are various Skyway Commands available to the web developer.

Building Web Layer

47

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 onthe need to associate behavior and/or logic to the web control using Skyway Commands. An Event willhave at least one Command (otherwise the developer wouldn't have added an Event in the first place), andan 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 ofthe application, the commands will execute in the order that they are defined.

Building Web Layer

48

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 thanone element can be specified by separating them with commas. And morethan one CSS class can be specified by separating them with commas. Thestyles must be defined separately in a style sheet or an inline style block onthe page.

Change Style This reloads the current page. This also supports the auto-scroll feature. Thisaction is useful for refreshing a page when data has changed, etc. If you usethis 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 multipleelements. You can specify more than one layer by separating them withcommas.

Custom Script Raw JavaScript can be typed into this action. Skyway supports round tripHTML with this action. If the user switches to code view in the HTML editorand manually enters JavaScript into an event attribute, this JavaScript willbe parsed and placed into a Custom Script action when the user re-opens thewizard for the control. The user should make sure he puts a semi-colon afterany custom JavaScript entered (this is standard). You can also wrap actionsinside of conditional statements.

Set Variables This allows a user to set the variable assignment. Enter the expressiondirectly into the Set Variables text area containing the variable path and thevalue 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 tutorialon EL Expressions.

Building Web Layer

49

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 theevent. The event can be invoked asynchronously, which means the currentpage will not be reloaded. If the user wishes to reload the current page, theycan select the auto-scroll feature which will automatically scroll the page(after reloading) so that the originating component (the one that fired theevent) is in view. This loads a Skyway component into a target element onthe page. A target element can be any body tag, such as a DIV or SPANregion, or a table cell (TD). NOTE: If you use this command to load acomponent that is going to overwrite the control firing the event, then it mustbe the last command in the sequence. In other words, you can configure abutton or control that will reload itself or overwrite itself. But when you dothis, it must be the last thing you do.

Move Element This moves an element to an x,y coordinate position. There is an option tomove the element to the coordinates of the triggering mouse event, whichis 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. Thisaction is useful for refreshing a page when data has changed, etc. If you usethis action, it should be the last action in your sequence.

Submit Form This action submits the named form. Only one form can be submitted peraction. 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 reallynice feature.

Swap Image This action changes the SRC of one image to another. This action is goodfor rollovers. Typically, the user would drop images onto the page (using theskyway image wizard) and make them invisible. Then, the user can changethe 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 alreadyhas the class, it will be removed. If the element does not have the class, itwill be added. This is a great action to use when you don't want to maintainstyle state. For example, you just want to display a down arrow if an uparrow is displayed or vice versa. You can specify more than one element andmore 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 isnot visible, the display attribute will be removed, causing the element to bedisplayed in its natural state, either inline or blocking. A DIV element isnaturally blocking, for example, and a SPAN element is naturally inline. CSSNote: the display attribute can be set to inline, blocking or none. When set tonone, 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 invisiblebut it will still take up space on the page. Our visibility actions control thedisplay attribute, as this is the desired behavior most of the time. You canspecify 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 gettingbogged down with the details of html or javascript. However it's worthwhile to take a quick peek at how

Building Web Layer

50

events and commands manifest themselves in JSP code. When you first start using Skyway Builder, youare encouraged to implement your web controls using the properties panel. As you become more proficientwith 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. Theimplementation 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 commandconfigurations are wrapped by the web control tag. The events are embedded in the web control usingan event tag ( <skyway:event> ), which wraps all the commands associated with the event. Finally thecommand tags ( <skyway:command> ) define the Commands that should be executed for the event.

4.3. Using CSS

Cascading Style Sheets (CSS) is a language for describing how an application should formatted. Whilethere are a variety of options for formatting web pages, CSS is the pre-dominant choice because it's astandard supported by all modern web browsers, and it facilitates the separation of the structure of thepage and the presentation (or style) of the page.

There isn't really any special considerations regarding using CSS with Skyway applications. CSS can beused 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 orstylesheet)

Most Skyway web controls have style properties panel that can be used to specify a CSS class and/orspecify an inline style. In the case of inline styles, at runtime the visual rendering of the web control willbe 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.

Building Web Layer

51

When defining the inline style, you can specify the style information directly into the Inline Style sectionof the style panel. Alternatively you can click on the Style Editor button to configure the style using aspecialized 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. Thehref attribute specifies the location of the stylesheet. Typically the stylesheet of a web application will belocated in the web application, and in the case of a Skyway project, the stylesheet will be added somewherein the web content folder. The ${webContextRoot} variable is a convenient way to reference at runtimethe root context of the web applicaiton. Since in this example the css file was added to a "css" folder in theweb 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 wouldbe a good reference for best practices in using CSS within a web application.

4.4. Integrating additional web resourcesThe WebContents folder in a Skyway Project gives a web developer a lot of flexibility to organize theweb content in any manner they desire. When creating a new project, Skyway will automatically addsome folders and files to the WebContents folder. When using Skyway Builder Enterprise Edition, someadditional folders and files are added. However a web developer can add whatever files they want to theWebContents folder. The files are usually related to the design of the web pages, and some typical itemsa 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 structureis desire.

• Reference the files within the application by URL.

Next some common examples will be described.

Building Web Layer

52

4.4.1. 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 afolder (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 beloaded 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 specifiedURL. The remainder of the URL is based on the folder (images) and the file name (logo.jpg).

4.4.2. Linking Javascript

Javascript is a very powerful technology for specifying client-side logic that runs in the web browser. Whilea web developer using Skyway may not specify any javascript, applications produced with Skyway Buildermake extensive use of Javascript. Many of Skyway's web controls will automatically emit javascript basedon 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. Thisfolder is used to store the javascript files used by Skyway's web controls. In the folder there are threejavascript files. The prototype.js file is used to support Skyway's AJAX functionality, and the other twolibraries are light-weight javascript libraries from Skyway for bridging the prototype library with Skyway'sweb controls.

If you have some additional 3rd party or custom javascript libraries that you want to include in the webapplication, you can add them to the js folder (or any folder for that matter) and load them from yourweb application.

For example if you add the script.aculo.us javascript library (scriptaculous.js) to the js folder inWebContents, 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

Building Web Layer

53

javascript file. The tag automatically derive the URL from the context root (so there's no need to specifythe ${webContextRoot} variable), and it will automatically look in the js folder.

5. Model-View-ControllerThe most common way of describing design of dynamic web applications is to use the model-view-controller (MVC) architectural pattern. First the MVC layers will be described in the context of Skyway-based development, and then the interactions between the layers will be described.

5.1. Model-View-Controller LayersThe model-view-controller (MVC) architectural pattern prescribes splitting and application into separatelayers: 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 thestructure of an application. While the model can apply to all web technologies, the diagram is intentionallyvoid of technology implementation details.

The following sections show how the MVC is implemented using Skyway Builder.

5.1.1. JSP (View)

Views are implemented as JSP pages, and Skyway provides various web controls for presenting dataand soliciting input from user. The data available to a View is defined in a Web Conversation, which isconfigured with variables and constants that are available to all views in a project.

5.1.2. Web Controller/Conversations (Controller)

If you look at the logic typically found in a web application, the logic is associated with either thebehaviour of the application or business logic. The MVC pattern prescribes that the controller layershould be focussed on implementing the behaviour of the application. While a Web Conversation andassociated Actions can be used to implement the behavior and business logic, the best practice is to excludethe business logic from the controller layer. However sometimes it's more practical (as in the case ofprototyping) 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 businesslogic) in the Web Conversation Actions.

Building Web Layer

54

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 domainlogic 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 businesslogic, and the "Controller" Actions merely orchestrate the calls to the service layer. In this case, the roleof "Controller" actions is limited to defining only the behavior of the application. The core applicationbusiness 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 domainlogic 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.

Building Web Layer

55

5.1.3. Data and Services (Model)

The Model refers to the domain logic and domain model. As decribed in the Actions section, there are twofundamental choices for implementing Models. Actions can partly implement the model by implementingthe domain logic themselves and manipulating the domain model directly. The alternative is to implementthe 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 arelocated 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 InteractionsThis section takes a closer look the interactions that occur between the model-view-controller layers inregards to Skyway Builder.

5.2.1. JSP to Action

To associate JSP and Actions, configure a web control to invoke a URL in response to a user generatedevent. Skyway's web controls support all the relevant standard events (i.e. onClick, onBlur, onFocus), andthe controls can be configured to fire one or more Load URL commands for each event. Furthermoresince a Web Conversation Action is addressable by URL (assuming there is a URL Action Mapping entryin the Web Controller), just about any 3rd-party or custom web control can invoke Actions.

5.2.2. Action to Model

Depending on whether the domain logic is implemented in the Model or Action, an action invokes changeson the model through a service layer or through direct access to the domain model. To wire an Action toa service layer, the Action can use the invoke operation step. To wire an Action to the domain model, theAction can use the data access steps.

5.2.3. Model to Action

In all cases model changes are communicated back to an Action via updated Web Conversation variables.

5.2.4. Action to JSP

When an Action is done responding to the user event, the model updates need to be represented to the userthrough 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 beresponding 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.

Building Web Layer

56

• Multiple Views - In this scenario, the Action can specify one of several possible Views. Under certainconditions the Action may direct a particular View to be rendered. In other conditions, the Action maydirect another View to be rendered.

6. UI Composition PatternsFor implementing user interfaces, Skyway uses Java Server Pages (JSP), a Java-based technology for thedynamic creation of content (i.e. html) to be delivered over HTTP. There are various ways of leveragingJSP to design user interfaces, and this section describes two patterns for composing user interfaces.

6.1. Page Centric Pattern

The page centric pattern is a course-grained technique for utilizing JSP to compose a user interface. Inthis technique a single JSP implements the whole HTML page appearing in a web browser. At any pointin time, the html content being viewed by the end-user of the web application was produced by a singleJSP. As the end-user interacts with the application, they will be taken to different pages, which are eachrendered 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.

6.2. Page Composition Pattern

Another pattern for composing user interfaces using JSP is to decompose the end-user pages into finer-grained units of dynamic content that are implemented individually using JSP. Each fine-grained unit isvisually and functionally distinct, and they are typically a rectangular and easily identifiable element ofa user interface.

Building Web Layer

57

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 becausea UI is decomposed into fine-grained units, doesn't mean that the end-users need to consume them asfine-grained units. So the second part of this pattern is to define a JSP that composes a page from theelementary 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 sectionis on the composition pattern, the implementation techniques will be described later in this guide. It's alsoworth mentioning that this pattern can leverage standard HTML features for structuring the fine-grainedcontent into a full page, including tables, div/span and CSS. At runtime the composite JSP will render thefully 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 duplicatedcontent in multiple views)

• Works well for both traditional and AJAX-based applications

7. Page Flow PatternsThe previous sections describe the patterns for composing the user interface. This section describes thepatterns for implementing page flow.

Building Web Layer

58

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 everyAction 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 determinedby the processing that occurred in the action and optionally the requested URL.

7.1. Page-to-Page PatternIn this pattern, for a given JSP URL there can be an Action invocation (pre-load). When the Action hascompleted, the requested page will be rendered.

7.2. Page-to-Action PatternIn 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 bedynamically determined by the outcome of the Action.

Building Web Layer

59

In many cases an Action will resolve to a single view, however there are also scenarios where an Actionmay resolve one of many views. This is called dynamic view resolution, and it's also supported by thispattern.

7.3. Page Composition PatternThis pattern is just an implementation of the Page-To-Action pattern in the context of the View beingcomposed of multiple other component component Views. When the Action has completed, the View willbe rendered at the server. However in this pattern the view is usually the same view (JSP page) for allactions.

7.4. Page Composition (AJAX) PatternThis pattern is also just an implementation of the Page-To-Action pattern in the context of the View beingcomposed of multiple other component views. When the Action is done, the View will be rendered at theserver. Unlike the Page Composition pattern, in this pattern the View is loaded into to a region of the pageusing browser based technologies (AJAX).

60

Chapter 9. Deploying Applications

This chapter will describe the artifacts and configurations associated with deploying the Skyway Project.

1. Deployment ExplainedTBD

2. Runtime ArchitectureThe Skyway Runtime Architecture is the infrastructure of libraries and super-classes in which the modelsdeployed from Skyway Director can run. At Skyway we are big believers in an open architecture andin Open Source components and the value that it can provide to an enterprise. To that end, the SkywayRuntime architecture makes use of dozens of Open Source libraries and a common skeleton for bringingthose libraries together.

The code generated from Skyway Director is all of the business logic and data defined in the metadatamodel and is represented as clean, commented, human-readable JEE code. This code can be opened withinEclipse or any standard IDE for insight into exactly how clean and concise it is. Every comment enteredin while designing the metadata is embedded directly in the code in the appropriate place. All names arepreserved from the model and into the code.

3. Deployment ModelsWeb-Only

Web/EJB3

4. Community Edition Deployment OptionsTBD

4.1. Option 1TBD

4.2. Option 2TBD

5. Enterprise Edition Deployment OptionsTBD

Deploying Applications

61

5.1. Option 1TBD

5.2. Option 2TBD

6. Changing DatabasesTBD

7. Run ApplicationTBD

62

Chapter 10. SecuritySkyway Builder EE enables developers to easily add security to an application. Security is implementedusing Spring’s powerful security module, appropriately named Spring Security. Skyway security allowsout-of-the-box configuration of the two most common security information providers: database and LDAP.In addition, it lets developers plug other security information providers included in Spring Security, ortheir own custom providers by implementing a single method.

1. Securing Project ResourcesSkyway Builder EE allows the developer to configure the URL patterns, services and data stores that mustbe secured. At runtime, whenever a requested URL matches one of the configured URL patterns, runtimecomponents verify if a user has been authenticated, and if not, forwards the request to a view to collectthe user’s credentials. Once the user has been authenticated, it proceeds to the originally URL. The viewsused for security functions, which are implemented as JSPs, can be customized or replaced altogether. Thesecurity functions for which views can be configured include login, logout, and access denied.

2. Securing ServicesSkyway operations can be invoked externally as Web services or native operations. External invocations onoperations of a secured service are intercepted to ensure that the request contains authenticated credentials.If it does, the request is allowed to reach the operation. The authenticated credentials are propagatedtransparently to external invocations during the operation’s execution chain within the same project. Itis important to note that a service is secured only for external invocation; operation invocations within aproject are not intercepted, since it’s assumed that the developer secured the entry point.

3. AuthorizationSo far we have only discussed authentication, which is the act of establishing that the user is whoever heor she claims to be. Another aspect of security is authorization. Authorization is the process of verifyingthat an authenticated user has the authority to perform certain function. Skyway supports role-basedauthorization -- an authenticated user has a set of roles that define which functions may perform. InSkyway, the application is responsible for authorizing. The alternative would be for the developer todeclaratively designate which roles can invoke certain operation. Letting the application authorize providesthe maximum flexibility, since often times a function may not coincide with an operation. To support thiskind of authorization model, Skyway Builder provides the following functions callable from a Groovy step:

Page Flow Patterns

• currentUser() – returns the name of the user currently authenticated, if any

• isAuthenticated() – returns whether a user is currently authenticated

• isInRole -- returns whether the user currently authenticated, if any, has the given role

skyway builder developer's guide · 2011-11-08 · java_persistence_api] 2.2.2. spring...

Documents