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 Send anything between any nodes	Military	The plumbing that provides connectivity between nodes
WWW (Web Browser, Web Server, Search Engines, HTTP, HTML)	Cross Platform User Interface User access to capabilities of any node on the network Ability to find useful capabilities	Academia	Brochure-like user access to capabilities
Java	Cross Platform Applications Enriched Cross Platform User Interface	Industry	GUI user access to capabilities

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 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

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):

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.

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.

Figure 3:  Network Appliances

Interoperability

Openwings focuses on interoperability of legacy components, new components and systems over time. There are several things that limit the interoperability of components:

• Lack of well-defined interfaces
• Hard-coded communications protocols
• Lack of or hard-coded discovery protocols
• Hard-coded details about deployment environments

Openwings relies on Java interfaces as the primary service contract language for both synchronous and asynchronous types of communication.  Another key enabler of interoperability is Java itself. Java bytecodes are platform-independent, enabling the delivery of mobile code. Openwings provides protocol independence through its connector architecture. Openwings provides discovery protocol independence through its Component Services model.  Openwings also provides techniques to achieve context independence, including isolation from platform details and environmental details through installation services, context services, policies, and properties.

Why is protocol independence important?  History tells us that one protocol does not fit all.  There is the need for transactional synchronous communications, point-to-point asynchronous messaging, broadcast asynchronous messages, real time streams, low bandwidth formats, and so on. If we could agree on the interfaces and interact solely on the interfaces, the protocols could change independently to support all of these different needs and more easily integrate legacy systems (the power of connectors). If we deliver all of the code needed to make use of the service, we don’t even have to agree on the interface (the power of mobile code).

Here are some techniques that Openwings uses for interoperability:

1. Provide the code, i.e. the user interface, needed to use the service.
2. Agree on the contract, not the protocol
3. Extend existing contracts
4. Publish legacy interfaces
5. Provide adapters for legacy interfaces

Availability

Since Openwings is an evolution of Systems Architectures it is very concerned with availability.  The service publication and discovery mechanism in Openwings allows fail-over between service providers. It deals directly with the inherent unreliability of networks and the fact that in large systems, rare things happen most of the time.  The Openwings Container Services provide generic lifetime management of components and can be used to restart components.  When containers are clustered they can provide fail-over between many platforms.  In fact, the Openwings Container architecture allows hetrogenous platform clustering, which enables a collection of computers to act as one large processing resource. In fact, processing itself is a service in Openwings.

Security

After publishing capabilities on the Internet through websites, it became apparent that parts of these sites needed to be protected.  When providing programmatic access and the ability to find these services, a similar problem is created for Service Based Architectures.  The Openwings Security model is primarily concerned with code security and service security, including authentication, confidentiality, non-repudiation, integrity, and authorization strategies. Code security is primarily enforced by the Openwings Container Service. Service security is handled primarily by Openwings connectors. In dynamic systems where relationships can be formed and dissolved, a highly distributed trust model is needed. The Certificate Authority is a core service run by the Context Services and implemented by the Security Services. The net result is that you can control access to services and platform resources.

Scalability

Openwings scales from integrating components, to systems, and systems of systems by providing a single service model.  The Openwings containers are designed to make efficient use of platform resources to allow many components to be executed simultaneously.

Simplicity

One of the primary goals of Openwings is to make systems easier to use; to eliminate the need for the user to manually configure components, install device drivers, or answer a series of questions each time he or she wants to install software.  The Openwings model allows for the creation of plug and play software and hardware.  The Openwings Install Service removes the need for user interaction to install components, even for components that depend on other components. 

Another goal was to make it easy to develop Openwings components.  This includes integration of legacy components.  The programming model is very simple: use, provide, publish, or subscribe to a service.  The Container places only standard Java security restrictions on what components can do.  You can easily package third party software into Openwings components that can run in Containers.  The package format is simply a Jar file that must contain only an Installable Component Descriptor that describes the internal structure of the component, dependencies on other components, and how to run the component (if it is executable). You can develop components without any knowledge of Openwings, simply using service interfaces, and in a few lines of code make them Openwings services.

Related Technologies

The following table gives a summary of various technologies and how they relate to Openwings.

Technology Area	Technology	Notes
Core Technologies	IP, Java	Openwings depends on Java and Internet Protocol.
File Transfer Technologies	HTTP, FTP, etc.	Openwings can use various file transfer protocols.
Synchronous Protocols	SOAP/JAXR, RMI, IIOP, etc.	Openwings connector model supports any kind of synchronous communications.
Asynchronous Protocols	JMS, SOAP/JAXM, etc.	Openwings connector model supports any kind of asynchronous communications.
Discovery Protocols	Jini, UDDI, Bluetooth, JXTA, etc.	Openwings component services model supports any kind of discovery plug-in
Web Protocols	HTML, applet, servlet, etc.	Openwings Service User Interfaces
Grammar Parsing Technologies	XML	Used in Openwings for policies.

Summary

In summary, Service Based Architectures represent the evolution of Component and Systems Architectures.  Openwings extends the value proposition of IP, Web, and Java Technologies, to allow programmatic access to capabilities and discovery of these capabilities.  The following table summarizes the value proposition.

Item	Value Proposition
Services, Discovery	Contract based services and the ability to find them on the network.  Well suited to dynamic network environments.
Components, Deployment	Simple deployment format and automated install / execute.
Interoperability	Platform independence, protocol independence, discovery independence, and context independence.
Availability	Containers, Clusters, and Service Fail-Over handle application and platform faults.  Ability to extend capabilities by adding platforms on the fly.
Security	Secure code and services to control access to your capabilities.
Scalability	One model for components, systems, and systems of systems.  Efficient sharing of platform resources.
Simplicity	Ease of use and ease of development.

Next: Architecture Overview

back to top

Copyright 2002, General Dynamics Decision Systems. All rights reserved.