When is 'optional' really optional? - Tim Ward

Copyright © 2005 - 2013 Paremus Ltd.May not be reproduced by any means without express permission. All rights reserved.

When is ‘optional’ really optional? Oct 2013

When is ‘optional’ really optional?

Tim Ward http://[email protected]

Tuesday, 29 October 13

http://www.paremus.com




•Senior Consulting Engineer and Architect at Paremus

• 5 years at IBM developing WebSphere Application Server• Container Implementation experience with Java EE and OSGi, including Blueprint, JPA, EJB

and JTA

•OSGi Specification lead for JPA and Bytecode Weaving

•PMC member of the Apache Aries project

•Previous speaker at EclipseCon, Devoxx, Jazoon, JAX London, OSGi Community Event...

•Author of Manning’s Enterprise OSGi in Action

• http://www.manning.com/cummins

Who is Tim Ward?@TimothyWard


http://www.manning.com/cummins




Optional Services




Optional Services

•OSGi bundles communicate and collaborate using loosely coupled services

•Making a service dependency “optional” is pretty easyOSGi API

ServiceReference<Foo> ref = ctx.getServiceReference(Foo.class);

if(ref != null) {Foo service = ctx.getService(ref);if(service != null) {

try {...

} finally {ctx.ungetService(ref);

}}

}

Declarative Services API

private Foo fooService;

@Reference(cardinality = OPTIONAL)public synchronized void setFoo(Foo service) {

fooService = service;}

public synchronized void unsetFoo(Foo service) {fooService = (fooService == service) ? null :

service;}




Difficulties with Optional Services

• The OSGi API and DS need null checks, which is messy

•Blueprint injects a proxy to the service - No more nulls!

Blueprint code

private Foo fooService;

public void setFoo(Foo service) {fooService = service;

}

Blueprint XML

<blueprint>

<reference interface=com.paremus.Fooid=”foo” availability=”optional”/>

<bean id=”bar” class=”com.paremus.Bar><property name=”foo” ref=”foo”>

</bean>

</blueprint>




Blueprint is the winner! Or is it?





•At first inspection Blueprint looks much simpler






•But what happens when there is no backing service?







•Calling an unbound blueprint service proxy blocks up to the “timeout”. If no service arrives then you get a ServiceUnavailableException








• The default timeout is 5 minutes!!!









•You can decrease the timeout (but not to zero)










•You can use a ReferenceListener (this is horrible code, and risks deadlock)










•You can use a ReferenceListener (this is horrible code, and risks deadlock)

•You can inject a ReferenceList (like DS, but with the wrong cardinality)




Blueprint 1.1 to the rescue





•Despite aiming to be “simple” Blueprint 1.0 sucked at optionality...






•Blueprint 1.1 proposes several fixes:







•Allow users to have an immediate timeout (no service, no waiting)








•Still have to cope with a ServiceUnavailableException









•Allow users to specify a “default” service implementation










• This can be a nice way to avoid branches in your code











•Allows users to use a “null proxy” as the default implementation











•Allows users to use a “null proxy” as the default implementation

•Avoids making you an API provider




Is Service Optionality really ‘optional’





• The optionality so far has made an implicit assumption






• The API was not optional!







•OSGi does a great job of managing dependencies








•Automatic dependency provisioning









•Prevent resolution unless dependencies are satisfied









•Prevent resolution unless dependencies are satisfied

•Optional dependencies don’t have the same guarantees!




Optional Packages




Handling Package Optionality





•Having optional package imports makes OSGi more like a normal classpath






•You need to be defensive - ClassNotFoundException could happen!







•Unusually for OSGi the factory pattern can be helpful








•Select the implementation with or without the dependency as appropriate









•Blueprint can use factories to create managed beans









•Blueprint can use factories to create managed beans

• It can be useful to isolate dependent code in a handler class




Handling Package Optionality (2)





•Optional packages can be very hard to manage






•Having multiple optional dependencies can explode complexity







• Effectively you’re back to the complexity of a Java Classpath!








•Possible approaches to consider:









•Don’t make the API optional, have two bundles, one with the dependency and the other one without










• If all you care about is ease of use then repackage the API










• If all you care about is ease of use then repackage the API

•Keep a careful internal dependency structure




• For more about OSGi...

•Specifications at http://www.osgi.org

• Enterprise OSGi in Action

• http://www.manning.com/cummins

Questions?

Thanks!

http://[email protected]


http://www.osgi.org

http://www.osgi.org





Date post:	16-May-2015
Category:	Technology
Upload:	mfrancis
View:	365 times
Download:	3 times

When is 'optional' really optional? - Tim Ward

Technology