(Migrated) Web Service Proxy Pattern

forum-admin · June 20, 2016, 4:17pm

(This message has been automatically imported from the retired mailing list)

Hi list.

I have several times had discussions with clients about exposing other =
system=E2=80=99s services as if they were services in the ESB. Optimally =
let the ESB serve realtime modified wsdls from the endpoint services =
through the ESB and reflecting the same methods in the ESB as available =
in the endpoint. The reason for doing this might be for example to =
expose shielded services and have centralized audit for all =
transactions.

I have seen that Mule have a pattern for setting up a scenario for this, =
but never used it, or mule. And the link below describes the scenario =
almost exactly as if I would have described what I often have wanted to =
do in my cases.

=
http://www.mulesoft.org/documentation/display/current/Web+Service+Proxy+Pa=
ttern =
<http://www.mulesoft.org/documentation/display/current/Web+Service+Proxy+P=
attern>

I=E2=80=99d be very interested in figuring out if and how this would be =
a suitable scenario to set up/develop with Zato.=20

Br, Daniel Grindelid

forum-admin · June 20, 2016, 4:17pm

On 15/11/14 17:08, Daniel Grindelid wrote:

I have several times had discussions with clients about exposing other
system’s services as if they were services in the ESB. Optimally let the
ESB serve realtime modified wsdls from the endpoint services through the
ESB and reflecting the same methods in the ESB as available in the
endpoint. The reason for doing this might be for example to expose
shielded services and have centralized audit for all transactions.

Hi Daniel,

let’s go through it piece by piece in detail - what does the backend
service you proxy to do?

Please provide:

Request headers it accepts/requires
Request payload it accepts/requires
Response headers it produces
Response payload it produces

thanks,

forum-admin · June 20, 2016, 4:17pm

On 15/11/14 17:08, Daniel Grindelid wrote:

I have several times had discussions with clients about exposing other
system’s services as if they were services in the ESB. Optimally let the
ESB serve realtime modified wsdls from the endpoint services through the
ESB and reflecting the same methods in the ESB as available in the
endpoint. The reason for doing this might be for example to expose
shielded services and have centralized audit for all transactions.

Hi Daniel,

let’s go through it piece by piece in detail - what does the backend
service you proxy to do?

Please provide:

Request headers it accepts/requires
Request payload it accepts/requires
Response headers it produces
Response payload it produces

thanks,

forum-admin · June 20, 2016, 4:17pm

On 15/11/14 17:27, Daniel Grindelid wrote:

This I will sure do. I do not have the systems on hand but will get these details documented.
For the current case it is a system exposing SOAP services used for storing and retrieving personal
records within the health care sector where they’d like to use the ESB platform
to audit all calls made. I will figure out the details as requested before going further.

Cool, please do.

Trivial things like proxying 1:1 are trivial indeed. Here we have a
proxy which translates messages from ZeroMQ to JMS WebSphere MQ and AMQP
in 2 lines of code:

https://zato.io/blog/posts/zeromq-amqp-jms-websphere-mq-more-2-lines-of-code.html

Or below, let’s assume we have such a 1:1 HTTP proxy. This is the actual
code needed:

from zato.server.service import Service

class MyProxy(Service):
def handle(self):
backend = self.outgoing.plain_http[‘Backend’]
self.response.payload =
backend.conn.post(self.request.raw_request).text

Now you can expose the same service over XML, JSON or anything and, for
instance, require security any means using the GUI as here:

So as you can see - such use cases can be done in 2 or 3 lines of code.

However, when you reach the point of complex business requirements with
custom headers, lots of transformations, lookups, dictionaries, missing,
incomplete or invalid responses, including XML-like payload produced by
parsers from proprietary vendors or such, you will definitely want to do
it in Python and Zato rather than in XML or a graphical language (even
if Zato may grow the latter with time for coordinating higher-level
processes).

As for the audit trail - this is trivial as well.

Let’s assume you have an HTTP proxy as the one above - now you need to
audit it.

What you do is mounting the proxy on a channel, enable the audit log and
after accessing, say with curl:

$ curl localhost:11223/service -d “My Payload”

… you have screens as here:

Note that you can specify a list of patterns, JSON Pointers or XPath,
that will be masked out when storing audit data so as not to log user
secrets.

Obviously, as with pretty much anything in Zato, the audit log is
available in the platform’s API so you can plug it in to any monitoring
tool.

But these are just ideas off the top of my head - please prepare
requirements, sample data and I’ll be happy to assist.