Structs And Nodes Development (SAND) is a form of message-oriented modeling and development that declares application data (structs) and application processing components (nodes) as java classes supplemented with custom javadoc tags. Runtime processing centers around synchronous and asynchronous messages (generated from the struct definitions) which are sent between executing application components (generated from the node definitions). The majority of the application code is generated automatically.

SAND explicitely addresses the following application design concerns:

1. Data structures: easy definition and consistent implementation of instance and collection displays, editing forms, database storage, messaging transport serialization, documentation and other representations.
2. Authorization: Appropriate UI display coupled with back-end enforcement of access control at the level of actions, data types, data instances, fields, and field values.
3. Bootstrap data: Clear definition and enforcement of data that must be available at application startup.
4. UI definition: Easy management of screens, content and navigation.
5. Presentation: Layout, fonts, colors, formatting, graphics
6. Application components: The processing components that make up the system functionality.
7. Configuration: The application settings and what components are running on which servers.
8. Communication: Data flow between application modules/servers. API for access via web services and other protocols.

Links to additional information:

Sandev is a complete Structs And Nodes Development (SAND) framework generator implemented using Ant, and targeting an Apache/Tomcat deployment environment. Sandev grew out of the sandboss project, which was substantially similar but targeted the JBoss™ application server. The sandev project serves as a reference framework generator implementation.

A framework generator is a build tool that reads declarative application definitions and produces a complete framework of supporting technology interfaces through code generators.

A SAND framework generator (like sandev) reads source code written in accordance with Structs And Nodes Development declarations, and writes the code needed to support persistence, ad-hoc queries, object serialization, request marshalling, asynchronous notification, UI form rendering, UI form processing, error handling, logging, runtime instrumentation/control, deployment configuration, build coordination and other utilities.

Unlike traditional approaches, which consist of layers of abstraction that never completely map to your application definition, a framework generator works from your application definition to build the code that calls supporting technology APIs.

1. It gives flexibility. You can react faster to changes in supporting technology, and take advantage of new technology with minimal impact.
2. It speeds development. The build environment is already set up and generators create the framework for your application.
3. It adds formal definition beyond what's in code. System evolution is controlled, and you have unified documentation that isn't out-of-date.
4. It declares the business processing in terms of business data communications.
5. It guarantees consistent implementation. Cross-cutting system concerns can be addressed with confidence.
6. Open methodology, open source tools. No lock-in. No licensing fees.

1. UI, messaging, and persistency being treated as separate data models to be integrated, without any coordinated approach.
2. Development, deployment, and runtime management not being coordinated in terms of managing business processes.
3. Lack of clear definition as to which business processes rely on what business data.
4. Applications defined only by implementation code. Lack of accurate up-to-date documentation.
5. System inflexibility.

Feature	Benefit
Message oriented architecture	Directly models business dataflow Fine grained authorization, support for cascading firewalls Time tested, flexible approach
Data structures and processing modules defined in standard java (j2sdk1.4+)	Reduced complexity without proprietary tools Unified data and processing model embedded in source code Application data and logic not bound to support technology Single source for data and processing module definitions
Code generation framework	Supporting technology interface generators (persistency, messaging, format conversion etc) can be re-used across applications Cross-cutting system concerns (security, auditing, documentation etc) leverage consistent data and processing declarations Huge effort savings leveraging existing generators
Modular project structure	Projects can require other projects to re-use existing functionality and/or common definitions Multiple deployments of a single application Multiple applications in a single deployment
Openly published methodology, open source tools	Portable methodology with no lock-in or licensing fees Can be extended to work with other models, technologies, software and tools.

Feature	Benefit
All open source with minimal prerequisite software.	Default implementations can be used over a wide range of technologies (within or outside of J2EE™). Minimal setup and system requirements. Full access to development source code and mailing lists. Zero cost
Comprehensive Ant build with generator infrastructure and dependency checking across required projects.	Supports large scale dependency-checked code generation. Code generation integrated into fast incremental build. Simple initial setup and low maintenance. Modular application component structure with consistent physical source layout. Fully navigable documentation web spanning entire project dependency graph. Easily extensible.
Common basics project defines Message type hierarchy and messaging technology interfaces Authorization and security infrastructure Persistence management and caching Test script messages and driver infrastruture Utilities for reference resolution, UI form processing, matching, logging, serialization, conversions and more	Most of the core framework your application requires is already written and tested
Deployment ConfigurationStruct included in basics project. Integrated deployment configuration editor.	Defines which nodes are running on which servers with what initial parameter values. Defines application-wide communications in terms of custom application data and custom application business logic modules. Defines initial data that must be present at system startup. Separate deployment configuration editing tools not required. XHTML persistence format supports version control and other editors.
SandUIStruct included in ui project. Integrated SandUI editor.	Standard MVC architecture is easily understood and extended. Form support for each struct definition provides ad-hoc queries, multi-instance listing display, add, modify, delete, navigation across references, subclass resolution, custom report displays, custom action buttons, context sensitive help. Authorization processing uses same action, instance, field and field value as internode communications, ensuring a smooth user experience within a muli-level security model. Default webapp support based on standard XHTML/XSLT ensures simple customization of look-and-feel. Technology independent, declarative UI definition can be adapted to multiple display technologies. XHTML persistence format supports version control and other editors. Easily extensible/replaceable.
Integrated control infrastructure.	Standard and dynamic JMX MBean wrappers generated for each node declaration. Generated control panel provides click-through access to each node's native control panel interface. Control framework supports multiple simultaneous control interfaces. Easily extensible.
Integrated optimized messaging.	Supports integrated synchronous (invocation model) and asynchronous (pub/sub model) communications. Messaging uses direct method invocation for nodes running in the same VM. Fully integrated authorization model supports filtering, secure communications, auditing and other communication hooks. Full trace capability and remote/local exception handling. Includes optimized XML serialization/reconstruction. Support for application-defined transactional boundaries. Protocol-agnostic generator framework can support custom: messaging protocols (either standard or vendor proprietary) encryption protocols auditing requirements serialization/reconstruction standards
Integrated persistence support. Default implementation using standard JDBC.	Automatic support for transaction-safe, version-tracked, field-validated persistence. Automatic support for ad hoc queries. Automatic verification of data structures (schema creation and maintenance, initial data verification and maintenance) Supports struct inheritence (data definitions extended from a common base). Automatic pluggable primary key management with support for alternate keys. Pluggable class/field mappings and value conversion. Minimal overhead and complexity. Easily extensible/replaceable.
Sample TaskHeap application and TaskHeapDemo deployment	Provides a working example application for development reference Can be used for development task tracking and planning
Pluggable technology interfaces	Adapt to multiple control, messaging, logging, and persistency implementations without impact to core application source Globally consistent statistics and testing infrastructure

Structs And Nodes Development has two primary requirements:

1. Use struct declarations to define data, and node declarations to define processing modules.
2. Use generators to write as much of the application code as possible.

Switching to code generation is easy, and gets rid of all the tedious work that nobody in their right mind wants to do anyway. Switching to structs is also easy, but can be more of a paradigm shift. Most organizations model their data starting from either

• the relational database schema (or E/R model)
• the UI forms and actions
• the web service XML structure (schema or DTD)
• the java object model

In typical development, the technology is chosen first and then the implementation is done. Really the requirements of the application should determine the technology, especially as both the technology requirements, and the supporting technology itself will evolve over time. Structs and Nodes Development provides a basis to define the application requirements without having to commit to a specific technology first. Unfortunately this freedom is not what people are used to. Changing to SAND may require a shift in perspective.

If your organization is already using an abstract modeling tool with sufficiently general data definition capabilities, and that tool has generator capabilities, then it may be possible to generate SAND definitions from it. If not, it is usually possible to generate source for the modeling tool from the SAND definitions.

The default technology implementations in sandev are completely original implementations developed without reference to any other existing source code. They are built based on our general experience (going back to around 1986), and common computer science techniques (going back way before that). The fundamental theories and practices this work is based on have been around since the late 70s.

If we define "generation" to mean the number of times the development lead on a particular technology has implemented something similar before, then this is a rough breakdown of the sandev component technologies that ship with the open source release:

• Messaging: 4th generation
• Persistence: 6th generation
• UI: 3rd generation
• Configuration: 2nd generation
• Control: 2nd generation

Everybody has dealt with logging, exception processing, system build, deployment, documentation and other utilities for every project they've worked on, so it doesn't make sense to describe these in terms of technology generations. The sandev environment supports all the mod cons.

There are three major stages of enterprise software development:

1. individual enterprise applications, with little or no communication between applications outside of shared database access.
2. communications between specific applications are built on a point-to-point basis as needed.
3. enterprise communication is the primary focus, applications are built to fit into a communication/management model.

There is nothing wrong with being a stage 1 organization. The advantages of the later stages grow as the pain associated with managing application islands increases. Clearly if you only have one primary enterprise application, then integration is not much of an issue and setting up a common architectural basis will not be your first priority. At this stage SAND is useful for the generators, and the visibility provided into the enterprise application.

At stage 2, SAND provides the same advantages as stage 1, but shifts the focus from point solutions to integrated solutions. The required goals are achieved, while enabling enterprise communications to grow. With a common architectural basis, enterprise applications can be added as needed, without the enterprise becoming mired in an exponential growth of point solutions, or committing to a single integration technology.

At stage 3, enterprise development is usually quite customized. SAND was built to work at stage 3, with the understanding that the organization will create or customize their SAND generators based on their unique requirements. At this stage, SAND provides a framework for enterprise application development.

Yes. As with any integration effort, you will need to write adaptor code, so this is really two questions:

1. What needs to get written to adapt an existing application?
2. When is this work necessary?

While the answers to these questions depend on the situation, you do not need to rewrite or change any existing code to use SAND. In general, you need to

1. determine what communications are relevant to the enterprise
2. write struct definitions for these messages
3. write an adaptor node which processes these messages by communicating with the existing application.

There is a huge range of approaches, mechanisms, tools, and technologies for adapting existing applications. All those that we know of are compatible with the SAND methodology.

The primary goal of the sandev project is to serve as an example of how to build a Structs And Nodes Development framework generator, and to provide default reference information for general use.

A secondary goal of sandev is to provide a smooth migration path from stage 1 enterprise application development up through stage 3, without requiring additional specific technologies or frameworks. The Structs And Nodes Development methodology, coupled with the code generator infrastructure and existing codebase, provides for extremely rapid and flexible application development (aka SANDRAD).

A third goal of sandev is to illustrate how SAND works, specifically:

• How the database, communications, and user interface aspects of a data definition relate to one another.
• How the framework code, configuration, deployment and runtime management of processes are related to one another.
• How the data and processes work together.
• How the application is bound to specific supporting technology that enables it to run.

Model Driven Architecture (MDA) uses a UML model of the application to generate code. More specifically a platform independent model (PIM) drives a platform specific model (PSM) through code generation. Changes to the system are done through changing the model, which is separate from the generated code. Changes to code are not reflected in the model.

SAND does not use a separate model hierarchy to generate code. The emphasis is on iterative application definition and repeated code generation. The source code and the application definition are one and the same.

Aspect Oriented Programming (AOP) and a framework generator are overlapping solutions derived from different perspectives. Both work from a definition to produce code in accordance with a pattern, and a complete application framework is equally valuable whether generated via AOP, or a framework generator, or both. A framework generator can easily work with AOP thanks to the output of a code generator being indistinguishable from handwritten source.

A framework generator is first and foremost a generator, which means it runs before code compilation. That distinguishes it from runtime interpretive techniques (such as reflection, runtime metadata discovery, XML data parsing etc), and from post-compilation modification techniques such as bytecode manipulation. These techniques are also important, and increasingly a part of application processing and platform deployment, but they are distinct from framework generators based on when they do their work.

The goal of a framework generator is to produce an application with all the advantages of being handcoded from scratch (such as compiling to a native executable, easy debugging etc).

Structs And Nodes Development (SAND):

• works as a service oriented architecture (SOA), but emphasizes more tightly integrated applications.
• has a more precise and static deployment configuration than software agent approaches.
• is more loosely coupled than traditional EJB™/J2EE™ development, with most processing done via messaging.

SAND separates application code from supporting technology code, allowing both to be implemented more effectively.

A code generator is anything that automatically writes source code. Code generators range from scripts or wizards that are run once, to sophisticated software tools integrated into the iterative build process, that write all the code necessary for a major portion of an application (a common example is persistency). Because the advantages of code generation are compelling (implementation consistency, capture and refinement of programming knowledge etc), many large scale application development efforts use at least one code generator, and many use several. Once a development effort is running multiple generators, their use needs to be coordinated. Once several code generators are coordinated in a build, that build becomes a framework of generators.

As a framework of generators grows in complexity, several points begin to emerge:

1. Build dependencies between generators need to be supported. It is important to know when a generator needs to be run (changes to the definitions it uses or changes to the generator itself), and when it should not run (so the generator doesn't cascade unnecessary build work).
2. The generators should all run before compilation begins. Otherwise there is a risk of dependencies not being properly checked.
3. Chaining generators together doesn't scale well, since they can't be modified independently. Translating a central data definition into input for each generator allows each generator to work as an independent build module.
4. A standard build interface for generators makes writing generators accessible to developers, increasing effectiveness and helping to capture collective technology expertise.
5. Removing references to supporting technology APIs from the core application source enables application coding and generator coding to proceed independently.
6. Generators want to be easily shared across projects, and need to be accessible from multiple project builds as a single source.

Addressing these points results in an integrated collection of generators, all working from a common definition of application data and functions. This integrated package is a framework generator.

Messaging communications in SAND are defined independently of the transport mechanism. That allows us to use direct method calls for local communications whenever possible. That (and years of experience building a broad range of messaging applications) allows us to build tightly integrated, high performance systems with all the flexibility of a message-oriented architecture.

Our transport independence allows us to work across a variety of technologies (or combinations of technologies) to achieve an appropriate balance of speed, flexibility, and external visibility. So you can choose between web services, various JMS vendors, proprietary messaging protocols, or combinations of these as appropriate.

Yes. But it doesn't currently use them. A JavaSpace is a Jini service with semantics similar to a cache:

• "write" copies an object into the space
• "read" copies an object from the space
• "take" copies and removes an object from the space

In a SAND application, components generally react to receiving messages, and reference their own copies of any information they need. Updates will only succeed if they reference the most recent information, with transactional integrity guaranteed by the DataManager. So any data in a SAND application's JavaSpace must be managed by the application to ensure it is only accessed through the space semantics.

At the time of this writing, the plan is to leave JavaSpaces out of the main SAND framework, so that applications are free to use JavaSpaces as they see fit without any potential interactions or increased complexity.

Use the SandUI editor to define the screens, links and actions that make up the UI. Implement your UIFormOwner node to handle the data processing. Modify the templates to make the display look nice.

The SandUIAdaptor calls UIScreenAdaptor.getScreen to retrieve a working copy of the current screen. UIScreenAdaptor loads the formState for each link by calling UIFormAdaptor.getFormContext. When the screen has been reloaded, each UIFormContext action is either CUSTOM, one of the standard form actions, INIT, or UNDEFINED.

The SandUIAdaptor then processes the screen by walking the links and processing each one if necessary:

• If the link held a custom action, then UIFormOwner.doAction is called.
• If the link held a standard form action, the UIFormManager.processForm is called.
• If the link action is INIT, then UIFormOwner.doAction is called.

Some standard form processing may affect data references, in which case UIFormOwner.doAction(ACTION_REFRESH_GLOBAL_DATA,...) is called for each link to allow the references to be updated. If you have multiple forms on a single screen, where updating one form affects the contents of another, then you need to implement this action handler. Otherwise the form that handled the action is already up to date.