This is an overview document describing high level technical decisions
and considerations bounding and relating to the SandBoss project. SandBoss
supports the Structs And Nodes Development (SAND) methodology for
distributed enterprise application development and deployment. For
implementation details, refer to the SandBoss
documentation. For overview information on SAND, see the original whitepapers.
Boundaries of the SandBoss project:
While the SAND methodology can be extended to programming languages like
C, C++, C#, VB, Python, Perl (or even Cobol), SandBoss will remain focused
on SAND as it applies to the standard Java language. Code generation for
other languages in support of auxiliary processing will be left to
specific applications. In other words, SandBoss supports apps written as
plain Java classes. Support for languages outside of Java is left to the
specific application generators.
SandBoss was developed as an implementation of SAND, using JBoss(tm) as
the primary platform. The intent is to provide a fully functional SAND
environment that is accessible to all developers, and to provide a
reference implementation for other J2EE containers such as IBM WebSphere,
Sun iPlanet, BEA WebLogic, Macromedia JRun, Borland etc.
It is not our intention to adapt SandBoss to these other environments.
Instead, we hope to see additional SAND environments covering these
products (something like SandPlanet, SandLogic, SandRun, SandBuilder etc).
The idea is that a SAND developer would simply copy their app/deploy source
files into their environment of choice, rebuild, and run. Common build and
code generation would be factored across these projects where possible.
We also hope to see additional SAND environments for products like
Microsoft .NET, plain Apache Tomcat/Struts, Systinet, Oracle, and a variety
of other technologies (e.g. SandNet, SandCat etc). With the same source
code portability.
It should go without saying that extension into the wireless, J2ME etc.
space is also a separate endeavor (e.g. SandGrain), and outside the
SandBoss scope (even though we definitely want to go there).
Purpose of the TaskHeap application:
The TaskHeap application has two purposes:
We would like to eventually grow this into a reasonably serious tool for
distributed project management, including tie-ins to Sourceforge, Microsoft
Project import/export functionality, and PMXML. It would also be our
intention to provide integration into bug/defect tracking (like Bugzilla)
and other groupware.
We would potentially like to factor the discussion portion so it can
wrap existing threaded discussion list server functionality or provide a
standalone implementation depending on how it is deployed.
Development of TaskHeap is based on sponsorship and our own needs.
Jakarta Ant was chosen for our build process because it is solid open
source and everyone understands it. We may do some factoring at some point
which could lead to even higher level ant tasks, but we plan to preserve
the existing override targets. We definitely would seek to avoid impacting
any existing custom build code.
The build does not generally support a flag to run without creating
documentation, because we feel that docs are critical for development.
That said, doc updates for small incremental changes can cause too much
development overhead, so we don't recreate documentation if it already
exists.
We generally do the best job we can with dependency tracking. So the
build is dependable without wasting your time. We support projects that
require other projects (for application modularity), and multiple
deployments for any given project (versioning and multiple installations).
It is our goal for the build to provide adequate hooks for integration
with UML generators, indexing, visualization, editing and other development
technology. If there is a useful development tool (either IDE or
standalone) we would like to support it. That said, the core build should
require only what ships standard with JBoss(tm) and Ant, so integration with
things like TogetherSoft or Rational (or even open source projects like
Poseidon) will probably be done on a per-application basis for now.
In SandBoss, explicit runtime control is confined to nodes listed in the
configuration. Control of adaptor node instances, whose lifetime is
determined by the adapted technology, is implicit and managed by that
technology. So for example the lifetime of the HTTPConfigEditor (an
HTTP/HTML servlet adaptor node) is determined by the servlet container (the
HTTP servlet technology).
Explicit runtime control in JBoss(tm) is accomplished via JMX, using the
standard MBean interface supported directly by the JBoss(tm) control panel.
A dynamic MBean interface is also generated, but not currently used. Open
MBeans and model MBeans will be supported in the future as needed.
SandBoss is designed to support multiple simultaneous control
interfaces, because most applications will want a more detailed control
panel with integrated runtime statistics. SandBoss is currently pure JMX.
We want to add support for SNMP, including a relatively standardized MIB
registration format, but we are leaving this to specific application
requirements for now since the JMX space is still evolving.
It is important for us to integrate directly with the more popular
commercial application management interfaces (like HP OpenView, Tivoli JMX
etc) and with other open source efforts (like MX4J), in order to provide
the best possible application management. We will probably add adaptors
for these products (via JDMK and/or following JSR 160 recommendations) into
SandBoss for anything JBoss(tm) doesn't support directly.
SandBoss provides optimized message delivery, translating a message
transmission into a direct java call between two nodes in the same JVM.
Although most JMS containers (including JBossMQ) optimize these calls, the
setup for a JMS call (serializing the message) can still cause unnecessary
overhead, and it gives extra flexibility to have optimization built in at
the top level.
Due to the rapid evolution of web services, and extensive functionality
of established MOM products, interprocess communication technology has
become increasingly application specific. A given application may involve
one product, several products, or a custom mix. A custom solution could
involve different technologies for synchronous communications versus
publish/subscribe, and different technologies within each of these
paradigms depending on optimization, security, and transactional
requirements. SAND keeps this churn out of the application code, but we
expect continued evolution of the supporting technology.
It is our expectation that most SandBoss apps will utilize predominantly
JMS and web services, as these are the current leading standards. However
we expect to see some technology-specific code where product features like
wireless messaging conversion, certified messaging, distributed queues, or
other features are required and provided by the supporting technology. We
do not plan to bring in adaptors for other J2EE containers (IBM MQSeries
belongs with the IBM container), but we are open to building adaptors for
things like Progress SonicXQ, Tibco Rendezvous and others.
Even though .NET kind of belongs with the Microsoft container, we're
open to building a general adaptor for that, and for other specific
protocols, as needed for general application use.
When connecting to legacy EDI systems (or even to CORBA, RMI and other
protocols), our general approach is to create an adaptor node which
translates to/from that protocol to a more recent standard. When budget
and architecture allows, legacy connection can also be done via third-party
integration products (either via JCA or a proprietary interface). Each
case is considered uniquely. If a specific stack can be applied generally,
it may be released back into SandBoss.
Support for Jini is currently off-radar for SandBoss, although we are
generally interested in both discovery and load balancing. We want to put
together a cohesive statement on the conjunction of SAND with agent-based
architectures first. JXTA is also off-radar for now.
Messaging is just one of the cases where an object is serialized. To
cover the maximum number of these cases, SandBoss includes fast XML
serialization based directly on the native Struct declarations. We are not
currently considering any XML processing that requires technology outside
of what ships with JBoss(tm), except on a per-application basis.
XML schema generation is supported on a per-application basis for now,
although it may be folded into the main release later (possibly in
conjunction with a JMI model and application metamodel generator). Since
many web services products autogenerate supporting declarations (including
WSDL, UDDI and more), this is also being handled on a per-application basis
for now.
While simple binary serialization is easy to support, SAND messages are not currently declared serializable because:
It's possible we may add default binary serialization, and other
Serializer implementations later. Also because of the features being
provided by supporting technologies, we are currently holding off on a
SAAJ Serializer until it turns into a general need.
Authorization is inherently application specific, which is why this is
handled through an Authorizer interface, rather than a general purpose node
in SandBoss. While we expect many applications will leverage JAAS, this
may be overkill in some cases and require supplemental logic in other
cases.
Standard encryption processing (for passwords and things) will be
handled on a per-application basis, although we will provide some basic
utilities based on JCE. We don't expect SandBoss to get involved at the
level of JSSE (SSL, TLS), since most of this is handled at the level of the
webserver or MOM. This is left to the supporting technology.
Certificate chains and certification paths are related to the
application's transactional requirements. This is a critical part of
the application design, but not part of SandBoss per se.
SandBoss "out of the box" supports the HSQL (hypersonic) database
because it's a good choice for development and ships with JBoss(tm). It's
generally pretty easy to write a complete JDBC or OODB Persister
implementation. Eventually SandBoss will probably ship implementations for
every database out there, as we build them or people donate them.
The default Persister implementation uses JDBC directly. Since SandBoss
generates all the code from the struct definitions, CMP, BMP, JDO or raw
JDBC are all about equally easy. Of these JDBC has the best support for ad
hoc queries. Even if you prefer JDO QL over SQL, SQL seemed like a better
choice to us for now. Feel free to write alternate implementations.
Transaction integrity is assumed as part of the Persister
implementation. We expect that applications with transactional integrity
issues beyond what a single database or container can provide, will write
their own Persister implementations using JTA/JTS. This includes access
to legacy EIS systems via JCA or JNI.
Caching and query processing is built on top of the messaging,
persistency, and UI layers, so that's not covered here. See the product
documentation for details.
SandBoss generates standard HTML forms from the struct definitions, and
these can be used to create web interfaces for data entry and query
operations. For general display processing, we expect an application will
format the XML serialized form of the object(s) using XSLT.
Our plan is to support any and all other standard form processing as it
evolves, including XForms and anything growing out of JSTL. This includes
support for specific vendor products (like Flash), as needed. We will also
probably ship standard Swing components at some point.
We're not sure to what extent we are going to incorporate email
utilities and capabilities useful for creating portals and eCommerce web
sites. More on that later.
Acronyms and terms:
JBoss is a trademark of Marc Fleury. All other trademarks mentioned
herein are the property of their respective owners.