WebORB Presentation Server provides
a variety of features for all stages of application
development, including client interface design,
client/server integration, application deployment and
runtime operation. Below is a list of the most
notable product features:
|
Ease of use |
WebORB has been
designed to deliver the utmost simplicity with a
variety of tasks involved with product operations.
Starting from rich application development to
deployment and runtime operation, our goal was to
make it as easy as possible to use the product,
its features and APIs. For example:
- It takes just one line of code to bind to
any supported object type
- Deploying a user application into WebORB is as
simple as copying a .NET assembly or a JAR file
into the web application
- User application classes do not need to use
any WebORB classes or interfaces to
expose themselves to rich clients
|
|
|
Universal Object Access |
WebORB offers the
same API function to bind to any supported server-side component. Whether you bind to a .NET or Java
object, ColdFusion Component or an XML Web
Service, the API is exactly the same, but the
generated proxy will point to the requested object
type. This reduces the number of special functions
a developer has to remember and simplifies the
development experience. |
|
|
Security |
Restricting access to
the core application assets must be the highest
priority when deploying rich internet application
into production. WebORB provides several levels of
code level security, as well as extensibility
points for custom authentication and authorization
handling. Below are the highlights of the WebORB
Security subsystem:
- Open vs. Closed System - WebORB
supports two operation modes to simplify
security configuration for development and
provide an easier path to restrict access to
code application assets in production. The
'Open' system mode allows access to all
namespaces, packages, classes and methods unless
there is an explicit access restriction. The
'Closed' system restricts access to all
deployed classes unless there is specific
access permission.
- Namespace, package, class and method
level security - A WebORB configuration file
provides a flexible way to restrict or grant
access permission on various levels of
granularity. Access can be granted or denied for
namespaces or package names with wildcards, or
for individual classes or method names. For
example, WebORB configuration can allow access
to a specific method for all users in one role
and restrict access to another method of the
same class to users in some other role.
- Custom authentication - WebORB
provides a point of extensibility to allow
customizable authentication. Application
developers can plug in custom WebORB
authentication handlers to authenticate client
application users against in-house or 3rd party
security realms.
- Custom authorization - Similar to
custom authentication, WebORB has an
extensibility mechanism to support custom
authorization. Application developers can plug
in a special handler to control resource access
by the client application users.
|
|
|
Management Console |
The Management
Console application provides a simple way to observe
operation of the WebORB server engine. It exposes
control points to configure and manage various
aspects of the product including logging,
invocation and inspection handlers, object and
argument factories, memory consumption, licensing
information and call tracing facility. |
|
|
Data binding |
WebORB implements
a special serialization mechanism to support
seamless client/server data binding. .NET and Java
objects or ColdFusion components can return
respectively DataSet, ResultSet or CFQUERY objects
representing the results of database queries.
WebORB automatically serializes the data to
present it to the client application in the most
natural way for that environment. For example,
Flash Remoting clients receive .NET DataSet, Java
ResultSet or CFC CFQUERY results as a RecordSet object
for the Flash Remoting components package. Client
applications using the Rich Client System/AJAX receive
the data as a RecordSet object available in the
system's library. |
|
|
Data paging |
WebORB supports
a robust and configurable data paging mechanism. If
enabled, data paging transparently applies to the
client/server data binding process. Server-side
objects or global server configuration settings control the
size of the initial page returned to the client.
The client application then uses either the Rich Client
System or Flash Remoting API to control subsequent
data page delivery. |
|
|
Object activation |
One of the core roles
of WebORB is object request broker (ORB). As an
ORB, the product is responsible for constructing
or retrieving instances of objects as the targets
of method invocations. This process is called
'object activation'. WebORB supports three built-in
activation modes: request, session and application
and also provides a simple way to extend the
system with custom activation modes. |
|
|
Custom object
instantiation |
To handle a remote
method invocation from a rich client on a Java or
.NET object or CFC, WebORB must construct the object
first (see Object Activation above). WebORB
implements a default object construction mechanism,
but also provides an extensibility feature.
Application developers can plug in custom code to
create instances of the objects for further method
invocations. |
|
|
Custom argument
instantiation |
Similar to the
custom object instantiation described above,
application developers can plug in custom argument
object factories. WebORB uses argument factories
to handle creation of method arguments for the
remote method invocations. |
|
|
Client/server class
mapping |
WebORB provides a
class mapping mechanism, to simplify client server
integration. The mapping is between client and
server class names. When a client invokes a method
and sends an argument of a particular class,
WebORB checks if the name of the client
class has a server-side mapping. If the mapping
exists, WebORB uses the mapped class as an
argument in the invocation. The same algorithm
applies during the serialization of return values
from the method invocations. |
|
|
Named objects |
Both Flash Remoting
and Rich Client System/AJAX clients use server-side
class names during the object binding process.
Using server class names in the client application
and sending it as a part of the invocation request
imposes several issues. Indeed the name of the
class may change, it may be obfuscated or must
remain private in the server-side application.
WebORB provides a simple yet powerful way to solve
this issue. It's possible to assign a logical names (mappings)
to server side class names, WSDL URLs or CFC names
When a mapping is in
place, client applications can bind to any server
resource using the assigned logical name. |
|
|
Remote references |
One of the most
powerful features in WebORB, remote references
allow delivery of a proxy (to Java or .NET objects)
to Flash or AJAX clients. Once the client
application gets a remote reference (proxy) as a
result of a method invocation, it can invoke any
method on the proxy object. All method
invocations on a remote reference get delivered to
the backend object the reference points to. |
