没有合适的资源?快使用搜索试试~ 我知道了~
温馨提示
试读
335页
This first part of the book introduces OSGi and Equinox, Eclipse’s implementation of the OSGi standard. Chapter 1outlines the history and context of OSGi. Its usefulness and applicability are illustrated with real-world examples of OSGi and Equinox in action. Chapter 2 gives an overview of OSGi concepts, terminology, and architecture to ensure that all readers have a common understanding.
资源推荐
资源详情
资源评论
OSGi and Equinox
Creating Highly Modular Java
Systems
Part I: Introduction
This first part of the book introduces OSGi and Equinox, Eclipse’s implementation of the OSGi
standard. Chapter 1outlines the history and context of OSGi. Its usefulness and applicability are
illustrated with real-world examples of OSGi and Equinox in action. Chapter 2 gives an overview of
OSGi concepts, terminology, and architecture to ensure that all readers have a common
understanding.
Chapter 1. OSGi, Equinox, and Eclipse
As this book goes to press, both OSGi and Eclipse are celebrating their tenth birthdays as Java
technologies. Though they were developed independently in completely different domains, their
lineage can be traced back to teams in the same organization with a similar need to provide
componentized Java solutions. In the case of OSGi it was home gateways and set-top boxes. For
Eclipse, that need was in the tooling space. Both, however, had very similar needs for modularity
and extensibility.
In this first chapter of a book dedicated to OSGi and Equinox, we look at some of the history behind
these technologies, how they are used, what they are good for, and what they can do for you.
1.1. A Bit of History
For the first few years, OSGi and Eclipse technologies grew up in parallel with only a few passing
encounters. The OSGi organization was a loose consortium of embedded and home gateway
vendors. Its modular runtime specifications evolved quickly with several major revisions, new
services, and expert groups in different domains, particularly vehicle software. Adoption ramped
up, and more and more framework implementations appeared. The OSGi community maintained
its focus on the embedded market, and those needs continued to be reflected in concise and honed
APIs and design.
At the same time, Eclipse was a loose consortium of software tool vendors looking to create a
comprehensive tooling platform. Its technology was maturing and quickly dominating the tooling
market. Eclipse-based offerings with thousands of components were shipping as flagship products
from major software companies. Modularity and the open community, two key ingredients, were
working as a powerful pair to drive a revolution in the tooling world. Eclipse also began to reach
beyond tools and into rich client applications. This shift drove the need for a more robust
modularity mechanism, support for dynamic behavior, and, moreover, standardization.
In 2003 the Equinox project was created at Eclipse. The initial goal was to address the
runtime-related issues seen in the Eclipse of the day—static behavior, a nonstandard markup and
execution model, and, as a result, the inability to leverage the work of others in areas such as
provisioning and management. OSGi was not the only contender.
After a public survey of the available technologies (e.g., Avalon, JMX, and, of course, OSGi), OSGi
was identified as the most promising approach—its clear component model and strong execution
specification were seen as great assets. The potential for leveraging the standardization and
creating an even broader community was clearly evident.
Having decided on OSGi, the team had to get, write, borrow, or co-opt an open-source
implementation. At the time there were relatively few choices: the open-source Oscar project at
ObjectWeb—now the Felix project at Apache—and IBM’s Service Management Framework (SMF),
a shipping commercial framework. Knopflerfish, now an open-source implementation, was not yet
open-source and was unknown to the team.
Oscar had lots of great characteristics, not the least of which was its internal simplicity. SMF had
the benefit of being an industrial-strength implementation that had been in production for some
years and had the backing of a team of developers. In the end SMF was selected as the starting
point. IBM donated the code to Equinox, and the transformation began in earnest.
Marrying the two mind-sets and approaches was not easy, but working closely with the OSGi Core
Platform Expert Group, the Equinox team helped evolve a number of changes and additions to the
OSGi framework specification to cover the new use cases. Lazy activation, bundle fragments,
bundle name and version semantics, and bundle dependencies are all fruits of this very successful
and productive collaboration. Within six months the original Eclipse runtime was seamlessly
replaced with the new Equinox OSGi implementation. From there Equinox evolved to be the
reference implementation for the newly minted OSGi R4 framework specification, and the future of
both communities changed forever.
Part II: OSGi by Example
The best way to learn about the power of OSGi and Equinox is to build a real system. This part of
the book guides you through just that. Starting with a blank machine, we walk through setting up
Eclipse for OSGi development and then creating, running, debugging, and enhancing a reasonably
full-featured fleet management system called Toast. The screen shots here show an example of the
Toast in-vehicle client you will build.
[View full size image]
The material in Part II is presented in an informal tutorial style—as if we were sitting with you and
guiding you through Toast’s development. You are encouraged to follow along and do the steps
described. If you would rather not follow the steps, or are having difficulties, the completed code
for each section is also available in an easy-to-use Samples Manager. Even though the chapters are
very development oriented, the text for each chapter is complete and can be read without following
the steps or looking at the supplied code.
Chapter 3. Tutorial Introduction
This chapter guides you on the journey of developing a fully functional OSGi-based application,
Toast. Using the same application throughout the book adds to the coherence of the samples and
more closely matches the situations encountered in real-world software development. The
principles and practices discussed throughout are applicable in a wide range of application domains
and execution scenarios. Before getting down to the nuts and bolts of Toast development, we set
the stage for the application by outlining its nature and evolution. We also ensure that you are set
up with a working development environment.
This chapter focuses on three major issues:
• Outlining the sample application and sketching its evolution
• Setting up your Eclipse IDE so you can develop the code yourself
• Getting and using the Samples Manager to compare and manage the sample code
3.1. What Is Toast?
Toast is a sample application in the telematicsand fleet management domain. If you’re unfamiliar
with the term, you’re almost certainly familiar with the concept. Wikipedia has the following to say
about telematics:
[Telematics is] the integrated use of telecommunications and informatics. More specifically it is the
science of sending, receiving and storing information via telecommunication devices.
You will have seen this in car navigation and infotainment devices. A typical telematics system
interfaces to the devices in the vehicle and provides a user interface for interacting with or
managing the devices. More sophisticated systems connect to a fleet management control center
over a wireless network and allow remote control of the devices.
In its finished form, Toast covers all of these bases—it interfaces to a simulated GPS and airbag,
integrates with Google Earth, and communicates with an OSGi-based fleet management control
center using a variety of protocols.
At a high level, Toast consists of a client and a back end. The Toast Client provides a variety of
functionality, including an emergency application that notifies the control center of the vehicle’s
GPS location when the airbag deploys, an application that tracks the vehicle’s GPS location and
periodically notifies the control center, a touch screen interface to control the vehicle’s audio and
climate systems, and a turn-by-turn navigation system.
The Toast Back End is developed over the course of the book from a simple emergency monitoring
station to an extensible fleet management platform for managing and controlling vehicles. This
includes vehicle discovery, tracking, and software management or provisioning.
The attractiveness of Toast as an example goes beyond the familiarity of telematics, fleet
management, and the functionality of the various applications. It is compellingly extensible—we
can reasonably explore a number of technologies without making it up. More important, this range
of scenarios enables us to discuss a variety of real-world OSGi-related challenges:
Bundle granularity—A deployed Toast system, including the in-vehicle client, the device simulators,
and the control center, amounts to over 100 bundles. That may seem like a lot, but this
architecture both is representative of real systems and allows us to demonstrate a number of best
practices in dealing with large numbers of interdependent bundles.
Third-party libraries—Most real-world applications make use of third-party code; Toast is no
exception. The full Toast application uses libraries from Eclipse, Apache, the broader Java
open-source community, as well as Google JavaScript. We walk you through the process of
incorporating non-OSGi-aware third-party libraries into an OSGi-based application and detail the
issues to watch for.
Dynamic installation and removal of functionality—Toast is a highly dynamic application with
functionality being installed and removed, servers and clients interacting, and user input being
handled. Through this example we show how to write bundles that adapt to the appearance of new
functionality and to the removal or updating of dependencies. We also show how to use p2, the
latest deployment implementation in Equinox, to manage executable Equinox profiles.
Extensibility and collaboration— As you walk through the development of Toast, you’ll see a
number of approaches to extensibility and collaboration, including services, Declarative Services,
the Whiteboard Pattern, the Equinox Extension Registry, and more. Writing new functionality is
relatively straightforward, and Toast combines this with support for the dynamic installation and
removal of applications to create a powerful software platform.
Testing and simulation strategies—Throughout the book, Toast develops into a reasonably complex
application. Accordingly, we provide examples and best practices for automated testing, from POJO
(plain old Java object) development to using mock objects and JUnit in OSGi-based system tests.
We also show how to test against simulated devices for situations where real device hardware is
either unavailable or cannot be used economically. Deploying real airbags can get very expensive!
Off-board communications—Very few systems today stand alone. Most eventually communicate to
off-board servers, peers, or subsystems. For example, Toast clients use HTTP to communicate with
the control center running the Jetty web server. The device simulator uses a similar approach but
embeds a small web server in the vehicle itself. Provisioning is done using the Eclipse
Communications Framework (ECF) to talk to software repositories.
Graphical and web-based user interfaces—Using OSGi certainly does not require a user interface;
many real-world applications are “headless.” Nevertheless, Toast provides a number of UI
examples—the graphical user interface intended for an in-vehicle touch screen, a simple web UI for
the control center, and JavaScript web-based UI for the device simulator.
剩余334页未读,继续阅读
ZHANGSAN
- 粉丝: 0
- 资源: 1
上传资源 快速赚钱
- 我的内容管理 展开
- 我的资源 快来上传第一个资源
- 我的收益 登录查看自己的收益
- 我的积分 登录查看自己的积分
- 我的C币 登录后查看C币余额
- 我的收藏
- 我的下载
- 下载帮助
安全验证
文档复制为VIP权益,开通VIP直接复制
信息提交成功
- 1
- 2
- 3
前往页