Point-to-Point integration vs ESB

Question

We have a system which has been in development for 10+ years and still continues. It is built as an SOA and use SOAP. We have a new client, internally within our company, who wants to integrate with our application. Since JSON and REST are the sexy and new thing, they want to communicate with us using HTTP, following REST and JSON as the Data Exchange Format. This is fine and no problem.

The questions I need to answer to myself in order to make an informed decision are the following:

1. Should we expose the services and provide JSON? This means development within our system or possibly a thin layer on top of our SOAP services.
2. We have an ESB within our enterprise. Should we just ask the client to connect to the ESB, which will call our SOAP endpoint, receive an envelope, transform it and return it as JSON to the client. This means development within ESB.
3. Do 1 above and in addition, ask the client to connect to the ESB to avoid Point-to-Point integration.

I was hoping someone out there, preferably architects with years of experience will help me arrive at a conclusion which will make our system ready for a better future.

Answer 1

How much load do you expect from this new service? For a client that wouldn't call on your application much, there's nothing wrong with option 1, especially if you don't expect to do any more favors for other clients. Point to point can get ridiculous to maintain, but a simple RESTful abstraction layer probably wouldn't add much tech debt. But like you said, REST APIs are new and sexy, and it may not be the last you'll hear about it. Fortunately, even two or three more applications to integrate over HTTP shouldn't require a big overhaul with enterprise integration designs.

If you have an ESB already, and the client is internal to the company, why haven't they already connected to it, rather than come to you directly?