Glossary
Service Based Architectures like Openwings are relatively new.
Consequently, there is a learning curve. This glossary is an attempt
to make the learning curve easier by listing the most important
Openwings concepts on one page. This list is by no means complete.
But if you're the type of reader who likes to get the broad overview
before diving in, read on.
- ADL - Openwings uses the
Architectural Definition Language to model service-oriented
problems. Details can be found under Design
Topics of the Openwings tutorial.
- Ant - Ant is a make-like
utility. We endorse the use of Ant because it supports platform
independence and it is easy to use. In this tutorial we introduce
Ant in the
Trail02_GettingStarted trail. We go into more detail in
Trail05_Developing Components. We provide several Ant examples
in our demo applications and we provide an
Ant template to use should you want help in making your
own Ant build file.
- Classpath - Classpath
refers to local files that are needed in order for a
component to be executed. Classpath URLs cannot be HTTP
URLs; they must be file URLs. Details on how to provide classpath
information is in the
Dependency Resolution section of the Developing Components
trail. An extensive example detailing why the classpath was
populated the way it was for a demo copmponent can be found
in the
Dependency Substitution section of Developing Components.
Finally, tips for debugging your classpath can be found in the
Component Packaging section of Developing Components.
- Codebase - Codebase
specifies the mobile code URLs that a component needs in order
for the component to be executed.
It's the mechanism that allows us to use remote class loading.
Codebase URLs cannot be file URLs; they must be HTTP URLs. Click
here
for additional information about how codebase works in Jini.
How to provide codebase information in your component is covered
in detail in the
Dependency Resolution of the Developing Components trail.
How to debug your codebase is found in the
Component Packaging section of Developing Components.
- Component - It is easy
to think of a component as a unit of independent deployment.
It is the center-piece of the service based architecture in
Openwings. Of particular note is the idea that
components have states. The notion of a component is introduced
in
Developing Components. A more formal definition is given
in the
introduction section of the Openwings tutorial. How to design
components is addressed in the
Design Topics trail. Keep in mind, that when components
are designed, it is possible to create
several versions of a component.
- Connector - This is
what connects components. The goal is to provide
protocol independence. The nice thing about connectors is
that Component Services does a lot of the detailed work for
you. All the user has to do is know how to generate connectors
for a component. We use Ant to do
that. The first time the notion of connectors are introduced
is in the
Getting Started trail of the tutorial. Generating connectors
is outlined in more detail in the
Developing Components trail. When components are designed,
the connection part of component relationships are denoted by
a modeling method, the
Architectural Description Language, ADL.
- Container - The Openwings
container provides an environment for executing Openwings services.
Key functionality for Container Services can be found in the
Container Services section of the Openwings Introduction.
How we can utilize container functionality is done through Context
Services. We use a
default policy, the Installable Component Descriptor Policy
for an executable component to be run on a container in Openwings.
And the policy loader in Container Services is what we use to
support dependency substitution should a user want to use Openwings
property settings from the
properties.txt file.
- Dependencies - Components
can have dependencies on other components. There are several notions to keep
in mind when considering component dependencies:
- Dependency
Resolution -
Dependency resolution refers to substitution of a suggested
setting of an attribute in a policy and modifying that attribute
into an actual setting. Dependencies are specified by the user
in the
Resolvable Codebase and
Resolvable Classpath attributes of the
Installable Component Descriptor Policy. Of particular note
is the ability to use the dependent component's
version to specify a dependency, assuming
multiple versions of a component exists. If a version is
not specified, Openwings Install Service will find the most
recently installed version of a component that is in a
resolved state.
- Dependency
Substitution The
classpath and
codebase (as well as
properties) of one component can be inherited through the
use of
substitution by another component. This is outlined in detail
in the
Developing Components trail.
Executable String and
Command Line attributes can also be substituted. Click
here for a quick summary table of substitutions.
- Installable Image
- The unit of component deployment is an installable image
(Jar file). Details regarding the creation of an installable
image can be found in the
Packaging section of the Developing Components trail. Note,
we use Ant to create an installable
image. Finally, the
Deploying Components trail further explains how to deploy
your component once an installable
image is created.
- Interface -
Interfaces allow us to declare the nature of a service without
specifying the implementation. The use of interfaces is a fundamental
practice in Openwings because services are defined and obtained
through the use of interfaces. We discuss the definition of
the service contract (interface) in the
Design Topics trail. Another good definition of Java interfaces
can be found
here and
here.
- Native Code -
Native code refers to programs that are written in another
language other than Java, such as assembler or C++. You can
use the
Java Native Interface (JNI) to allow your Java program to
interoperate with such programs. We provide details on how to
do that in Openwings--see the
Native Code appendix. We also offer a Native Code demo that
provides an example in integrating native code. You can find
this Native Code demo under the "demos" folder where you installed
Openwings.
- Policies - Policies
provide configuration information so that components can be
executed in their environment. The
Developing Components trail discusses how to create and
use policies. In most cases, an executable component to be run
on Container Services will be using the
Installable Component Descriptor Policy as their default
policy. But it is possible to create a unique policy for a
user defined interface. The default policy, Installable
Component Descriptor Policy, is discussed in the
Packaging section of the Developing Components trail.
- Properties - The
properties mechanism in Openwings is an extension of Java
properties. Property keys and their descriptions in Openwings
are listed
here but, of course, you may add your own properties. Note
that Openwings further expands its use of properties by using
property substitution. That is, it is possible to obtain
a property setting from one component
and apply it to your component. Information on debugging
your property settings can be found in the
Properties section of Developing Components.
- Service - A service
is a contractually defined behavior that can be implemented
and provided by a component
for use by any component, solely based on the contract. Sometimes
the word "contract" and "interface" are used interchangeably.
That is because services are defined through interfaces. In
the Openwings tutorial, in the introduction, we discuss a formal
definition of a
service noting that services are things that are published
and discovered. The principles involved in designing services
are addressed in the
Design Topics tutorial trail.
|
|
Back to Tutorial Trails
© Copyright 2002, General Dynamics
Decision Systems. All rights reserved. |
|
