►
From YouTube: Jakarta Tech Talks - JMS 2.0 & Jakarta Messaging 3.0
Description
Jakarta Messaging 3.0 provides a standard set of messaging concepts and interfaces enabling Java developers design and build loosely coupled with a single - yet powerful - API. In this session, Graham and Richard will show how a developer can get up and running quickly with a Jakarta Messaging 3.0 developer runtime environment - using OpenLiberty and IBM MQ - and get hands on with a sample code. Once up and running, the presenters will explore the environment's key features: demonstrate how Jakarta 3.0 applications can interoperate with JMS 2.0 services using IBM MQ as a common messaging provider and as a basis to migrate applications to the new standard.
A
Hello,
everyone
and
welcome
to
another
Jakarta
Tech
talk.
My
name
is
Serena
and
joining
us
today
is
Richard
copen
and
Graham
Hopkins,
who
will
be
presenting
on
the
topic
of
Jakarta
Tech
talk,
JMS,
2.0
and
Jakarta
messaging
3.0.
If
you
have
any
questions
for
Richard
or
Graham
as
we
move
through,
today's
presentation
feel
free
to
ask
them
in
the
chat
or
in
the
ask
a
questions
tab
without
any
further
delay
over
to
you
guys.
B
Good
morning,
thank
you,
everyone
for
taking
the
time
to
join
and
apologies
for
the
slightly
late
start.
We
had
a
few
little
technical
problems
that
I
eventually
overcame
heroically.
So
a
lot
of
pleased
with
that
to
say
good
morning,
my
name's
Richard
cobbin
I
work
in
ibmq
and
I
lead
the
developer,
experience
and
efforts
in
the
development
organization
here
in
hursley
I'm
joined
this
morning
by
Graham.
B
Nothing
thank
you.
So
what
we
want
to
do
this
morning
was
talk
you
through
some
jms2
and
Jakarta
messaging.
Three
material
talk
about
messaging,
quite
generally.
Actually,
whilst
we
offer
IBM
and
we'll
be
using
some
IBM
Technologies
to
show
you
messaging
and
action,
a
lot
of
presentation
today
is
really
focused
around
the
JMS
and
Jakarta
from
SG3
specification
of
apis.
B
B
First
of
all,
I
just
wanted
to
say
a
huge
thanks,
really
appreciate
you
investing
time
in
us
today
and
that's
really
appreciated,
and-
and
thank
you
for
doing
it.
If
there's
something
today,
you
think
hey
I
need
to
hear
more
about
that
or
less
about
something.
Then
please
send
me
an
email
right.
It's
really
great
to
have
a
conversation.
It
helps
us
get
better,
so
yeah
just
so
much.
Thank
you
for
your
time,
really
do
appreciate
it
and
don't
be
afraid
to
make
contact
emails
on
the
screen
just
there.
B
B
So,
let's
start
at
the
beginning,
let's
get
stuck
in
so
messaging
Basics.
What's
the
big
deal,
why
do
we
need
messaging?
And
quite
often,
when
we
talk
to
those
joining
the
industry,
maybe
joining
us
as
graduates
or
in
University
settings
messaging
is
really
kind
of
compacted
down
into
your
experiences.
We
have
with
our
mobile
phones
in
day-to-day
life
and
when
we
say
nesting,
it's
often
synonymous
with
WhatsApp
or
Twitter,
or
something
that
folks
can
touch
on
there
on
the
handset.
And
when
we
talk
about
Enterprise
messaging,
it's
much
more
than
that.
B
If
I
send
an
iMessage,
you
know
that's
kind
of
in
an
ecosystem.
That's
that's
on
its
own!
It's
in
an
island
right!
What?
If
I
need
to
be
able
to
do
a
style
of
messaging
that
ink
to
connects
the
world,
something
that
can
go
across
different
compute,
Services,
different
architectures,
different
programming
languages,
different
apis
and
perhaps
start
to
connect
things
together
that
otherwise,
you
wouldn't
imagine
being
connected
together
now.
What
if
I
need
to
connect
my
washing
machine
into
my
laptop?
What,
if
I
need
to
connect
my
bank
to
my
transport
facility?
B
Those
kind
of
things
and
those
environments
have
different
heritages,
have
different
about
compute
environments
within
them
and
they
work
in
very
different
ways.
But
Enterprise
messaging
is
about
having
a
framework
about
having
a
layer
that
interconnects
those
worlds
that
we
can
do
really
quite
sophisticated
things
and
change
lives.
B
So
the
way
I
like
to
think
of
it
is
that
messaging
is
the
wiring
that
glues
together.
Our
businesses
leads
together
our
society
glues
together
the
world
right.
It
enables
us
to
pull
functions
together
and
really
achieve
something
where
the
the
sum
is
is
much
greater
than
the
the
individual
parts
we
think
about
a
typical
business.
B
It's
also
a
big
deal
and
if
we
go
right
back
to
the
beginning,
certainly
of
IBM
mq
and
other
messaging
providers
as
well
is
in
the
early
90s.
We
had
a
lot
of
services,
a
lot
of
applications
deployed
on
quite
large
physical
Hardware.
That's
the
Mainframe
in
this
case.
It's
a
OS
server
here.
So
all
those
services
and
applications
are
doing
really
cool
things,
but
they're
living
in
their
own
environment,
they're
quite
isolated.
B
So
then,
when
we
bring
a
new
application
or
a
new
service
into
the
environment,
we
have
to
then
massage
that
into
the
existing
Communications
framework
that
we
have
so
ibmq
and
another
nesting
Technologies
were
really
designed
to
solve
that
problem,
to
find
a
very
generic,
scalable,
reliable
way
of
connecting
services
and
applications
together
in
a
compute
environment,
so
that
developers
can
focus
on
adding
business
value
and
that
problem
re-emerges
as
the
industry
starts
to
mature
right.
So,
in
the
early
days
of
three-tier
Computing,
we've
now
got
the
same
problem.
B
We
need
to
move
data
between
different
compute
environments
and
we
need
to
solve
that
problem,
so
this
is
a
different
type
of
Plumbing.
This
is
now
an
over
the
network,
communication
and
transportation
problem.
So
messaging
Technologies
evolve
to
start
to
solve
that
problem,
maybe
in
the
early
days
to
overcome
unreliable
networks
to
make
sure
that
data
can
be
moved
securely
and
reliably
between
different
compute
environments,
so
that
work
can
be
done
on
those
elements
of
data.
B
Then
we've
seen
the
industry
shifts
again,
so
more
and
more
architectures
become
available
and
different
organizations
start
to
pick
an
architecture
because
they're
fond
of
it.
They
have
the
right
skills
for
it
within
their
development
organizations
and
again
those
services
that
are
running
in
different
environments
in
different
programming
languages,
running
on
different
CPU
architectures.
They
need
to
talk
to
each
other
so
that
we
can
bring
our
businesses
together
and
be
cohesive
about
data
sharing,
so
messaging
evolves
to
start
to
solve
those
problems.
B
B
So
when
we
look
at
a
product
like
IBM
mq,
we
went
in
a
lot
of
places.
You
can
see
our
heritage
there
and
we've
got
probably
on
the
Mainframe
on
zos,
but
also
across
many
distributed
platforms.
As
you
can
see.
On
the
left
hand
side
there,
we
also
have
dedicated
appliances,
a
piece
of
Hardware
that
you
plug
into
a
rack
and
it
just
does
messaging
for
you.
We
also
have
offerings
on
different
Cloud
environments
and
we're
available
motion
shift.
B
We
have
an
operator,
you
can
employ
issues
and
kubernetes,
so
we
can
get
messaging
to
wherever
you
need
it
to
keep
joining
those
microservices
together.
Those
applications
together
also
in
the
case
of
ibmq,
have
software
as
a
service
offerings
on
IBM
cloud
and
AWS
as
well.
So
why
do
you
need
messaging?
So
that's
sort
of
drill
down
into
another
little
bit,
and
quite
often,
when
we
speak
to
new
audiences,
the
messaging
problem
might
start
off
as
something
that's
relatively
small.
B
So
if
you
think
about
a
university
project,
I
might
have
just
one
or
two
applications
that
I
need
to
connect
together
and
there's
ways
of
doing
that
with
with
technologies
that
are
very
easy
to
understand
and
work
with
like
rest
right,
I
can
just
open
the
port
and
I
can
connect
to
another
application.
That
I
can
share
some
data.
B
The
problem
with
that,
as
as
our
application
landscape
starts
to
build
up
as
a
developer
I'm
now
having
to
solve
that
connectivity
problem
between
lots
of
applications
so
again
starting
to
have
to
write
code,
that's
moving
more
and
more
away
from
my
business
value,
but
also
having
to
solve
problems
about
if
two
applications
are
dependent
on
each
other
and
they
have
an
asynchronous
link.
That
relationship
is
quite
brutal.
So
if
one
of
the
applications
goes
down,
the
other
applications
may
become
best,
responsive
or
less
useful
until
the
entire
estate
is
back
up.
So.
B
For
here
is
something
that's
a
little
bit
more
Loosely
coupled
but,
most
importantly
as
a
developer,
we
want
you
to
focus
on
the
business
value.
The
thing
that
you're
getting
paid
money
to
go
do
to
add
value
to
your
business.
We
want
you
to
focus
on
that.
So
we
see
messaging.
Technologies,
therefore
solve
the
slightly
more
prickly
problems
that
we've
outlined
just
here:
reliable
communication
security
transactionality,
which
we'll
talk
about
in
just
a
second,
when
my
data
is
at
rest
and
an
application
hasn't
consumed
it.
B
Yet
I
want
a
data,
be
reliably
persistent,
so
I
can
come
and
get
it
later
on.
As
our
businesses
and
solutions
grow,
the
messaging
layer
needs
to
scale.
Quite
often,
let
me
vast
scale
so
that
we
can
run
a
global
Enterprise
and
should
something
go
wrong?
Should
we
lose
a
data
center
or
a
system?
We
need
the
messaging
layer
to
be
recoverable,
so
their
applications
are
not
just
waiting
for
the
messaging
service
to
come
up.
They
can
recover
and
carry
on
doing
business
until
the
problem
is
fully
resolved.
B
So
what
does
a
messing
solution?
Look
like
how
does
it
add
value
to
us
as
developers
and
overcomes
all
those
sort
of
brittle
problems
that
we've
just
explored
and
the
most
important
concept
I'm
going
to
pull
out
today?
Is
someone
called
the
queue
right?
A
queue
is
a
really
nice
way
to
decouple
two
applications:
they're
no
longer
synchronously
bound.
They
just
need
to
know
about
a
queue
where
to
put
data
and
where
to
get
it,
and
that
gives
us
a
really
nice
loose
coupling
right.
B
So
if
we
can
make
the
queue
available,
the
applications
can
come
and
go.
They
can
put
the
data
on
the
Queue
when
they
need
to
and
other
applications
can
come
along
and
get
data
off
the
queue
when
they
need
to
to
scale
up.
The
only
information
I
need
to
share
with
my
applications
is
the
information
about
the
queue
right.
I.
Don't
need
to
share
information
about
the
other
application.
I,
don't
need
to
know
anything
about
each
other.
B
B
The
really
nice
thing
about
point
is
we
can
scale
things
up
so
if
we're
dealing
with
a
an
event,
maybe
a
busy
shopping
event,
but
there's
Furious
activity
on
the
buy
now
button.
We
want
our
front
end
to
be
nice
and
responsive,
so
we
can
take
orders
from
that
front
end.
We
can
cue
them
and
then
our
dispatch
and
order
processing
systems
might
not
be
able
to
run
really
really
fast,
but
they
can
run
quite
fast,
perhaps
over
a
longer
period
of
time.
B
So
we
can
scale
up
our
consumers
and
they
can
pull
messages
off
the
queue
and
fulfill
the
orders.
But
the
fact
that
they're
running
slightly
slower
is
okay,
because
the
queue
will
just
fill
up
and
it
will
soak
up
some
of
that
load
and
as
the
consumers
catch
up
and
produces
the
the
depth
of
the
queue
will
then
start
to
to
to
drop
back
to
zero.
It's
a
really
nice
way
of
scaling
out
applications
just
by
creating
more
instances
of
them
where
those
instances
know
about
which
queue
to
put
two
and
to
get
from.
B
The
pattern
that
we
just
looked
at
sort
of
classic
point
to
point
is
quite
I,
guess
a
passive,
certainly
not
passive.
It's
much
more
sort
of
my
application
is
knowingly
gonna
have
to
do
a
put
or
a
get
one
pattern.
That's
really
nice
is
something
called
a
listener
where
we
can
produce
messages,
but
the
queuing
system
pings
any
listeners
that
are
registered
for
that
queue
to
say,
hey,
there's
a
message
here
and
delivers
the
message
to
the
application:
that's
got
its
list
and
registers.
This
is
a
bit
like
a
callback
and
great.
B
C
So
outside
you've
had
this
Standalone
message
list
the
type
of
stuff
they
should
move
into.
More
of
the
managed
environments,
yes,
you're,
taking
to
the
NDB
of
the
message
stream
being
a
type
of
environment
where
you
just
write
something
that
handles
message,
logic
rather
than
have
to
say,
I'm,
going
to
go
and
try
to
get
these
messages.
The
messages
are
just
handed
available.
B
Another
common
pattern
is
probably
subscribe,
so
this
is
where
we
have
a
producing
application.
That
is
putting
data
onto
the
topic
and
subscribers
come
along.
They
don't
need
to
know
anything
about
the
producers.
They
just
register
an
interest
in
the
topic
itself.
This
is
a
classic
pattern.
You
see
on
platforms
like
Twitter
right
here
we
have
the
frictional
hursley
airport
and
our
consumers
are
interested
in
flight
information,
update
information
from
hersley
airport.
They
come
along.
They
subscribe
as
soon
as
there's
information
around
the
the
flight
details
that
we
need
to
share
to
our
subscribers.
A
B
B
In
the
previous
example,
there's
only
ever
one
copy
of
the
message
on
the
queue
a
consumer
will
get
one
copy
as
soon
as
it's
been
consumed,
there's
no
more
copies
available
for
consumers
to
receive
until
the
producer
creates
another
one.
In
this
pattern,
one
produce
can
fan
out
to
multiple
machines.
The
copy
of
the
message
is
delivered
to
all
consumers,
all
subscribers
that
are
actively
subscribed
at
that
point
in
which
the
publication
was
made.
So
more
than
one
to
many.
B
Okay,
now
we've
kind
of
got
our
basic
building
blocks
of
cues
and
topics
as
you'll
see
in
a
minute.
There's
other
attributes
of
a
message
that
allow
us
to
do
much
more
sophisticated
things,
and
this
is
a
really
kind
of
cool
thing.
As
a
developer,
in
that
we
can
start
to
model
some
of
our
solution
Behavior
into
the
messaging
system
itself.
B
This
particular
pattern
is
called
request.
Response,
I'll
walk
through
this
and
I'm
happy
to
take
questions
on
the
way.
The
idea
here
is
I
call
into
my
messaging
layer
and
first
thing:
I
do
is
I,
create
a
reply
to
destination,
which
is
often
a
temporary
queue
and
I'm
going
to
take
that
cue
from
the
message
name,
I'm
going
to
say
right,
I
want
all
replies
to
my
request
to
come
onto
this
queue.
So
the
first
thing
I
do
is
create
a
report
EQ
and
I.
Just
keep
that
in
my
code.
B
I
then,
on
that
message,
I
assign
a
property
called
a
reply
to
destination
I
say
if
you're
interested
send
a
reply
on
this
queue,
because
I'm
going
to
be
waiting
for
your
reply
once
I've
injected
the
message,
it
sits
on
the
request,
queue
and
then
Graham
might
come
along
with
his
response.
Application
consume
that
message.
B
Take
a
little
look
at
it
and
say
the
way
I
talk
to
Richard
is
I
ping,
him
a
message
on
this
reply
to
destination
and
then
Graham
Construction
reply
either
yes
or
no
he's
going
to
accept
my
generous
offer
on
his
house,
and
he
sends
that
message
to
my
reply.
Queue
once
I've
consumed
that
the
request
response
operation
is
over.
B
So
we've
had
a
we've,
had
a
conversation
between
two
applications
that
don't
know
anything
about
each
other
other
than
the
cues
that
they're
going
to
have
a
conversation
over
and
we're
using
the
properties
of
the
message
to
pack
additional
information
about
how
that
conversation
should
play
out,
and
we
can
do
other
things
such
as
set
a
time
to
live
on
the
request
message
so
that
it
might
only
live
for
five
seconds.
So
Graham
running
has
a
very
small
window
of
opportunity
to
accept
my
generous
offer.
Otherwise
the
messaging
layer
will
delete
the
message.
B
B
B
They
might
have
a
message
ID
on
it,
some
kind
of
unique
identifier,
so
that
I
can
YouTube
and
those
kind
of
things
if
I
would
need
to
there's
also
fields
in
messages
often
referred
to
as
properties
that
allow
us
to
set
certain
context
for
our
message.
So
if
my
payload
just
said,
50
I
might
not
know
which
unit
of
currency,
that's
in
and
I
might
therefore
use
a
property
to
to
fix
the
the
unit
of
currencies.
That
I
can
I
can
then
say,
are
50
euros
50.
So
the
message
payload
might
be
very
simple.
B
Okay,
so
messages
are
only
useful
if
you've
got
somewhere
to
put
them.
We
spoke
about
cues
a
moment
ago
in
in
this
particular
case.
Here
we
have
a
set
of
messages,
just
sat
on
a
queue
there's
many
of
them
and
they
are
typically
consumed
in
a
first
in
the
first
out
order,
certain
characteristics
and
properties
of
the
message:
May
change
the
order
in
which
they
consume.
B
B
And
you'll
get
to
see
one
in
just
a
second,
but
long
short
of
the
queue
manager
or
a
messaging
server
is
the
piece
of
technology
that
looks
after
cues
and
topics
and
manages
subscriptions
and
delivers
messages
that
kind
of
thing
and
finding
applications.
This
is
where,
as
a
developer,
you
add
your
business
logic.
You
bind
that
with
a
little
bit
of
client
code
from
your
messaging
vendor,
the
union
of
your
code
and
that
client
layer
allow
you
to
collect
the
queues
and
exchange
data.
B
And
the
reason
for
all
this
is
to
create
that
nice,
Loosely,
coupled
relationship
between
our
services,
that
they're
not
greatly
dependent
on
each
other,
we
often
refer
to
asynchronous
messaging,
is
providing
a
shock
absorber.
So
that
means
that
if
there's
a
flood
of
work
comes
into
the
system
we
can
put
onto
the
cues,
the
cues
will
soak
it
up
and
then
our
different
I.T
systems,
our
different
Services,
can
run
at
different
speeds
and
the
queue
is
what
allows
them
to
just
take
up
load
and
build
a
load
over
periods
of
time.
B
B
B
To
bring
in
is
when
we
talk
about
message
queuing,
that's
a
destructive
operation.
When
we
take
the
message
off
the
queue
it
is
ours,
sometimes
that
behavior
isn't
ideal,
because
we
might
have
to
do
work
on
the
message
once
we've
consumed
it
and
should
that
set
of
operations
fail,
we
wouldn't
like
to
have
consumed
the
operations.
I've
consumed
the
message.
So
if
I
was
booking
a
airline
seat,
I
might
take
that
request,
try
and
sort
out
payment.
B
Maybe
I
might
need
to
do
some
work
with
services
from
government
agencies
to
ensure
the
C
can
be
booked.
Those
kind
of
things
if
any
of
those
other
down
down
the
chain
operations
were
to
fail.
It's
desirable
to
be
able
to
put
the
message
back
on
the
Queue
so
that
we
can
retry
it.
That's
often
referred
to
as
a
transaction
and
a
rollback
taking
a
message
under
a
scope
of
work
and
being
able
to
roll
it
action.
B
Something
go
wrong
and
the
scenario
here
being
baseball
in
that
we
only
score
a
run
if
we
get
around
all
of
the
plates.
If
we
do
all
of
the
things
that
we
need
to
do,
it's
only,
then
we
score
a
run.
Otherwise
we
have
to
go
back
to
the
start
and
try
again.
This
is
something
that
Sony
ibmq
does
very
efficiently
and
very,
very
well
transactions.
Sometimes
just
some
people
feel
a
little
bit
nervous.
It
feels
expensive,
but
actually
for
many
messaging
vendors.
B
So
once
we've
done
all
that
stuff,
let's
maybe
just
take
a
moment
to
have
a
think
about
what
we've
got
and
as
you'll
see
in
a
moment
we're
going
to
start
something
up
called
a
queue
manager.
That's
going
to
give
us
connectivity
to
the
outside
world
to
allow
us
to
do
some
messaging
work
to
give
access
to
cues
and
topics
in
the
case
of
ibmq.
B
We
also
have
a
console
that
allows
you
to
make
configuration,
changes
and
work
with
the
with
the
server
and
we
have
a
layer
of
persistence,
which
is
where
messages
are
stored
until
they're
consumed
from
the
queue
so
that
we
can
recover
from
server
restarts
that
kind
of
thing
and
better
than
just
those
key
managers
being
Singleton
objects.
It's
possible
to
chain
them
together
to
form
larger
networks
so
that
we
can
do
reading
between
different
Keys.
B
Also
for
reasons
availability
like
many
messaging
vendors,
such
as
our
dnaq
support
clustering,
so
that
we
can
put
more
power
into
the
system
and
be
more
thought
tolerant,
make
sure
our
keys
are
always
available
for
our
consumers
and
should
something
go
wrong
with
any
of
the
individual
servers.
Great
anything
to
add
on
on
those.
C
B
Okay,
so
that's
all
the
kind
of
background
or
the
Preamble
for
messaging.
So
hopefully
that's
that's
just
build
some
gaps,
and
you
know
you've
reminded
many
of
my
messaging
is
important
for
those
that
are
new
to
this
this
world
and
giving
you
a
grounding.
So
let's
have
a
little
talk
about
JMS,
which
is
one
of
the
reasons
we're
here:
I'm
going
to
hand
over
to
Greg,
okay,.
C
Okay,
so
yes,
a
switch
has
gone
through
reasons
why
you
might
want
to
use
messaging.
How
do
you
use
message,
though?
There's
a
different
messaging
providers
will
provide
lots
of
different
ways
of
talking
to
them
if
you're
talking
to
mq,
which
has
been
around
for
quite
a
long
time,
now,
there's
lots
of
different
ways
you
could
choose
to
do
that.
C
C
What
is
it?
Well,
it's
an
API
specification.
It's
not
a
programming
language!
It's
on
right!
It's
not
a
provider!
It's
not
something
you
can
just
do
you
have
to
have
someone
who
implements
it.
So
there
are
numerous
JMS
providers
who
will
implement
this
specific
specification.
It
could
be
empty,
but
you'll
find
any
Java
re
provider
or
Jakarta.
You
need
provider
now
will
provide
a
JMS
implementation
or
knowledge
require
semester
in
communication.
A
C
C
How
does
it
fit
into
that?
Well,
it's
available
in
both
specs
now,
so
it's
something
that
can
be
run
in
a
very
lightweight
environments
and
much
more
likely
than
even
javery
environments.
You
can
still
run
in
command
line
environment.
It
is
also
supported
in
and
at
a
certain
point
in
time,
a
number
of
years
ago
became
a
requirement
for
the
job
providers
and
natural
providers.
C
As
it
says,
an
API
has
been
around
very
long
time.
She's
well
grounded
it's
well
trodden
and
none
and
has
had
updates
over
a
period
of
time
spanning,
let's
say
approximately
20
years
now.
If
we
look
through
some
of
the
the
versions,
we've
had
gone
back
to
102b
into
one
one
and
jms2
being
that
the
the
last
version
before
we
cut
over
to
Jakarta
they've
generically
been
additive.
So
in
102b
you
don't
have
a
certain
way
of
connecting.
You
would
have
had
objects.
C
That
would
say
I
want
to
critic
connection
to
this
queue,
so
I'll
use
a
queue.
Connection,
I'll
talk
specifically
this
queue.
If
you
want
to
jms1,
which
will
look
to
simplify
that
a
bit,
so
you
start
to
remove
some
of
the
specifics
about
the
objects
you're
trying
to
use
and
then
Germans
to
again
attempts
to
expand
onto
that.
So
if
you've
got
applications
running
from
maybe
20
years
ago,
using
102b,
they
can
still
run
environments,
they're
actually
supporting
jms2
as
their
General
additive.
C
Then
we
come
to
Chicago
to
messaging
3,
though
hash
you
will
probably
be
aware,
as
part
of
the
job
read
each
country
movement.
A
lot
of
that
on
the
time
is
move
in
the
Java
vaccine
interface
of
Jakarta.
So
if
you
think
of
Jakarta
messaging
now
it
was
actually
very
much
akin
to
and
very
similar
to
JMS
2.
C
So,
just
to
kind
of
go
over
that
a
little
bit
more
on
the
timeline
and
a
half
it's
in
with
the
joggery
and
cartery
time
frames.
So
on
left
hand.
Time
now,
we've
had
JMS
102d
back
in
2001
and
traveling
in
between
here
and
there
we've
gone
through
the
different
versions
with
their
Integrations
with
the
different
Java
e
versions,
and
we
find
the
jms2
being
the
last
one.
That
was
a
kin
to
the
jabber
E7
specification.
C
So
those
are
requirements
in
there
and
then
we've
got
to
the
Java
EA
time
frame,
which
was
the
last
geography
time
before
we
moved
over
to
them
being
moved
to
the
open
source
Community
under
Eclipse,
becoming
a
specific
option,
moving
forward
then
into
Jakarta
E9.
That's
the
time
where
Jakarta
estrogen
hr3
came
along,
which
was
where
the
JMS
has
moved
over
to
the
end
of
the
Jakarta
namespace.
But
the
implementation
of
the
program
is
the
same.
C
So,
just
to
take
a
quick
look:
I'm
not
going
to
go
into
a
huge
amount
of
detail
about
the
coding
of
this
we've
got
some
samples
and
stuff
I'll.
Look
at.
You
should
point
to
just
to
give
a
quick
look
through.
You
know
how
why
would
I
code
in
this
language?
Well,
as
I've
said,
it's
an
API
specification,
so
it's
not
tied
to
any
real
vendor
a
lot
of
that.
The
vendor
specific
details
are
hidden
away
from
you.
C
So
in
the
case
here,
what
we're
going
to
do
is
we're
going
to
look
up
at
the
top
a
connection
Factory
now
that
would
generally
come
from
your
Java
environment
or
some
other
environment.
So
you're
going
to
look
up
something
generic
to
you
and
your
code,
and
all
of
the
details
like
where
is
my
Q
manager?
Do
I
need
this
security
configuration?
What
are
these
other
properties
I
need
to
know?
There
are
very
much
vendor
specific
they're,
all
abstracted
away
from
your
application,
which
you
don't
need
to
code
or
know
anything
about
it.
C
So
you
could
write
an
application
and
it
could
pick
up
a
connection
factor
from
the
queue
it
could
be
any
other
JMS
provider
and
move
on.
We
have
a
simple
connection,
so
we're
just
going
to
create
connection
to
the
thing
now.
This
would
historically
the
things
you
could
have
had
a
Q
connection,
this
one
while
we've
moved
on
to
a
connection,
but
in
jms2
that
happens
to
be
a
context
and
that
defines
how
we
connect
it
to
it.
So
you
now
physically
connect
to
our
underlying
messaging.
C
As
we
said
that
could
be
anything
we
then,
as
we've
talked
about
in
messaging,
you
have
the
general
concept
accused
and
topics
in
this
case
we're
just
creating
a
definition
of
a
queue,
pressing,
a
message
and
then
sending
it
and,
as
you
see
in
this
there's
nothing
apart
from
our
very
top
one,
where
we're
using
a
very
simplified
external
thing,
there's
nothing
that
is
specific
to
the
vendor
itself.
It's
all
extracted
away
from
you.
It's
simplified
thing
that
can
and
can
move
in
between
different
vendors.
If
you
so
choose.
C
Okay,
so
if
I
said,
the
GMS
and
Jakarta
messaging
are
common
usage
in
runtime
environment
and
we've
chosen
to
build
a
sample
or
run
through
a
quick
example
of
how
you
get
yourself
running
quickly
and
the
differences
between
them
and
how
these
kind
of
things
can
interoperate.
As
we've
said
before
an
underlying
message
and
provider,
we
said
well
now
we're
talking
about
JMS
versus
Jakarta
messaging.
Well,
these
can
interact,
and
but
we
can
also
interact
everything
so
we'll
take
a
quick
runtime
environment
that
we
can
look
at
running
these
in.
C
To
give
an
example
of
how
these
things
can
run.
In
this
case,
we've
chosen
open
Liberty,
surely
for
it
being
a
nice,
simple,
open
source
project
click
to
get
running,
certainly
from
my
point
of
view,
I
think
we
found
it
running
with
most
people
pushing
them
and
it's
lightweight.
Scalable
and
yeah.
We're
gonna.
Take
a
quick
look
run
through
guessing
I've,
been
running
here.
Imagine
One.
B
B
You
can
see
that
Grandma
was
totally
wrong
here,
but
we
picked
a
Jakarta
version
in
this
case
9-1,
which
gives
us
Jakarta
question
three
capability
right,
clicked
on
generate
project
that
gave
me
a
zip
file
which
has
a
maiden
build
definition
in
it,
I
added
which
you'll
see
in
a
minute
the
code
for
the
message
listener.
The
MDB
ran
the
amazing,
build
process
and
I'm
up
and
running
connected,
and
mainly
these
is
treated
off
the
queue
so
really
quick
and
lightweight.
B
B
So
if
Android
here
has
put
a
GitHub
repo
out
of
your
MIT
license,
he's
explained
how's
it
right
and
MDB
explain
how
to
deploy
it
in
this
particular
case
with
open
Liberty
and
also
reference
the
source
documentation
that
you
use
to
build
that
repo.
This
is
one
of
many
yeah.
This
one
I
think
the
first
hit
I
found
on
Google
right,
and
it
was
just
nice
to
see
that
you
know
this
wasn't
very
specifically.
It
was
you
know,
community-led
so
yeah.
Thank
you
for
doing
that.
B
B
Okay,
so
I
think
we've
spoken
about
sort
of
basic
messaging,
a
little
bit
about
mq
and
how
that
provides
cues
and
things,
and
now
we
need
to
solve
the
problem
of
gluing
open
Liberty
in
the
runtime
environment,
together
with
JMS
Chicago's,
investing
three
technology
into
a
messaging
layer
so
that
we
can
do
it.
So
I
think
this
section
just
sort
of
completes
the
triangle
right:
okay,.
C
So
just
say:
we've
got
our
kind
of
mq
sat
down
the
bottom,
as
you
say
now,
this
could
be
our
thing
running
off
from
some
Pi
or
it
could
be
something
running
on
your
laptop
or
it
could
be
something
running
on
some
big
Mainframe.
It's
just
this
layer
running
down
the
bottom
and
then,
if
you
take
this,
this
nice
lightweight
to
open,
Liberty,
runtime
environment.
Well,
how
do
you
connect
it
into
that
and
open
Liberty
itself?
It
provides
its
own
JMS
provider
or
you
can't
actually
provider.
C
C
Now,
in
these
different
environments,
there's
generic
way
of
plugging
in
these
external
providers
that
could
be
mastered
providers,
but
they
can
also
be
things
like
databases
Etc,
so
that
can
come
in
Via.
You
know
all
the
day,
some
job
respect
or
the
jca
which
are
the
connectors,
and
then
you
move
into
Jakarta
move
into
the
kind
of
the
connector
connectors
thing
which
will
allow
you
to
specify
and
how
where's
my
code
that's
going
to
do
this,
and
then
you
can
find
the
resources
and
then
your
applications
again
at
the
top.
C
It's
our
MDB
are
going
to
specify
the
connection
details
that
specify
that
they're
very
much
again
still
hidden
from
the
application
itself.
It's
just
a
here's,
my
activation
inspector,
it's
called
Bob
and
in
your
XML
Etc,
you
would
actually
specify
the
provide
a
specific
implementation
and
then
the
application
and
knowing
to
it,
goes
through
the
resource,
adapter
layer
to
connect
to
receive
font
and
send
to
the
underline
and
queue
queue,
management.
B
If
you've
got
questions
under
the
IBM,
Dash
mq
tag,
but
there's
a
whole
bunch
of
things,
video
assets,
you
can
go,
take
a
look
at
and
there's
tutorials
on.
Ibm
Biz
learn
mq,
which
will
get
you
up
and
running
with
a
Q
manager,
nice
and
fast.
And
if
you're
prepared
to
spend
an
hour
or
two
reading,
some
tutorials,
you
can
get
yourself
a
badge
and
show
that
off
on
LinkedIn.
B
Word
that
I've
been
doing
in
my
team
and
I'm
happy
to
take
questions
on
this
follow-ups
or
whatever
we're
also
trying
to
make
our
resources
a
little
bit
more
dipping
and
out
of
we're
finding
YouTube
is
a
nice
way
to
do
to
do
that.
So
you
have
a
number
of
short
videos
on
on
YouTube
which
have
some
presentations
on
you
know.
Various
aspects
of
mq
and
it'd
be
great
to
get
your
feedback
foreign.
B
Okay
and
then
today
we're
talking
exclusively
about
Java
or
J
messenger,
Carter
messaging,
three,
like
many
messaging
vendors
and
as
I
said
at
the
beginning,
it's
important
that
we
have
apis
with
different
language
sets.
So
if
you
go
over
to
Dev
patterns,
which
is
our
idea
messaging
repo
for
samples
and
so
on,
and
you
should
be
able
to
find
a
messaging
sample
in
API
and
language
of
your
choice
right
so
what's
GMS
and
your
cost
is
incredibly
important
to
this
as
a
messaging
vendor.
B
There
are
other
ways
of
getting
messages
in
and
out
of
the
of
the
users
as
well.
Okay,
so
I'm
going
to
use
a
container
today
to
get
up
and
running
with
with
mq.
So
let's
go
and
do
that
live
see
if
I
see,
if
I
can
do
that
right
now
and
so
to
do
that,
I'm
just
going
to
can't
seem
to
copy
that
command.
B
Let's
go
and
see
if
we
can
do
that
so
hopefully
on
the
screen,
you
should
see
a
bunch
of
Windows
just
coming
in,
so
this
is
going
to
be
the
the
command
lines
that
I
use
for
my
for
my
Liberty
sews
in
just
a
second,
that's
also
bring
a
window
in
just
to
start
the
key
manager
up
and
to
maybe
send
some
messages.
Let's
clear
that
one
down,
but
hopefully
I've
got
a
Docker
run
command
in
here,
otherwise
you're
in
trouble.
B
Okay,
so
there's
the
command
that
you
can
see
on
the
presentation
just
a
moment
ago,
so
I'm
going
to
start
up
a
queue
manager,
I'm
going
to
give
it
a
little
bit
of
persistence.
The
docker
volume
called
cure
them
on
data
and
I'm,
going
to
open
up
Port
1414
for
messaging
work
and
I'm,
going
to
open
up
a
web
Port
that
we're
going
to
use
for
our
console
so
that
we
can
take
a
look
at
what
it's
doing
there.
We
are.
We
have
a.
B
B
B
A
B
Is
up
and
running
and
the
number
of
default
queues
have
been
made
available
so
when
we
create
a
container
in
ibmq,
we
give
it
a
default
development
config.
So
we
create
a
set
of
cues
ready
to
ready
to
go,
and
so
I've
got
three
cues
here
that
I
can
just
start
to
experiment
with
so
next
thing,
I'm
going
to
do
is
just
start
up
the
the
Liberty
service
so
that
Liberty
server
there,
which
is
just
starting,
is
a
Jakarta
messaging
three.
B
So
it's
using
the
Jakarta
e91
feature
set,
and
this
one
over
here
is
going
to
use
the
version
8
feature
set.
So
this
is
jms2,
and
this
is
a
Jakarta
messaging
3
server
and
here's
my
queue
manager
which
these
these
servers
are
going
to
connect
to
in
just
a
second
we'll
see
them,
and
while
it's
doing
that
and
what
behind
you
to
go
back
to
the
presentations
we
have,
which
is
just
there.
B
B
B
Okay,
so
what
we've
got
running
in
the
background
here
is
a
couple
of
limiting
runtime
environments
configured
with
the
resource
adapter,
and
we
have
a
little
bit
of
server
XML,
which
is
defining
activation
Speck,
which
Graham
spoke
about,
and
we
also
specify
Q.
So
this
is
what's
going
to
connect
our
message
driven
beam
to
mq
and,
as
you
can
see,
on
the
right
hand,
side
here,
we
both
have
a
jms2
so
using
the
javax
namespace
message
listener
and
a
Jakarta
messaging
three
message
listener,
and
these
just
have
a
very
simple
message
method.
B
B
Those
messages
print
with
the
screen,
regardless
of
how
they
came
into
the
system,
so
that's
just
a
trick:
the
messaging
layer
and
performs,
as
we
support
those
stones.
So
hopefully
that's
that's
clear,
Graham,
anything
to
add.
Okay.
So
before
we
get
to
the
questions,
let's
show
the
magic
so
I'm,
hoping
I'm,
hoping
our
I'm
hoping
our
servers
have
started.
B
B
Some
messages
in
using
your
car's
messaging
three,
so
let's
do
a
Jakarta
Jakarta
put
great
stuff.
Okay,
so
you
can
see
two
messages
gone
in
one
to
q1,
which
is
just
there
and
one
to
Q2,
and
you
can
see
that
the
payloaders,
your
lucky
number
is
153
on
each
message
and
jms2
stack
has
received
that
message
and
our
Jakarta
SG3
stack
has
received
that
vessel.
B
B
That's
just
put
an
arbitrary
message
on
here,
so
that
should
go
to
the
Jakarta
messaging
3
side,
which
it
has
so
there's
a
hello
just
there,
and
if
we
go
back
and
send
a
test
message
to
Q2
great
one
there
we
can
say
hi
Graham
like
that,
and
this
should
go
exclusively
to
the
jmst
site,
which
it
has
I.
Think
that
was
everything
for
the
demo.
If
you,
if
you
did
get
up
and
running,
then
key,
the
console
is
a
great
way
of
sort
of
exploring
your
configuration.
B
As
I
say,
there
is
a
set
of
predefined
cues,
so
there's
no
barrier
to
entry.
You
can
get
up
and
running
just
using
those
default
ones,
and
these
are
configured
for
an
app
views
and
we
set
the
password
on
a
Docker
one
command
for
those
of
you
looking
closely
and
it's
all
the
security
policy
that
gets
baked
into
that
container
for
its
lifetime,
which
makes
get
up
and
running
quite
easy.
C
B
B
Hopefully,
you
can
see
on
the
screen.
It's
loading
there,
so
there's
what
you've
just
seen.
You've
got
those
two
keys
down
to
different
namespaced,
JMS,
music
conferencing
three
respectively.
You
see
that
nice
message
exchange
over
both
of
them
it's
possible,
as
in
the
previous
diagram
here
that
was
shown
by
Graham
for
your
mdbs
to
connect
back
to
the
the
outside
world,
using
a
collection
Factory.
So
quite
often
what
you
see
that
that's
taking
longer
to
go
back
than
I
thought.
So
what
can
we
see
with
an
MDB?
B
B
Okay.
So
that's
everything
I
had
in
the
demo,
pretty
straightforward
configuration
load
validity,
got
our
key
manager
up
and
running
we've
injected
messages,
different
namespace
styles
and
delivered
them
to
mdbs.
As
shown
in
that
diagram.
There's
anything
I
have
be
great.
If
there's
any
questions,
we'd
love
to
hear
them.
B
B
Yeah
so
I
think
the
the
question
here
from
from
Dirk
is
how
does
the
reactive
messaging
relate
to
Jakarta,
nesting
and
I?
Think
that
this
really
sort
of
was
asking
questions
about
what's
available
in
the
micro
profile
versus
what's
available
in
in
the
Jakarta
stack
and
I?
Think
that
and
but
those
messaging
styles
are
are-
are
possible.
The
integration
that
we're
showing
here
has
a
slightly
deeper
set
of
capabilities
around
the
resource
adapter,
so
things
like
connection
reporting
and
transaction
supports
any
others.
B
You
know
recovery
and
reconnect
logic
and
those
kind
of
things,
so
we've
added
some
additional
capabilities
in
there.
If
I
had
to
talk
to
Emily
earlier
I,
don't
know
that
Emily's
on
online,
but
one
of
the
things
that
we
can
do
with
ibmq
is
connecting
is
that
reactive,
stuff,
using
amqp
and
I?
Think
that
would
be
a
great
talk
to
them
back
if
there's
interest
to
do
that
in
both
messaging
styles
are
compatible
with
each
other.
Often
we
see
solutions
that
are
doing
both.
B
If
we
take
the
example,
maybe
an
airline
States-
maybe
we
want
say
an
operational
message
to
change
the
state
of
the
world,
but
once
the
seat's
booked.
Maybe
we
want
to
propagate
messages
to
to
other
services,
to
maybe
allocate
loyalty
points
or
to
a
log
that
seats.
So
we
often
see
that
sort
of
complementary
relationship
between
messaging
Styles
and.
B
B
Okay,
well,
I
think
I
think
we're
there.
Oh
we've
got
a
mic
problem,
so
so
you
know
they're,
saying
sorry
about
that.
I
guess
considerable
questions,
I'll
hand
over
to
the
I'll
hand
over
to
you
have
the
call
wrapped
up,
but
thank
you
very
much
for
your
time
and
please
do
make
contact
if
you'd
like
a
follow-up.