►
From YouTube: Hiding SOAP Legacy Applications Using the Mullet Pattern With Aaron Weikle | Kongcast Episode 4
Description
Organizations don’t move as fast as technology. That’s why in this Kongcast episode, Aaron Weikle, Founder & CEO at MS3, explains how to continue supporting your organization’s legacy-based services as they continue to add the next generation of services.
If you're planning on migrating legacy applications to microservices this episode if for you!
More about MS3's Kong SOAP plugins: https://www.ms3-inc.com/wp-content/uploads/2021/11/Kong-SOAP-Adapter-WEB.pdf
More about the DataSonnet project: https://datasonnet.com/
Contact MS3 to learn more: https://www.ms3-inc.com/
Subscribe to get email alerts for the latest new episodes and see which guests are coming on the show next: https://bit.ly/3zQV71e
▬▬▬▬▬▬ TIMECODES ▬▬▬▬▬▬
0:00 Kongcast Show Intro
0:28 Welcome, Aaron!
2:19 Mullet Pattern vs. Strangler Pattern
3:21 Kong Gateway SOAP Plugins to Integrate Legacy Applications
5:16 SOAP Request Validation
7:37 Legacy Mullet Plugin
9:38 DataSonnet and Java PDK
11:45 Demo: Custom WSDL Kong Plugins
21:45 Thanks for Joining, Aaron!
23:28 Kongcast Show Outro
▬▬▬▬▬▬ ABOUT KONGCAST ▬▬▬▬▬▬
Hosted by @ViktorGamov and Kaitlyn Barnard, we interview software developers and technology leaders at the top of their game every other week. We’ll also give you the tools, tactics and strategies you need to take your distributed architectures to the next level. Kongcast goes beyond the buzzwords and dissects real-life applications and success stories so that you can tackle your biggest connectivity challenges.
▬▬▬▬▬▬ KONG COMMUNITY ▬▬▬▬▬▬
⭐ https://github.com/Kong/kong
🐦 https://twitter.com/thekonginc
🌎 https://konghq.com/community/
🍻 https://www.meetup.com/pro/kong
❓ ️https://discuss.konghq.com/
💯 https://konghq.com/kong-champions/
#MulletPattern #StrangularPattern #APIGateway #KongPlugins #KongGateway #Kongcast
B
A
Today,
I'd
like
to
welcome
erin
weichel,
ceo
at
ms3
aaron
is
here
to
talk
to
us
about
how
to
support
your
legacy
applications
while
embarking
on
digital
transformation
efforts,
if
you're
currently
trying
to
figure
out
how
to
modernize
your
applications
while
dealing
with
technical
debt,
this
episode's
for
you
erin.
Could
you
start
us
off
by
kind
of
setting
the
stage
for
our
viewers
on
the
problems
organizations
run
into
and
how
this
relates
to
common
connectivity
challenges.
C
Yeah
thanks
caitlin,
you
know.
First,
I
want
to
say:
I'm
super
excited
to
be
part
of
you
know,
comcast,
and
you
know
a
tremendous
opportunity
to
present
some
of
the
exciting
things
that
we
have
going
on
here.
So
one
of
the
things
you
know
our
organization
has
been
in
the
integration
space
for
over
a
decade,
and
so
we've
seen
the
evolution
of
technology
as
it
goes
from.
C
You
know:
legacy
based
type
of
b2b,
interconnectivity
with
you
know,
pipe
delimited
data,
fixed
field
sets
through
soap
integrations
and
now
we're
into
our
next
generation
of
restful,
apis
and
grpc
organizations.
However,
don't
move
quite
as
fast
as
what
technology
does,
and
so
there's
a
lot
of
technical
debt.
That
is,
you
know,
strung
along
for
decades.
A
C
So
organizations
have
done
a
variety
of
different
things:
right,
they've
implemented.
You
know,
technology
tooling,
like
esps
and
in
order
to
provide
both
message
and
protocol
based,
abstractions
they've
implemented
a
variety
of
different
technologies
in
order
to
implement
a
way
to
hide
the
soap
behind
the
scenes.
C
And
if
you
look
at
a
gentleman
by
the
name
of
martin
fowler,
he
actually
has
a
document
written
out
there
around
the
strangular
pattern
or
strangular
facade,
and
so
we
like
to
take
that
pattern
and
implement
it
in
what
we
call
the
mullet
pattern.
Right.
Where
you
have
a
nice
clean
api
in
the
front,
you
got
the
messy
soap
in
the
back
and
what
that
does
is
it
provides
a
layer
of
abstraction
between
the
consumers
and
the
legacy
systems,
because
you
have
that
abstraction
point.
It
allows
a
period
of
disconnection
between
the
services.
C
So
that
way,
as
you
begin
to
modernize
the
back-end
systems,
those
are
unimpactful
for
your
consumers,
which
is
really
important,
because
no
one
wants
to
have
a
change
that
goes
into
place
and
then
every
time
that
a
system
continues
to
modernize
or
make
incremental
changes
on
the
banking
system.
That
all
of
the
consumers
have
to
make
modifications.
That
is
a
very
costly
approach,
and
by
taking
this
mullet
pattern,
it
really
helps
to
alleviate
that
type
of
cost
initiatives
that
organizations
face
on
the
daily.
So.
A
C
C
C
In
addition,
one
of
the
big
problems
that
we
see
is
the
poor
implementation
of
fault
handling
within
soap.
So
soap
is
something
that
whenever
you
have
a
problem,
it
doesn't
really
give
you
a
nice
clean
status
code
associated
with
you
know
what
the
problem
was
like
when
you
have
a
401
or
403
or
404
types
of
errors
in
restful
apis.
C
That
is
pretty
self-telling
just
in
the
status
code.
But
everything
that
comes
back
from
soap
is
just
a
500
right
and
so
inside
of
that
they
have
what's
called
a
soap
fault
body
now,
historically,
with
soap
faults,
they
dump
a
lot
of
information
in
there
there
could
be
stack
traces.
There
could
be
sensitive
information,
a
lot
of
really
ugly
things
that
you
don't
want
to
go
out
to
your
end,
consumers,
if
you're
in
the
health,
industry
or
financial
industry,
there
could
be
sensitive
information.
C
C
We
say
contact
your
administrator
and
take
that
that
heavy
lift
of
being
able
to
process
that
off
of
the
systems
and
having
to
you
know
make
sure
that
everything
is
coming
back
clean
because
at
the
end
of
the
day,
we
don't
want
our
developers
or
or
the
our
clients
developers
working
on
building
enhancements
to
soap
services,
which
should
be
you
know,
slowly
going
away,
but
focusing
on
writing
new
restful
or
grpc
based
services
that
can
go
through
the
gateway.
So
by
providing
that
whatever
technical
debt
that
they
historically
have
had.
C
C
As
you
know,
with
soap
soap,
soap
that
says:
what
is
it
that
we're
going
to
do
with
this
inbound
request
right,
and
so
it
could
be
processing
data.
It
could
be
retrieving
data,
it
could
be
updating
data,
but
it
all
comes
through
the
same
http
request,
which
is
an
http
post.
So
what
we
do
is
we
actually
provide
the
capability
to
map
a
get
operation
on
the
front
end
to
a
http
post
with
a
say,
get
customer
soap
action
on
the
back
side.
C
Likewise,
if
we're
doing
a
post
operation
for
the
customer,
we
do
a
post
operation
to
create
customer
on
the
soap
action.
So
so
this
gives
us
the
ability
to
really
blend
the
front.
End
restful
capability
to
the
soap
back
in,
and
that's
going
to
alleviate
rewrite
of
consumers
down
down
the
line,
especially
as
you're
going
from.
Let's
say
you
have
an
old
erp
system.
Maybe
it's
you
know
an
sap
system
or
it's
a
microsoft
dynamics
and
you're
moving
to
a
sales
force
right.
C
Those
legacy
systems
are
using
so
as
you're
migrating
your
erp
components
into
into
salesforce.
Now
your
consumers
are
completely
oblivious
that
any
of
this
work
is
going
on
on
the
backside,
because
they're
still
getting
the
data
models
they're
still
using
the
operations,
the
way
that
they
did
before.
So
that's
really
really
powerful.
Next
thing
that
we
did
was
we
actually
created
an
additional
plug-in
kit
for
kong.
So
what
we
did
was
we
took
a
java
based
component
and
we
built
it
to
utilize.
C
The
communication
bridge
within
calm
and
the
reason
that
we
decided
to
go
with
this
direction
is
because
a
lot
of
the
powerful
data
transformation
tooling,
is
written
in
scala
or
or
java,
or
things
that
are
used
in
a
jvm,
and
so
one
of
the
open
source
platforms
that
we
really
love
is
called
data
sonic.
So
data
sonnet
is
a
template
based
transformation,
language
that
is
written
at
scale.
C
You
don't
want
them
to
have
to
send
in
these
huge
requests,
and
these
huge
responses
back
and
iterate
through
the
data
to
then
make
the
next
set
of
requests
that
becomes
very
erroneous
to
the
mobile
applications
where
their
cpus
and
their
memory
just
can't
handle
that
that
amount
of
work.
So
this
capability
allows
kong
to
have
a
lightweight
call
come
in
from
a
mobile
application.
C
It
can
use
data
sona
to
call
let's
say
a
product
catalog
and
then
that
product
catalog
will
then
return
back
information
that
we
can
then
use
another
call
out
to
a
system
to
provide
additional
information
start
to
shrink
the
data
model
to
only
what
the
mobile
application
wants
and
then
return
it
back.
That
pulls
the
workload
off
the
mobile
application
and
provides
that
into
back-end
systems
which
have
substantially
more
resources,
and
so
that's
another
really
powerful
way
that
you
can.
A
C
C
So
one
thing
to
be
cognizant
of
here
is
that
when
you're
working
with
soap-
and
we
need
to
be
able
to
store
this,
it
will
not
work
in
the
db
less
mode.
In
addition,
we
also
pull
the
schemas
right,
so
we
pull
the
schemas
in
so
that
way
that
those
can
be
obfuscated
at
the
gateway
level.
One
problem
that
you
run
into
is
that
there
will
be
a
firewall
between
the
two
and
you're
unable
to
be
consume,
the
schemas
from
the
wisdom.
C
C
That's
why
you
see
new
lines
so
that
way
that
it
can
be
easily
handled
whenever
we
need
to
serve
it
up
to
back
in
consumers.
So
the
second
piece
that
we
do
is
now
we
have
the
wisdo
provider,
so
the
first
one
was
the
dao.
That
is
the
way
to
be
able
to
pull
the
information
from
destination
systems,
whether
it's
from
a
file
or
whether
it's
from
a
service
or
you
want
to
manually
upload
it
that
gets
it
into
calm.
Now.
C
We
can
actually
then
use
the
plug-in
provider
to
then
expose
that
externally
to
the
the
end,
consumers-
and
we
can
update
these
paths.
However,
we
want
to
we're
just
using
temp
here.
As
you
can
see,
these
plugins
will
be
available
inside
of
the
kong
ui.
We've
put
it
in
so
that
way
that
we
can
have
everything
associated
with
an
easy
configuration
capability.
C
This
alleviates
some
of
the
headache
of
of
needing
to
know
how
to
use
an
api
to
modify
or
update
configurations
within
a
custom
plugin,
so
we
went
ahead
and
spent
the
extra
time
to
put
this
capability
in
here.
As
you
can
see
here,
we
specify
where
we
want
the
endpoint
for
the
url,
and
you
can
also
specify
wisdo
as
being
the
query
parameter.
Whenever
you
want
to
return
the
actual
wisdo
itself,
some
organizations
may
have
location
equals
wisdo,
but
typically
the
whistle
question
mark
wisdom
is
how
you
tell
a
organization.
C
That's
consuming
your
service,
where
the
whistle
definition
is.
We
have
some
masking
capabilities
which
we'll
we'll
return
to
that
in
just
a
minute,
but
you
can
also
specify
your
response
headers.
So
it's
always
good
to
define
this,
especially
if
you
want
to
come
back
as
a
application,
xml
or
text
xml.
In
this
case,
we
want
this
to
come
back
as
being
text
xml.
So
that
way,
it's
you
know
very
simple
to
consume.
Lastly,
remember
the
uid
on
the
response
that
goes
in
and
that
provides
our
actual
service,
that's
accessible
from
the
the
influence.
C
So
one
of
the
other
pieces
that
we
talked
about
just
or
I
was
talking
about
just
a
second
ago-
is
the
configuration
abstraction.
So,
as
you
can
see
here,
it
comes
with
services
urls,
but,
as
I
mentioned
before,
you
may
be
behind
the
firewall,
where
the
service
endpoints
from
the
sub
action
are
not
accessible.
So
with
that
being
said,
we
support
both
just
having
the
gateway,
provide
the
service
definition
with
the
service
natively
in
there
or
where
everything
has
to
come
through
the
gateway.
C
So
in
this
case,
what
we're
doing
is
we're
going
to
go
through?
You
can
mask
the
addresses
to
your
backend
service,
so
what
happens?
Is
this
address
will
be
found
inside
the
whistle
and
it
will
be
replaced
with
the
gateway
url
that
will
provide
when
it
comes
in
it
defines
the
route
so
that
way
that
when
it
comes
to
that
gateway
endpoint,
it
knows
where
to
go
within
your
back-end
destination
system.
C
C
C
C
C
C
So,
moving
on
to
the
the
custom,
soap
validation
plug-in.
So
this
is
the
one
that
I
was
telling
you
about
earlier,
where
we
can
actually
validate
both
the
body
of
the
soap,
and
we
can
also
hide
the
faults.
So,
like
the
whistle
provider,
this
one
also
provides
the
capability
for
us
to
hide
the
abstraction
of
the
soap
faults.
C
So
it
knows
what
it's
going
to
validate
against,
and
the
information
that
we
actually
had
originally
within
the
soap
service
is
what
it's
going
to
utilize.
So
if
you
remember,
whenever
we
ingested
the
whistle
it
had
the
information
associated
with
the
schema
that
schema
data
is
what
is
going
to
go
through
and
make
sure
that
everything
is
validated
and
it
does
not
break.
C
C
C
We
also
have
the
capability,
as
I
mentioned,
do
data
transformation,
the
plug-in
that
we
showed
there
at
the
end,
I
did
the
data
validation,
but
then
it
also
hid
the
subfault.
It
came
back
so
that
way
that
it
was
easy
for
your
consumer
to
know
that
there
was
a
problem.
They
need
to
communicate
with
the
admin.