The Openwings Tutorial
Introduction
This tutorial provides guidance on design, development, and deployment of
components using the Openwings reference implementation, version 0.9.2. This
document is meant to be a terse guide. it does not discuss the Openwings APIs in
detail—please refer to the Javadocs for that information.
This tutorial contains material that is specific to this Reference Implementation
of Openwings. It will be continually updated to reflect changes made in new
releases. If you notice an error in the tutorial, please e-mail us so we can fix the
problem.
Click here to download a PDF containing all the tutorial content.
Tutorial Trails
Trail I. Openwings Architecture Introduction
1. Introduction
2. Architecture Overview
3. Component Services
4. Container Services
5. Connector Services
6. Install Services
7. Context Services
8. Management Services
9. Security Services
Trail II. Getting Started (Quick Start)
1. Installation
2. Running the Demo Applications
file:///S|/OpenwingsDotOrg/html/openwings-0.9.2/tutorial/index.html (1 of 5) [12/19/2002 6:46:37 PM] The Openwings Tutorial
3. The HelloWorld Demos
4. The HelloWorldSynchronous
Component
5. The HelloWorldProvider Component
6. The HelloWorldSimpleUser Component
7. The HelloWorldUser Component
8. The HelloWorldAsynchronous
Component
9. The HelloWorldPublisher Component
10. The HelloWorldSubscriber
Component
11. Compilation
12. Connector Generation
13. Packaging
14. Installing Your Component
15. Running Your Component
Trail III. The Openwings Shell
1. Navigation
2. Basic Commands
3. The ls command
4. The cd command
5. The lcd, pwd, and lls commands
6. The install command
7. The process command
8. The uninstall command
9. The edit command
10. The findclass command
11. The quit command
12. Other Useful Shell Tricks
Trail IV. The Openwings Explorer
file:///S|/OpenwingsDotOrg/html/openwings-0.9.2/tutorial/index.html (2 of 5) [12/19/2002 6:46:37 PM] The Openwings Tutorial
1. Introducing the Openwings Explorer
2. Basic Navigation
3. Installing a Component
4. Uninstalling a Component
5. Starting a Process
6. Stopping a Process
7. Moving a Process
8. Editing a Component Descriptor
9. Viewing more about a Component
10. Shutting Down a Platform
11. More Explorer Tips
Trail V. Design Topics
1. Design Introduction
2. Architecture Definition Language
(ADL)
3. Service-Oriented Programming
Principles
4. Defining Service Contracts
5. Defining Components
Trail VI. Developing Components
1. Developing Components
2. The Development Environment
3. Naming Conventions
4. Component Service APIs
5. The Component Interface
6. The ComponentComplex Interface
7. Failure Recovery Techniques
8. ServiceUI Development
file:///S|/OpenwingsDotOrg/html/openwings-0.9.2/tutorial/index.html (3 of 5) [12/19/2002 6:46:37 PM] The Openwings Tutorial
9. Component Compilation
10. Connector Generation
11. Using Policies
12. Using Properties
13. Dependency Resolution
14. Dependency Substitution
15. Component Packaging
Trail VII. Deploying Components
1. Component Deployment
2. Component Installation
3. Component Execution
Trail VIII. Code Security
1. Introduction to Openwings Code
Security
2. Editing Your ICD
3. Create Your Component's Security
Policy
4. Rebuild and Reinstall
5. Debug
Trail IX. Troubleshooting
1. Openwings Troubleshooting Tips
Glossary
Openwings Glossary
file:///S|/OpenwingsDotOrg/html/openwings-0.9.2/tutorial/index.html (4 of 5) [12/19/2002 6:46:37 PM] The Openwings Tutorial
Appendices
Appendix A: Native Code
Appendix B: System Performance
Appendix C: Log Control
back to top
© Copyright 2002, General Dynamics Decision Systems. All rights reserved.
file:///S|/OpenwingsDotOrg/html/openwings-0.9.2/tutorial/index.html (5 of 5) [12/19/2002 6:46:37 PM] l
l
l
l
l
l
l
Installation
Openwings Introduction
Congratulations for taking the leap into the world of Service Based Architectures
(SBA). Perhaps you have heard something about SBA and want to find out what it is all
about. In this section we will discuss some of the history that has lead up to SBA and
why it is important.
History
Often it is helpful to reflect on the past to understand the present. There have been
three key software technologies underlying the success of the Internet: Internet
Protocol (IP), WWW technologies, and Java. Understanding why these technologies
were successful provides a great deal of insight.
Technology Value Proposition Origin Notes
Internet Protocol (IP) Cross Platform Connectivity Military The plumbing that
Send anything between any provides connectivity
nodes between nodes
WWW (Web Browser, Cross Platform User Interface Academia Brochure-like user access
Web Server, Search User access to capabilities of to capabilities
Engines, HTTP, HTML) any node on the network
Ability to find useful capabilities
Java Cross Platform Applications Industry GUI user access to
Enriched Cross Platform User capabilities
Interface
The reason all of these technologies were successful is that they had compelling value
propositions. Your computer is more useful if it is on the Internet. The Internet is
more useful with web technologies. You can provide much richer user interactions
with Java. These technologies provide greater flexibility and value. By using these
technologies to integrate legacy systems, one can extend the reach and utility of
legacy systems, without losing past investments.
Because of these technologies, the Internet has become a very useful tool. People can
do a tremendous variety of tasks on the Internet, everything from paying their bills,
selling items, buying items, getting the weather, reading the news, finding directions,
filing tax returns, installing software, downloading music, finding movie times, reading
book reviews, doing research, etc. When the Internet first came into existence, there
file:///S|/OpenwingsDotOrg/html/openwings-0.9.2/tutorial/Trail01_Introduction/01_Introduction.html (1 of 9) [12/19/2002 6:46:40 PM] Installation
was connectivity, but it was not easy to find and use things. A published cross-
platform user interface (a web page) and the ability to search for things (a search
engine) dramatically changed the use of the Internet. A compelling commercial aspect
came to the Internet, in such a way that eBay could hold the world’s largest garage
sale with a million of their closest friends.
At times, industry and individuals would like to have these capabilities work together
in ways that their creators could not have conceived. For instance, a travel service is
a prime example of a horizontal integration of services. Travel agents need to book
travel (airlines, bus, train), book tour services, book hotels, book rental cars, find
weather information, book events, and book attractions. Another example is a realtor
selling homes. A client wants to know the price range of homes in an area, crime
rates, seasonal information, schools, easements, fees, previous sales history, taxes,
energy costs, insurance costs, local shopping, local restaurants, noise levels,
gas/electric, cable/internet, sewage/septic tank, public water/well, plot information,
and so forth. The military has similar horizontal integration problems. The military
often needs to coordinate across services, agencies, and nations to achieve its
objectives.
Figure1. Horizontal Integration Examples
file:///S|/OpenwingsDotOrg/html/openwings-0.9.2/tutorial/Trail01_Introduction/01_Introduction.html (2 of 9) [12/19/2002 6:46:40 PM] l
l
l
Installation
That fact is that one cannot predict how services or information will be combined and
used in the future. The whole is greater than the sum of the parts. However, this kind
of interoperability is very difficult to achieve when the only interface to these
capabilities is a web page. Today, the technique of parsing these unstructured HTML
pages is used to integrate across vendors, however it is difficult and error-prone.
Simple changes to websites can break this “screen scraping” approach. The problem is
that there is no programmatic access to these capabilities and no way to search for
these capabilities. This interoperability need has been labeled as many things:
Enterprise Integration
Horizontal Integration
Open-Ended Integration
This has been the driving force behind Web Services. Web services rely on a protocol
for interoperability: Simple Object Access Protocol (SOAP). Since web services are not
concerned with high bandwidth access or passing large amounts of data, they use XML
technologies. Web services can be used to share capabilities, but not software. Web
Services provide the important lookup mechanism through Universal Description,
Discovery, and Integration (UDDI).
Not only do we have these kinds of integration problem for web services, but for
network devices and network services in general. The concept of plugging a piece of
software or hardware onto the network and having it automatically provide services is
very powerful. It extends the utility of these hardware and software components
while making it much easier for users. This same concept of pluggability can even be
extended to locality-based services, similar to what Bluetooth provides.
Often the military has characterized their interoperability problem as an information
dissemination problem, but it is more than that. As an example from a non-military
environment, when you go to the bank to get your balance, the bank doesn’t send you
all of your banking transactions since the creation of your account for you to add up.
Instead the bank provides a service that returns your account balance. This is much
more efficient and convenient. They knew a balance is something people would ask for
and provided an efficient way of accessing it. The military is moving to a service view
of the world and in fact they define interoperability in terms of services:
Interoperability (from Joint Vision 2020): The ability of systems, units, or forces to
provide services to and accept services from other systems, units, or forces and to use
the services so exchanged to enable them to operate effectively together.
Service Based Architectures represent the evolution of distributed software
Component Architectures and System Architectures. The following figure shows the
evolution of component architectures and the focus of Openwings (modified slide from
Sun™ Jini Presentations):
file:///S|/OpenwingsDotOrg/html/openwings-0.9.2/tutorial/Trail01_Introduction/01_Introduction.html (3 of 9) [12/19/2002 6:46:40 PM] Installation
Figure 2. Evolution of Component Architectures
In a world where components can encapsulate both hardware and software, publish
services, and find services to use, our concepts of Systems Architecture must begin to
evolve. The Service Based approach actually makes it easy to define systems, because
service contracts are defined for all inter-node interactions. This makes integration
much easier. Systems architectures are not only concerned with the functional
breakdown, but the quality of service provided. Things like availability, security, and
performance become issues.
The Problem
Here is a succinct statement of the problem(s) SBA is trying to solve.
How do you provide interoperability between software components,
hardware components, and systems in a secure, highly available
manner that is simple to develop and use?
This is a compact statement of a large problem.
The Solution
In this section we break down the various parts of the problem and explain how
Openwings solves it.
file:///S|/OpenwingsDotOrg/html/openwings-0.9.2/tutorial/Trail01_Introduction/01_Introduction.html (4 of 9) [12/19/2002 6:46:40 PM] l
l
l
l
Installation
Services, Discovery, Components, and Deployment
Openwings takes a broad view of Service Based Architectures. Here is how Openwings
defines a service:
A service is a contractually defined behavior that can be provided by a
component for use by any component solely based on the Interface
Contract.
A key thing to note is that there has to be a way to publish and discover a service.
Much like we need search engines to find user interfaces on the web, we need a way
to find programmatic access to services. Though this is a relatively simple definition it
has very powerful implications. It implies that the service cannot depend on:
Discovery protocols
Transport protocols
Platforms
Deployment Environments
This has broad implications for interoperability. Service Based Architectures are an
evolution of Component Architectures. Component Architectures have typically
focused on deployment and inter-process communication; examples include Common
Object Request Brokering Architecture (CORBA), DCE, EJB, Applets, Servlets, etc.
Openwings takes the Software Engineering Institute definition of a component:
A component is a binary implementation of functionality that is a unit of
deployment, which is subject to third party composition and is conformant
with a component model.
Openwings handles the issues of deployment and third party composition through its
Install Service and Component Services. Openwings allows software components to be
deployed on any platform with no user interaction. By combining Openwings software
components with hardware components, one can easily create network appliances that
you simply plug in and turn on to use. The following figure shows an example network
appliance that, when plugged into the network, can display any workstation screen.
file:///S|/OpenwingsDotOrg/html/openwings-0.9.2/tutorial/Trail01_Introduction/01_Introduction.html (5 of 9) [12/19/2002 6:46:40 PM]
