PojoSR or OSGi (µ)Services For the Rest of Us

2,402 views

Published on

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
2,402
On SlideShare
0
From Embeds
0
Number of Embeds
417
Actions
Shares
0
Downloads
23
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

PojoSR or OSGi (µ)Services For the Rest of Us

  1. 1. PojoSR or
(OSGi)
µServices
for
the
rest
of
us Karl
Pauls !"#$%&&()"*Dienstag, 25. Oktober 2011
  2. 2. Karl • Member
Apache
So?ware
FoundaDon • PMC:
Felix,
Sling,
Incubator • PPMC:
Ace,
Clerezza,
Celix • Fellow
at
Luminis Hall et al. C re at in g M od ul ar A pp lic at io ns in J av a • Project
Owner
PojoSR O SGi IN ACTION • Co‐Author
of
„OSGi
in
AcDon“ Richard S. Hall Karl Pauls Stuart McCulloch David Savage • karl.pauls@luminis.eu FORE WORD BY PETE R KRIENS (a.k.a.
karlpauls@gmail.com) MANNINGDienstag, 25. Oktober 2011
  3. 3. Service
OrientaDonDienstag, 25. Oktober 2011
  4. 4. PromoDng
a
service‐oriented
interacDon
paSern !"#$%&" +"0%./#1 2-34%.5 86* !"#$%&" %6/"#7&/ !"#$%&" (#)$%*"# +",-"./"#Dienstag, 25. Oktober 2011
  5. 5. µServicesDienstag, 25. Oktober 2011
  6. 6. µServices • Interface‐based
programming,
but
more • Service
Registry • Centrally
accessible • Browsable • NoDficaDons • Service
Registry
Benefits • Consuming
code
is
in
control
of
provider
selecDon • But
not
provider
instanDaDon
and
configuraDon • Provider
code
is
in
control
of
when
to
provide • Promotes
very
loose
coupling
and
late
bindingDienstag, 25. Oktober 2011
  7. 7. OSGi
(µ)Services
Dienstag, 25. Oktober 2011
  8. 8. OSGi
services • OSGi
framework
provides
the
concepts
we
 need • Centralized
service
registry • Consumer
has
control
over
selecDon • Provider
has
control
over
when
to
provide • Plus
full‐blown
deployment
and
packaging
modularity
 with
run‐Dme
dynamismDienstag, 25. Oktober 2011
  9. 9. OSGiDienstag, 25. Oktober 2011
  10. 10. OSGi • The
downside
to
OSGi
is
that
it
requires
a
 boSom‐up
commitment • You
need
to
convert
all
of
your
code
into
 proper
modules
to
take
advantage
of
services • A
top‐down
approach
of
adopDng
services
 can
help
ease
migraDon
to
more
modular
 codeDienstag, 25. Oktober 2011
  11. 11. OSGi
frameworkDienstag, 25. Oktober 2011
  12. 12. PojoSR
Dienstag, 25. Oktober 2011
  13. 13. What
is
PojoSR? • It
largely
removes
the
modularity
layer
from
the
 OSGi
framework • Provides • A
centralized
service
registry
based
on
OSGi
 API • Lifecycle
hooks
for
JAR
files • A
“light”
OSGi
framework
for
the
class
pathDienstag, 25. Oktober 2011
  14. 14. Why
this
approach? • OSGi
API
is
a
standard
with
years
of
experience
 behind
it • Can
re‐use
OSGi
modules
(a.k.a.
bundles)
and/or
 technology • Can
leverage
services
without
having
to
 completely
modularize
first
(i.e.,
top‐down) • Provides
a
path
to
full‐blown
modularityDienstag, 25. Oktober 2011
  15. 15. Use
CasesDienstag, 25. Oktober 2011
  16. 16. MigraDonDienstag, 25. Oktober 2011
  17. 17. MigraDon • Without
PojoSR • Turn
applicaDon
into
one
big
bundle
(jar) • Split
into
several
bundles
 • Fix
problems • Split
into
even
more
bundles
(etc.) • Eventually,
start
using
services
 • Allows
you
to
remove
ugly
hacks
needed
to
fix
problems • With
PojoSR • Start
using
services • Split
into
bundles
Dienstag, 25. Oktober 2011
  18. 18. Use
OSGi
where
you
can‘t • OSGi
(lite)
on
Google
App
Engine
using
PojoSRDienstag, 25. Oktober 2011
  19. 19. Use
OSGi
where
you
can‘t • hSp://vimeo.com/22571224Dienstag, 25. Oktober 2011
  20. 20. AndroidDienstag, 25. Oktober 2011
  21. 21. Common
discovery
(SPI)Dienstag, 25. Oktober 2011
  22. 22. Common
discovery
(SPI)Dienstag, 25. Oktober 2011
  23. 23. Services
and
dependency
injecDon • Advantages
when
combined
with
service
 orientaDon • Dependency
injecDon
no
longer
needs
global
view • InformaDon
localized
to
just
the
provider/consumer • No
longer
restricted
to
a
single
DI
framework • Different
DI
frameworks
can
play
together
via
the
service
 registryDienstag, 25. Oktober 2011
  24. 24. UsageDienstag, 25. Oktober 2011
  25. 25. As
a
Service
RegistryDienstag, 25. Oktober 2011
  26. 26. As
an
OSGi
„light“
frameworkDienstag, 25. Oktober 2011
  27. 27. StandaloneDienstag, 25. Oktober 2011
  28. 28. DemoDienstag, 25. Oktober 2011
  29. 29. Closing
RemarksDienstag, 25. Oktober 2011
  30. 30. Benefits
and
Drawbacks • PojoSR
provides
part
of
the
power
of
OSGi
 • in
a
non‐intrusive
way. • allows
to
increase
modularity
and
use
µServices • without
first
ridding
an
exisDng
code
base
of
class
loader
hacks • Can
run
OSGi
bundles
where
you
can‘t • The
drawbacks
are • does
not
enforces
module
boundaries • does
not
allow
mulDple
versions
of
the
same
package;
does
not
 support
the
Bundle‐ClassPath.
 • But
you
can
use
the
µService
model
to
get
rid
of
the
class
loading
 hacks
over
Dme,
a?er
which
it
will
be
easier
to
move
to
OSGi
and
get
 side
by
side
versioning
and
real
module
boundaries.Dienstag, 25. Oktober 2011
  31. 31. QuesDons? http://pojosr.googlecode.comDienstag, 25. Oktober 2011

×