• Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
1,590
On Slideshare
0
From Embeds
0
Number of Embeds
21

Actions

Shares
Downloads
20
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. PojoSR or
(OSGi)
µServices
for
the
rest
of
us Karl
Pauls !"#$%&&()"*Dienstag, 25. Oktober 2011
  • 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. Service
OrientaDonDienstag, 25. Oktober 2011
  • 4. PromoDng
a
service‐oriented
interacDon
paSern !"#$%&" +"0%./#1 2-34%.5 86* !"#$%&" %6/"#7&/ !"#$%&" (#)$%*"# +",-"./"#Dienstag, 25. Oktober 2011
  • 5. µServicesDienstag, 25. Oktober 2011
  • 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. OSGi
(µ)Services
Dienstag, 25. Oktober 2011
  • 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. OSGiDienstag, 25. Oktober 2011
  • 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. OSGi
frameworkDienstag, 25. Oktober 2011
  • 12. PojoSR
Dienstag, 25. Oktober 2011
  • 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. 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. Use
CasesDienstag, 25. Oktober 2011
  • 16. MigraDonDienstag, 25. Oktober 2011
  • 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. Use
OSGi
where
you
can‘t • OSGi
(lite)
on
Google
App
Engine
using
PojoSRDienstag, 25. Oktober 2011
  • 19. Use
OSGi
where
you
can‘t • hSp://vimeo.com/22571224Dienstag, 25. Oktober 2011
  • 20. AndroidDienstag, 25. Oktober 2011
  • 21. Common
discovery
(SPI)Dienstag, 25. Oktober 2011
  • 22. Common
discovery
(SPI)Dienstag, 25. Oktober 2011
  • 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. UsageDienstag, 25. Oktober 2011
  • 25. As
a
Service
RegistryDienstag, 25. Oktober 2011
  • 26. As
an
OSGi
„light“
frameworkDienstag, 25. Oktober 2011
  • 27. StandaloneDienstag, 25. Oktober 2011
  • 28. DemoDienstag, 25. Oktober 2011
  • 29. Closing
RemarksDienstag, 25. Oktober 2011
  • 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. QuesDons? http://pojosr.googlecode.comDienstag, 25. Oktober 2011