|
Sponsored Links
Resources
Enterprise Java
Research Library
Get Java white papers, product information, case studies and webcasts
|
News
News
News
|
Messages: 15
Messages: 15
Messages: 15
Printer friendly
Printer friendly
Printer friendly
Post reply
Post reply
Post reply
XML
XML
XML
|
 |
Article: The Whiteboard Pattern for OSGi
"The Whiteboard Pattern for OSGi" is the second in TSS' series on OSGi, this time focusing on a common pattern in OSGi, called the "whiteboard pattern," where interfaces that can fulfill a contract are searched for in an OSGi repository. It's important to understand OSGi before reading this one - but this one's where you start to learn how to use OSGi fo shizzle.In the first article, we built a truly primitive infobot. It responded to "~put factoid_name factoid" and "~get factoid_name," where the factoid names were basically XPath expressions. (What's more, with the XUL repository, they're truly XPath expressions: you could put in "~get /fact/*" and get the first of any number of nodes, depending on how the XPath engine reported nodes back.) However, fixing the infobot in any way meant uninstalling it and re-installing it, and presumably restarting the darned thing. That's no fun. We should be able to have a deployable bot where new commands can be installed at any point.
This is perfect for the whiteboard pattern. We can install a pircbot implementation, and have the onMessage() method look for implementations of IRCCommand, passing the message to each command in turn (possibly stopping when the command is consumed.) If a command is broken, we can uninstall the command, fix it, and reinstall - all transparent to the IRC bot. Even our factoids can be implemented this way, so our IRC Bot turns into a whiteboard consumer, and can do anything we can think of to make it do.
|
|
|
Message #252961
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Whiteboard pattern definition
The article states that:
"Basically, the whiteboard pattern is this: a content provider registers itself into the OSGi service registry. A content consumer regularly polls the registry for consumers of the content provider type, and then calls each one in turn."
Shouldn't this be:
Basically, the whiteboard pattern is this: a content provider registers itself into the OSGi service registry. A content consumer regularly polls the registry for PROVIDERS of the content provider type, and then calls each one in turn.
change consumers -> PROVIDERS
Thanks.
|
|
|
Message #252963
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
I/F IRCCommand
public interface IRCCommand {
IRCMessage handleCommand(Ebot bot, IRCMessage message);
}
The signature of the handleCommand has two parameters , yet in the code that follows, method onMessage and the class Command it is called with only one parameter, the IRCMessage.
Am I missing something?
Cheers.
|
|
|
Message #252973
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: I/F IRCCommand
Yes, it's the joy of writing an article and code and not re-syncing the two after I was done with part of it.
In other words: "whoops." :)
|
|
|
Message #252980
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Events
Why poll in a thread ? Why not use events, so when the new service with corresponding set of parameters is registered, we can consume something from it.
|
|
|
Message #252999
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Events
Why poll in a thread ? Why not use events, so when the new service with corresponding set of parameters is registered, we can consume something from it. It depends on the need! For one thing, neither article (the first or second) uses OSGi lifecycle for anything other than starting or stopping. Looking for registration events is a separate issue. I can *certainly* go into that if you'd like - *I* just haven't needed it yet, so I don't have a use case with which I can illustrate a valid, sensible usage.
|
|
|
Message #253013
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Article: The Whiteboard Pattern for OSGi
dumb question: Where can I get a jar containing ServiceTracker?
|
|
|
Message #253018
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Article: The Whiteboard Pattern for OSGi
dumb question: Where can I get a jar containing ServiceTracker? Depends on the OSGi container you use. For Equinox, it's in org.eclipse.osgi_3.3.2.R33x_v20080105.jar - or similar, depending on the specific Equinox release you have.
|
|
|
Message #253020
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Article: The Whiteboard Pattern for OSGi
dumb question: Where can I get a jar containing ServiceTracker? Depends on the OSGi container you use. For Equinox, it's in org.eclipse.osgi_3.3.2.R33x_v20080105.jar - or similar, depending on the specific Equinox release you have.
So there's no standard jar for this? That seems weird.
|
|
|
Message #253021
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Article: The Whiteboard Pattern for OSGi
I have a couple of concerns/questions about this approach.
First, the code for stopping the thread (which you got from the whitepaper) doesn't seem proper to me. The run method is synchronized (for reasons that are unclear to me) but the stop method is not. As I understand it, there's no guarantee that the cache containing 'thread' for the thread that calls stop will be pushed to the cache for the thread that's calling the run() method. I don't think synchronizing on one side is enough. Unless I am mistaken, that just works by accident.
Secondly, I played around with this and moved the wait between the getServices() call and the loop over the services. If I stop or even uninstall the clock bundle between getServices and the getContent() call, it still works. That's a little confusing to me. Shouldn't uninstalling the bundle invalidate references to the services supplied by that bundle?
|
|
|
Message #253100
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Article: The Whiteboard Pattern for OSGi
OSGi Service Platform Core Specification Release 4, Version 4.1, Section 4.3.9
The BundleActivator interface defines a stop(BundleContext) method, which is invoked by the Framework to stop a bundle. This method must release any resources allocated since activation. All threads associated with the stopping bundle should be stopped immediately. The threaded code may no longer use Framework-related objects (such as services and BundleContext objects) once the stop method returns. If the stopping bundle had registered any services during its lifetime, then the Framework must automatically unregister all registered services when the bundle is stopped. It is therefore unnecessary to unregister any services in the stop method.
The Framework must guarantee that if a BundleActivator.start method has executed successfully, that same BundleActivator object must be called with its BundleActivator.stop method when the bundle is deactivated. After calling the stop method, that particular BundleActivator object must never be
used again.
Packages exported by a stopped bundle continue to be available to other bundles. This continued export implies that other bundles can execute code from a stopped bundle, and the designer of a bundle should assure that this is not harmful. Exporting interfaces only is one way to prevent such unwanted execution when the bundle is not started. Generally, to ensure they cannot be executed, interfaces should not contain executable code.
So as I read this, an exported package must remain available even when the bundle is stopped (also uninstalled) but services are to go away immediately. If we take the clock example and made it have a thread which is used internally to satisfy requests, it would (according to the spec) need to be stopped 'immediately' when the bundle is stopped. That would mean that it could no longer service requests.
Assuming I understand this properly, doesn't this mean that the whiteboard pattern suffers from a race condition? There's a (non-atomic) gap between when the services are retrieved and when they are called. In the example above the gap is too small for this to create an issue but what if the lookup returned dozens or hundreds of services? The last one might not be called for several seconds or even minutes depending on the time it takes to call each of the preceeding services.
I'm not bringing this up to be a pain in the ass. I really want to understand OSGi and if I'm wrong on this, I'd like to understand why.
|
|
|
Message #253298
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Article: The Whiteboard Pattern for OSGi
I don't know how to take the lack of response on this. Am I so wrong that no one can bring themselves to point it out or something?
|
|
|
Message #253322
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Article: The Whiteboard Pattern for OSGi
I don't know how to take the lack of response on this. Am I so wrong that no one can bring themselves to point it out or something? *I* just don't have a good answer for you. OSGi is *supposed* to have fewer problems with synchronization, but I haven't run into the problem you talk about - that doesn't mean it doesn't exist, it just means I have no answer for you.
I'm tempted to say "YAGNI" but I have no real reason to say that. I don't know.
|
|
|
Message #253379
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Article: The Whiteboard Pattern for OSGi
dumb question: Where can I get a jar containing ServiceTracker? Depends on the OSGi container you use. For Equinox, it's in org.eclipse.osgi_3.3.2.R33x_v20080105.jar - or similar, depending on the specific Equinox release you have.
So there's no standard jar for this? That seems weird.
ServiceTracker is part of OSGi Compendium jar and is defined in the compendium specs. As is quite central to osgi development most framework implementations include it in the system bundle so practically you can rely on importing it without installing any other additional bundle (jar).
Alin Dreghiciu
|
|
|
Message #264596
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Will the real whiteboard pattern stand up?
The article says,
Basically, the whiteboard pattern is this: a content provider registers itself into the OSGi service registry. A content consumer regularly polls the registry for consumers of the content provider type, and then calls each one in turn. That's fairly simple, but let's show some code to make it obvious, through two examples: one to illustrate the pattern itself, and another to build on our IRC bot example from the first tutorial, by adding a command system where new commands can be installed as OSGi bundles at runtime.
but the Whiteboard white paper defines it as,
Instead of having event listeners track event sources and then register themselves with the event source, the whiteboard pattern has event listeners register themselves as a service with the OSGi framework. When the event source has an event object to deliver, the event source calls all event listeners in the service registry.
Remarkably, the event source is not registered with the framework as a service....
Oddly, the code in both the white paper and the article match the article's version.
|
|
|
Message #266306
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
So the Whiteboard pattern differs from the Observer Pattern how?
Hi,
Unless I have missed something? This looks likes the Observer pattern e.g. java.util.Timer. So I could start a timmer that runs every 15 secs and calls all TimerTask to display things every 15 secs.
What is supposed to be new?
Ben.
|
|
|
| New content on TheServerSide.comNew content on TheServerSide.comNew content on TheServerSide.com |
|
|
Reza Rahman continues to explore the features of the proposed JSR 299, Contexts and Dependency Injection for Java EE (CDI). When approved, it promises to be a key feature of Java EE 6.
(January 21, Article)
Ted Neward is an independent consultant specializing in high-scale enterprise systems, and an authority in Java and .NET technologies. He is the author and co-author of several books, including Effective Enterprise Java. At TheServerSide Java Symposium in March, he will be presenting sessions on pragmatic architecture, ECMAScript and Scala.
(January 15, Article)
Now that Oracle is absorbing Sun Microsystems, there mixed views on what should come of the Java Community Process (JCP). While some say Oracle should become the new steward of Java and keep the JCP much as it was, others argue that it may be time to open-source this widespread language.
(November 24, Article)
Reza Rahman explores the features of the proposed JSR 299, Contexts and Dependency Injection for Java EE (CDI). When approved, it promises to be a key feature of Java EE 6.
(November 2, Article)
SAML is an XML-based standard for exchanging authentication and authorization data between security domains. The single most important problem that SAML was created to solve is the Web browser Single Sign-On problem. Many organizations are debating whether to stay with version 1.1 or move to 2.0. This article makes observations about both options.
(September 28, Article)
Joe Ottinger takes a look at how people learn, and applies it to the practice of programming. He notes that understanding how people learn is an essential part of working in a programming team.
(September 22, Article)
Stephen Maryka gave us an article about the Asynchronous Web and posed a number of questions that get examined like an approach to delivering Asynchronous Web capabilities through extensions to existing Java EE technologies.
(July 14, Article)
JavaServer Faces Flex goal is to provide users capability in creating standard Flex components, part of flexSDK which is open sourced through MPL license, as normal JSF components. This article by Ji Hoon Kim will provide an overview of creating a simple multilingual JSF page consisting of JSF Flex tags.
(June 29, Article)
In this session Jeff explores the key characteristics of successful SOA projects. He covers some of the patterns, and anti-patterns, tool sets, and strategies that he himself learned the hard way. Last, he provides a strategy and blueprint for achieving a high likelihood of success in your SOA project.
(June 23, Tech Talk)
Ari Zilka, CTO of Terracotta, Inc., talks about the new features in Terracotta 3.1, announced during JavaOne and available now.
(June 15, Tech Talk)
In this Tech Talk, Josh Long explores an integration challenge using Spring Integration and walks through the implementation, employing and expanding on the basic patterns of Enterprise Application Integration to tie together components into a function integration solution, and then demonstrates how Spring Integration helps address the integration requirements.
(June 15, Tech Talk)
In this Tech Talk, David Geary teaches you: The basics of Google Web Toolkit; How to implement Ajax-enabled applications in Java; Internationalization; Hooking into the browser history mechanism; Remote procedure calls.
(June 4, Tech Talk)
Jon Kern discusses the best architecture/technical solutions and ensure that they are repeated by all developers. By tackling the architecture up-front in a serial manner, subsequent parallel development will be much more manageable and predictable.
(May 28, Tech Talk)
This keynote describes the frustrations of modern knowledge workers in their quest to actually get some work done, and solutions for how to guard yourself against all those distractions. Neal Ford talks about environments, coding, acceleration, automation, and avoiding repetition as ways to defeat the misguided attempts to sap your ability to produce good work.
(May 26, Tech Talk)
Gil demonstrates how new, aggressive uses of already abundant compute capacity by common applications offer competitive value for application designers.
(May 21, Tech Talk)
Chris Keene introduces WaveMaker as a new way to automate the ability to generate Hibernate classes in order to more quickly bring OR mapping into an application.
(May 19, Article)
Mastering EJB was one of the original and most influential EJB books in the industry. Mastering EJB III now returns with two new expert co-authors, updated for EJB 2.1 and 30% new chapters including security, integration, best practices, open source, and more.
(Book PDF Download)
The Application Server Matrix is a detailed listing of J2EE vendors and their application server products, with information on latest version numbers, J2EE spec support and licensing, pricing, platform support, and links to product downloads and reviews.
(Application Server Comparison Matrix)
|
|
