skyway builder user guide (beta 1) · 2011. 11. 8. · • web-only (servlet container) deployments...

Skyway Builder User Guide (BETA 1)

March 26, 2008

Skyway Software

Skyway Builder User Guide (BETA 1): March 26, 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 data persistence. This user guide is intended to introduce users to theSkyway 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. Skyway Director ..................................................................................................... 1

2. Architecture Overview ..................................................................................................... 21. Design-time Architecture .......................................................................................... 2

1.1. Key Technologies Used ................................................................................. 22. Execution-time Architecture ...................................................................................... 3

2.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 ............................................................................................. 93.2. Skyway Toolbars and Menus ........................................................................ 103.3. Editors ...................................................................................................... 10

4. Application Development ............................................................................................... 111. Skyway Development Artifacts ................................................................................ 112. Project Meta-data Model ........................................................................................ 113. Application Layering ............................................................................................. 12

3.1. Web Layer ................................................................................................ 133.2. Service Layer ............................................................................................. 133.3. Data Layer ................................................................................................ 13

4. Development Process ............................................................................................. 144.1. Development Steps ..................................................................................... 14

5. Create Project ............................................................................................................... 151. Projects ............................................................................................................... 152. Project Configurations ............................................................................................ 15

2.1. General Info .............................................................................................. 152.2. Project Variables ........................................................................................ 162.3. Project Constants ........................................................................................ 162.4. View Mappings .......................................................................................... 16

6. Data Layer ................................................................................................................... 171. Domain Model ...................................................................................................... 17

1.1. Implementing the Domain Model ................................................................... 172. Basic Data Types .................................................................................................. 183. Data Types .......................................................................................................... 18

3.1. Defining Fields ........................................................................................... 193.2. Defining Relationships ................................................................................. 193.3. Mapping to Database ................................................................................... 20

4. Data Stores .......................................................................................................... 204.1. Data Operations .......................................................................................... 214.2. Named Queries ........................................................................................... 21

5. Leveraging Existing Databases ................................................................................ 225.1. Importing Types ......................................................................................... 23

6. Using Data Types from Other Sources ...................................................................... 236.1. Java Beans ................................................................................................ 236.2. XML Schemas ........................................................................................... 236.3. Web Services ............................................................................................. 24

7. Service Layer ............................................................................................................... 251. Skyway Service .................................................................................................... 25

Skyway Builder User Guide (BETA 1)

v

1.1. Customizing Operation Attributes .................................................................. 262. Operations ........................................................................................................... 26

2.1. Operation Interface ..................................................................................... 262.2. Operation Resources .................................................................................... 272.3. Transaction Management .............................................................................. 282.4. Asynchronous Invocation ............................................................................. 282.5. Recursion .................................................................................................. 28

3. Actions ................................................................................................................ 283.1. Steps ........................................................................................................ 29

4. Custom Java Code ................................................................................................. 315. Web Services ....................................................................................................... 31

5.1. Creating Web Services ................................................................................. 315.2. Consuming Web Services ............................................................................. 315.3. Contract First Development .......................................................................... 32

8. Building Web Layer ...................................................................................................... 331. Model-View-Controller .......................................................................................... 33

1.1. Model-View-Controller Layers ...................................................................... 331.2. Model-View-Controller Interactions ............................................................... 35

2. UI Composition Patterns ......................................................................................... 362.1. Page Centric Pattern .................................................................................... 362.2. Page Composition Pattern ............................................................................ 36

3. Page Flow Patterns ................................................................................................ 373.1. Page-to-Page Pattern ................................................................................... 383.2. Page-to-Action Pattern ................................................................................. 383.3. Page Composition Pattern ............................................................................ 393.4. Page Composition (AJAX) Pattern ................................................................. 39

4. Web Controllers .................................................................................................... 394.1. URL Action Mapping .................................................................................. 404.2. Other ........................................................................................................ 41

5. Web Conversations ................................................................................................ 435.1. Variables ................................................................................................... 445.2. Constants .................................................................................................. 44

6. Actions ................................................................................................................ 456.1. Steps ........................................................................................................ 45

7. Building Views ..................................................................................................... 467.1. JSP Pages .................................................................................................. 467.2. Web Controls ............................................................................................. 467.3. Page Flow ................................................................................................. 467.4. Validation .................................................................................................. 467.5. Using CSS ................................................................................................. 467.6. Integrating additional web resources ............................................................... 47

9. Deploying Applications .................................................................................................. 481. Deployment Explained ........................................................................................... 482. Runtime Architecture ............................................................................................. 483. Deployment Models ............................................................................................... 484. Community Edition Deployment Options ................................................................... 49

4.1. Option 1 ................................................................................................... 494.2. Option 2 ................................................................................................... 49

5. Enterprise Edition Deployment Options ..................................................................... 495.1. Option 1 ................................................................................................... 495.2. Option 2 ................................................................................................... 49

6. Changing Databases ............................................................................................... 507. Run Application .................................................................................................... 50

10. Security ..................................................................................................................... 51

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 ............................................................................................. 124.2. Application Layers - High-Level ................................................................................... 134.3. Development Steps Overview ....................................................................................... 146.1. Domain Model (Banking Example) ................................................................................ 176.2. Data Types (Banking Example) ..................................................................................... 196.3. Data Stores (Banking Example) ..................................................................................... 217.1. Skyway Service .......................................................................................................... 257.2. Operations ................................................................................................................. 267.3. Operation Actions ....................................................................................................... 297.4. Skyway Builder CE - Action Steps ................................................................................ 298.1. Page Centric Pattern .................................................................................................... 368.2. Page Composition Pattern ............................................................................................ 378.3. Page Flow Patterns ..................................................................................................... 388.4. Skyway Web Controller ............................................................................................... 398.5. Conversation .............................................................................................................. 438.6. Conversation Example: Survey Entry ............................................................................. 448.7. Web Conversation Actions ........................................................................................... 458.8. Skyway Conversation - Action Steps .............................................................................. 458.9. Skyway Site ............................................................................................................... 46

vii

List of Tables3.1. Skyway Builder Editions ............................................................................................... 93.2. Skyway Builder Distribution/Download Methods ............................................................... 96.1. Skyway Basic Data Types ............................................................................................ 186.2. Relationship Types ...................................................................................................... 206.3. Comparison of Native and External Data Models .............................................................. 226.4. Scenarios for using external data models ......................................................................... 237.1. Step Group: Data Manipulation Steps ............................................................................. 307.2. Step Group: Service Steps ............................................................................................ 307.3. Step Group: Flow Steps ............................................................................................... 317.4. Step Group: Exception Steps ........................................................................................ 318.1. Request Mapping Parameters ........................................................................................ 408.2. Request Mapping Parameter Examples ........................................................................... 41

viii

List of Examples8.1. Syntax for Accesing Conversation Variable ..................................................................... 418.2. Syntax for Accesing Project Variable ............................................................................. 428.3. Syntax for Accesing Project Variable ............................................................................. 429.1. This is a title ............................................................................................................. 48

1

Chapter 1. Skyway Visual PerspectivesSkyway Visual Perspectives is a set of Eclipse Plug-ins, and it aims to deliver an easy-to-use environmentwhere developers from any background can build rich user interfaces, applications, and services thatleverage existing assets and are designed from the ground up for an Service Oriented Archtiecture (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. Skyway DirectorSkyway Director is a distributed deployment solution for application release engineers. Skyway Directorprovides the release team with a graphical solution for easily deploying SOA-based applications enterprise-wide. Its easy-to-use interface simplifies the provisioning of even the most complex networks containingservers within specified domains of use and across world-wide networks.

2

Chapter 2. Architecture Overview1. Design-time Architecture

Skyway Visual Workspace is a set of Eclipse plugins, and it builds on top of various other Eclipse projectssuch as the Eclipse Modeling Project, the Web Tools Project, and the Data Tools Project.

Figure 2.1. Design-time Architecture

Eclipse is a generic framework for integrating tools using a plug-in architecture as described vy Wikipedia:

Eclipse is an open-source software framework written primarily in Java. In its defaultform it is an Integrated Development Environment (IDE) for Java developers, consistingof the Java Development Tools (JDT) and the Eclipse Compiler for Java (ECJ). Users canextend its capabilities by installing plug-ins written for the Eclipse software framework,such as development toolkits for other programming languages, and can write andcontribute their own plug-in modules.

—Wikipedia - Eclipse (Software)

1.1. Key Technologies UsedThis is a listing and brief description of the key design time technologies used by Skyway Builder.

1.1.1. 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 editors

Architecture Overview

3

for a variety of languages, wizards and built-in applications to simplify development,and tools and APIs to support deploying, running, and testing apps.

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

1.1.2. Eclipse Java EE Tools Project

The Java EE Tools Project provides frameworks and tools focused on the developmentof J2EE artifacts. Currently, the project supports (J2EE) 1.2, 1.3, 1.4 and Java EE 5.

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

1.1.3. 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:

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]

1.1.4. Eclipse Modeling Framework (EMF) Project

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/]

2. Execution-time ArchitectureTODO

Highlights of Execution Architecture:

• web-only (servlet container) deployments and full JEE (EJB3) deployments

• generated spring 2.5 applications

• using annotations (using standard Spring and JEE annotations) and autowiring

• pitchfork for processing JEE annotations in web

• generated spring 2.5 applications

TODO: Should probably include the meta-data transformation table here

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

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

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

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

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



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

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


4

Figure 2.2. Execution-time Architecture

Need to provide some description of the above diagram

2.1. Deployment

TBD


5

2.1.1. Web Only Deployment (WAR)

Figure 2.3. Web Only Deployment (WAR)

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

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

2.2. Key Technologies Used

Here is a listing and brief description of the key runtime technologies used.

2.2.1. Spring Framework

Spring is a Java/J2EE application framework.


6

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.

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.2. Hibernate

Spring uses Hibernate for persistence framework.

http://www.springframework.org/about

http://www.springframework.org/about


7

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/]

2.2.3. EJB3

TODO: Description needed.

2.2.4. Java 5


2.2.5. Prototype Javascript Library


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 particular plug-in or set of plugins. Projects are associated with one and only on workspace, and thetype 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

• core development functionality

• open source database deployment support

• web-only deployment (servlet/jsp container)

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

• web services

• transaction management

• web/ejb3 deployment

Table 3.2. Skyway Builder Distribution/Download Methods

Distribution Description

Skyway Builder Rich Client Platform (RCP) stand-alone

Skyway Builder Eclipse Plugin for adding Skyway plugins and perspective toexisting version 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.

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 a setof 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.

TODO: AS SOON AS THERE'S A PROJECT, INCLUDE IMAGE HERE

www.skywayperspectives.org

www.skywayperspectives.org

Environment Overview

10

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.

TODO: Update image.

Figure 3.1. Skyway Toolbar

3.2.2. Skyway Menus

Descriptions

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

11

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

12

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.

TODO: ADD EXAMPLES - SCREENSHOTS

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.


13

Figure 4.2. 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 handling user interactions/events. While the web layer can also contain logic, coreapplication 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.


14

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

15

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

16

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

17

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

18

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

19

Figure 6.2. Data Types (Banking Example)

TODO: Describe previous diagram a bit

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. When defining a relation for a data type, you must specify therelated data type, the relationship type, and the relationship names.

Note:

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

Data Layer

20

3.2.1. Relationship Type

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

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. Bi-directional Relationships

When a relationship is added to another data type, an opposite relationship is implied; hence the termbi-directional relationship. When defining relationship between data types, the reverse relationship isoptional. If you decide to define the reverse relationship, the cardinality and relationship names need tomatch.

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. Mapping to Database

The Database Mapping panel will let you override the default table name and field names.

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

21

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 Operations

For every data type added to a Data Store, the developer can perform basic persistence functions using theModify Data Store and Search Data Store steps.

4.2. Named Queries

A Named Query is a mechanism for predefining queries for the data types associated with a Data Store.When you add a data type to a data store, some basic queries (insert, delete, search) are automaticallycreated for you that are tied to the basic persistence functionality of the Modify Data Store andSearch Data Store steps. Named queries are defined using either SQL or JPQL (Java Persistence QueryLanguage). JPQL is the query lanaguage of JPA, that resembles SQL queries.

Data Layer

22

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.

4.2.2. Query Text

This defines the query in either SQL or JPQL.

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

Table 6.3. 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.

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 itoriginated from

Recreating project is simply a matter of copyingproject folder

Recreating project requires copying the projectfolder and providing the ddl for the database

While native data models offer maximum flexibility, there are occasions where external data models arethe only option. Here are some comman scenarios where you would use external data models:

Data Layer

23

Table 6.4. 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 TypesThe first step for utilizing tables created outside of Skyway Builder is to create a Data Store that isconfigured with a database connection to the external tables. The Import Types function in the Data Storeeditor is used for importing data types from the database. Once the data types are discovered, they can beused just like data types created in Skyway.

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.

6.2. XML SchemasTBD

Data Layer

24

6.3. Web ServicesTBD

25

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

Service Layer

26

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

1.1. Customizing Operation Attributes

In addition to grouping operations, some operation attributes are defined at the Service level. Using theSkyway Service editor you can specify the following configurations individually for each operation.

Operation Configurations

• Authentication

• Scope

• Protocol

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 Actions (which will be discussedin a later section).

Figure 7.2. Operations

2.1. Operation Interface

The 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

Service Layer

27

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.

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:

Service Layer

28

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

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 can consist of oneor more Actions, and the operation must be configured with the Action that should be called first uponinvocation of the operation.

2.3. Transaction ManagementTBD

2.4. Asynchronous InvocationIn some applications you may have the need to initiate an operation, but you don’t want to wait for theuser to wait for the operation to complete before getting a respone. In these cases an operation may beinvoked asynchronously. Once an Invoke Operation has been invoked asynchronously the calling Actioncontinues to execute the remaining steps without waiting for the asynchronous operation to finish.

To invoke an operation asynchronously, check the asynchronous check box in the Invoke Operation step

2.5. 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 using Actions. The developer defines the logic to be performed by sequencingsteps together.

Service Layer

29

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

Description goes here

Figure 7.4. Skyway Builder CE - Action Steps

Service Layer

30

Table 7.1. Step Group: Data Manipulation Steps

Name Description

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

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.

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 initiates another operation, web serviceoperation, or java service operation from the current operation.

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

Service Layer

31

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.

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.

4. Custom Java CodeIf a user has existing logic that is exposed as EJBs, a user can leverage them from Skyway by usingSkyway's ability to "discover and use" java code. The feature is frequently called Java Services. The basicidea is that a user can package up any java code into a java archive and discover the archive for use withinthe Skyway models.

For example a user could write a java method (client) called "validateOrder" which handles the call to anEJB "validateOrder" function. Then package up the java method (and any associated java beans) into ajava archiver (jar). From Skyway a user discover the java archive and select the methods a user want to bemade available to invoke from the models. In a userr models a user add a java service step, and configureit to invoke a userr discovered java method. Any beans a user may have used as inputs/outputs will berepresented in the modelling environment as data objects. a user will create Skyway variables using thesedata objects, just as if a user had created the data objects from scratch in Skyway.

5. Web Services

5.1. Creating Web ServicesWeb Service Enabled Skyway Operations are published together in the same WSDL

5.2. Consuming Web ServicesTBD

Service Layer

32

5.3. Contract First DevelopmentTBD

33

Chapter 8. Building Web Layer

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

In Skyway Builder the principle tools for building web applications are Web Conversations, Actions, andViews. Views render the user interface. Actions process and respond to user events. Related actions aregrouped together in a Web Conversation, which provide shared variables.

Before describing the tools in more detail, it's helpful to describe the overall web application architecture.As with any development tool, there are a variety of choices and types of applications that can be built.After describing the basic concepts, it will be easier to understand how the tools provided by Skyway canleveraged effectively for implementing the web layer.

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

1.1. Model-View-Controller LayersThe model-view-controller (MVC) architectural pattern prescribes splitting and application into separatelayers: domain logic/model (model), presentation (view), and user interaction (controller).

The following sections show how the MVC layers adapted for web applications are implemented usingSkyway Builder.

1.1.1. Views

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.

Building Web Layer

34

1.1.2. Actions

In the context of a Web Conversation, the Actions are processing and responding to user events. As in allMVC frameworks, a user have choices in Skyway regarding the implementation of Actions.

The first option is to put all the processing logic in the Actions. a user have the full compliment of steptypes available to a user to implement a userr processing logic. In this scenario the Action defines boththe behavior and the functionality of the application.

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 an application. The service layer contains all the processinglogic, and the "Controller" Actions merely orchestrate the calls to the service layer. In this case, the roleof Action action is limited to defining only the behavior of the application. The functionality is definedin the Service layer.

Building Web Layer

35

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.

1.1.3. 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 implemented using Skyway Services that arelocated in the Skyway Project. The Service Layer can also be implemented in a variety of other manners.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

1.2. Model-View-Controller InteractionsThis section describes the interactions that occur between the model-view-controller layers in regards toSkyway.

1.2.1. View to Action

To associate Views and Actions, configure a web control to invoke Actions 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 Actions for each event. Furthermore since an Action isaddressable by URL, just about any 3rd-party or custom web control can invoke Actions.

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

1.2.3. Model to Action

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

1.2.4. Action to View

When an Action is done responding to the user event, the model updates need to be represented to the userthrough a View. The Action is responsible for determining the view, and there are several scenarios:

Building Web Layer

36

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

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

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

2.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.1. Page Centric Pattern

In this pattern, every page in a userr web application is implemented using a single JSP.

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

37

Figure 8.2. 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

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

Building Web Layer

38

Figure 8.3. 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.

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

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

39

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.

3.3. Page Composition Pattern

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

3.4. Page Composition (AJAX) Pattern

This 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).

4. Web ControllersAs described earlier Web Controllers are used along with the JSP pages (located in the WebContent)to implement the Web layer of an application. The JSP pages represent the View in MVC, and WebControllers represent the Controller in MVC. Per the project meta-data model, a Web Controller can haveone or more Web Conversations, which will be described in more detail in a later section.

Figure 8.4. Skyway Web Controller

In addition to serving as the container for Web Conversations, a Web Controller has the very importantfunction of binding the views (JSP pages) to Web Conversations and their respective Actions. Theconfiguration information specified in a web controllers is largely responsible for the implementation ofthe page flow patterns.

Building Web Layer

40

4.1. URL Action Mapping

The Web Controller is responsible for mapping URL requests to specific Actions. Request mapping isthe configuration of URI and Action associateions. As noted earlier, there are various page flow patterns,and the configuration of the request mapping essentially implements the page flow pattern.

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)

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

Building Web Layer

41

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.

4.2. Other

So JSP pages have read-access to ALL variables in ALL Conversations. To access a Conversation variable,the syntax will be something like (the exact syntax is TBD)

Example 8.1. Syntax for Accesing Conversation Variable

${MyController.MyConversation.someVariable.someField}

Building Web Layer

42

Example 8.2. Syntax for Accesing Project Variable

${MyProject.someVariable.someField}

But the general idea is that a user must fully qualify a userr variables since a user are not limited to anyone Controller or Conversation in a userr views (JSP pages).

A Controller has a default Conversation. Where is this configured?

a Project has a default Controller

REASONABLE DEFAULT - In these cases, we could omit the URL segments for those default objects.For example, if Conversation1 were the default Conversation in the above example, the Action1 URLcould be:

Example 8.3. Syntax for Accesing Project Variable

http://hostname:port/contextRoot/Controller1/Action1

We could also use this rule in our variable references (TBD)

A Skyway Web Model is a composite design construct which implements a project’s web layer. TheWeb Model contains variables, components, server actions and is consumed by humans via graphical userinterfaces (GUI). Alternatively, a Web Model may be published as a WSRP-compliant portlet.

The Web Model Info tab contains the following configurations:

Name and Description – used in the generate documentation feature.

Web Access – defines how the web model is accessed at runtime

Communications Protocol – enables secure HTTP connections

Transaction Control – enables commit and rollback steps.

4.2.1. Blah

add an editor for our Controller that lets a user add request mappings that take the form:

When URL_PATTERN is referenced, execute RESOURCE_URL.

URL_PATTERN could be a generic URL pattern like /admin/* or a specific View like /someFolder/somePage.jsp or a specific Action like /MyController/MyConversation/MyAction.

RESOURCE_URL could be a specific View or a specific Action.

This lets a user define rules like:

For /* invoke GenericStuff. This causes the GenericStuff Action to be invoked on every request to anypage in the site.

Building Web Layer

43

For /index.jsp invoke Init. This causes the Init Action to be invoked anytime a user go to /index.jsp.

For /admin/* invoke CheckAdmin. This causes the CheckAdmin Action to be invoked for any page under /admin/.

For /MyController/MyConversation/MyAction, return /someFolder/somePage.jsp. This causessomePage.jsp to be returned whenever MyAction is directly invoked.

The picker for URL_PATTERN and RESOURCE_URL would allow selection of known pages andActions, as well as allowing the user to free form type (for patterns and views that we don't know about).

Of course, the nice thing about Skyway is that the user would NOT HAVE to define any mappings at all.This is a completely optional feature that could be used heavily or sparingly.

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

Figure 8.5. 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

44

Figure 8.6. 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

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

5.2. Constants

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

Building Web Layer

45

6. Actions

Figure 8.7. 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).

By default Actions are private and not accessible to JSP pages. In order for an action to accessible froma JSP page, the Action must be configured with a URL. This is performed in the request mappingconfiguration in the Web Controller. An Action can have multiple mappings defined in the Web Controller.If an Action has at least one mapping, the Action is considered public.

6.1. Steps

Description needed here

Figure 8.8. 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.

Building Web Layer

46

7. Building ViewsFigure 8.9. 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.

7.1. JSP PagesA JSP Page can reference any variable from any Web Conversation.

In addition to the standard available html capabilities, Skyway provides various web controls for buildinguser interfaces. Skyway's web controls are JSP tags with special functionality for binding to Webconversation and Project variables.

By using stanard JSP, Skyway developers can leverage the full power of java from the JSP pages ifnecessary

7.2. Web Controls

7.3. Page FlowTBD

7.4. ValidationTBD

7.5. Using CSSWhile there are a variety of options for decorating web pages, Cascading Style Sheets (CSS) is the pre-dominant choice for influencing the presentation of web pages. With CSS, designers can create stylesheets that define how the different elements of a web page appear. They facilitates the separation ofthe structure of the page and the presentation (or style) of the page. The style definitions can be definedin a single location and re-used across many pages, and any changes to the definition are automaticallyreflected on all the pages.

Building Web Layer

47

There are a two aspects to using CSS within Skyway Web Conversations. First there is the general pagedecoration using CSS, and then there is the specific use of CSS with Skyway web controls.

The Skyway HTML Editor provides some basic CSS support in regards to general page design. Anythingthat can't be accomplished using editor's menu bar or toolbar can be configured manually using the editor'scode view.

Most Skyway web controls have advanced properties that can be configured with inline styles or classattributes. In the case of inline styles, at runtime the visual rendering of the web control will be influencedby the embedded style. In the case of class attributes, the visual rendering of the web control (once againat runtime) will be influenced by a class definition.

Skyway supports Cascading Style Sheets (CSS) for decorating UI services. The support for CSS includes:

• HTML Editor provides CSS support in menu, toolbar, and code view.

• Most Skyway web controls can be configured with inline styles or class attributes (Advanced pane)

• CSS stylesheets can be included as:

• Separate stylesheet files (.css) included in the extensions folder

• As a separate component in a common web model

7.6. Integrating additional web resourcesTBD

7.6.1. Images

TBD

7.6.2. CSS

TBD

7.6.3. Javascript

TBD

48

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.

Example 9.1. This is a title

Prompt 1 User Input 1 Output 1 Prompt 2 User Input 2 Output 2

This is callout 1This is callout 2

3. Deployment ModelsWeb-Only

Web/EJB3

Deploying Applications

49

4. Community Edition Deployment OptionsNulla facilisi. Cras sit amet ipsum. Curabitur venenatis. Cras in diam eget diam adipiscing dignissim. Namnisi. Vivamus ligula magna, volutpat eu, ultricies ac, lobortis adipiscing, arcu. Sed rhoncus enim et nibh.Nam semper. Donec dui mi, hendrerit at, tristique ac, elementum sed, elit. Morbi ut eros. Curabitur elitquam, tempor nec, sollicitudin eu, pulvinar in, dui. Aliquam vitae dui non neque eleifend ultricies. Maurisullamcorper libero sed felis. Donec egestas, lectus a placerat pellentesque, nibh magna ornare metus, necfacilisis pede ante eget elit. Sed nec neque. Donec lorem.

4.1. Option 1Nulla facilisi. Cras sit amet ipsum. Curabitur venenatis. Cras in diam eget diam adipiscing dignissim. Namnisi. Vivamus ligula magna, volutpat eu, ultricies ac, lobortis adipiscing, arcu. Sed rhoncus enim et nibh.Nam semper. Donec dui mi, hendrerit at, tristique ac, elementum sed, elit. Morbi ut eros. Curabitur elitquam, tempor nec, sollicitudin eu, pulvinar in, dui. Aliquam vitae dui non neque eleifend ultricies. Maurisullamcorper libero sed felis. Donec egestas, lectus a placerat pellentesque, nibh magna ornare metus, necfacilisis pede ante eget elit. Sed nec neque. Donec lorem.


5. Enterprise Edition Deployment OptionsNulla facilisi. Cras sit amet ipsum. Curabitur venenatis. Cras in diam eget diam adipiscing dignissim. Namnisi. Vivamus ligula magna, volutpat eu, ultricies ac, lobortis adipiscing, arcu. Sed rhoncus enim et nibh.Nam semper. Donec dui mi, hendrerit at, tristique ac, elementum sed, elit. Morbi ut eros. Curabitur elitquam, tempor nec, sollicitudin eu, pulvinar in, dui. Aliquam vitae dui non neque eleifend ultricies. Maurisullamcorper libero sed felis. Donec egestas, lectus a placerat pellentesque, nibh magna ornare metus, necfacilisis pede ante eget elit. Sed nec neque. Donec lorem.


5.2. Option 2Nulla facilisi. Cras sit amet ipsum. Curabitur venenatis. Cras in diam eget diam adipiscing dignissim. Namnisi. Vivamus ligula magna, volutpat eu, ultricies ac, lobortis adipiscing, arcu. Sed rhoncus enim et nibh.Nam semper. Donec dui mi, hendrerit at, tristique ac, elementum sed, elit. Morbi ut eros. Curabitur elitquam, tempor nec, sollicitudin eu, pulvinar in, dui. Aliquam vitae dui non neque eleifend ultricies. Mauris

Deploying Applications

50

ullamcorper libero sed felis. Donec egestas, lectus a placerat pellentesque, nibh magna ornare metus, necfacilisis pede ante eget elit. Sed nec neque. Donec lorem.

6. Changing DatabasesNulla facilisi. Cras sit amet ipsum. Curabitur venenatis. Cras in diam eget diam adipiscing dignissim. Namnisi. Vivamus ligula magna, volutpat eu, ultricies ac, lobortis adipiscing, arcu. Sed rhoncus enim et nibh.Nam semper. Donec dui mi, hendrerit at, tristique ac, elementum sed, elit. Morbi ut eros. Curabitur elitquam, tempor nec, sollicitudin eu, pulvinar in, dui. Aliquam vitae dui non neque eleifend ultricies. Maurisullamcorper libero sed felis. Donec egestas, lectus a placerat pellentesque, nibh magna ornare metus, necfacilisis pede ante eget elit. Sed nec neque. Donec lorem.

7. Run ApplicationNulla facilisi. Cras sit amet ipsum. Curabitur venenatis. Cras in diam eget diam adipiscing dignissim. Namnisi. Vivamus ligula magna, volutpat eu, ultricies ac, lobortis adipiscing, arcu. Sed rhoncus enim et nibh.Nam semper. Donec dui mi, hendrerit at, tristique ac, elementum sed, elit. Morbi ut eros. Curabitur elitquam, tempor nec, sollicitudin eu, pulvinar in, dui. Aliquam vitae dui non neque eleifend ultricies. Maurisullamcorper libero sed felis. Donec egestas, lectus a placerat pellentesque, nibh magna ornare metus, necfacilisis pede ante eget elit. Sed nec neque. Donec lorem.

51

Chapter 10. SecurityIn Progress

skyway builder user guide (beta 1) · 2011. 11. 8. · • web-only (servlet container) deployments...

Documents