The Openwings Tutorial

Seym

Downloading requires you to have access to the YouScribe library
Learn all about the services we offer

268 Pages

English

About
Information
Extrait

Description

Subjects

Stringin' Along with Chet Atkins

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]