I have a project that is currently in production delivering some web-services using the REST approach. Right now, I need to delivery some of this web-services in SOAP too (it means that I will need to deliver some of the same web-services in SOAP and others a bit different), so, I ask you:
Should I incorporate to the existent project the SOAP stack (libraries, configuration files, ...), building another layer that deliver the data in envelopes way (some people call it "anti-corruption layer") ?
Should I build another project using just the canonical model in common (become it in a shared-library) ?
... Or how do you proceed in similar situations ?
Please, consider our ideal target a SOA architecture.
Thanks.
In our projects we have a facade layer which exposes the services and maps to business entities, and a business layer where the business logic is run.
So to add a SOAP end point for an existing service, we just create a new facade and call in to the same business logic.
In many cases it is even simpler, since we use WCF we can have a http SOAP endpoint for external clients, and a binary tcpip endpoint for internal clients. The new endpoint can be added by changing the configuration without any need to change the code.
The way I think about an SOA system, you have messages and pub/sub. The message is the interface. Getting those messages into and out of the system is an implementation detail. I create an endpoint that accepts a raw message document (more REST-like, but not really REST) as well as an endpoint that accepts the message as a single parameter to a SOAP call. The code that processes the incoming message is a separate concern from the HTTP endpoint enablement.
You can use an ESB for this. Where ESB receive the soap messages and send the rest request to the back end. WSO2 ESB provides this functionality. Please look at this sample[1].
[1] http://wso2.org/project/esb/java/4.0.0/docs/samples/proxy_samples.html#Sample152
Related
I need to integrate 3-5 existing and ready services that are developed by different teams. That is something like integrating several independent monolithic applications.
The very wanted feature is having a central communication component where all requests can be logged (or partially logged in case they have a big payload) so that it can be quickly seen what service sent a request with what payload and when if something goes wrong.
The second task is security. It is needed to protect inter-service communication.
I have been researching this topic for several days. That is what I've come up with so far:
Use Enterprise Service Bus (ESB)
Use MessageBroker (ActiveMQ, RabbitMQ, Kafka, etc)
Simply use REST API communication
I've read about ESB and I am not sure whether this solution is OK to use.
The picture from Wikipedia shows the following:
The problem with ESB that it not only implements communication between separate independent services. It also changes the communication itself from synchronous request-response model to an asynchronous messaging style. Currently, we don't need asynchronous messaging (maybe we will in the future, but not right now).
ESB allows to make request-response communication, but in a very inconvenient and complex way with generating correlation IDs, creating a temporary response-topic and consumer. With this, I have doubts whether it has more advantages to use ESB with its super complex Request-Response messaging style or simply use plain old REST API calls (RPC). However, with REST API it is not possible to have a centralized component that can log all communication between services. A similar problem exists with Message Broker too (because it also involves asynchronous messaging).
Is there any ready solution/pattern to integrate several services (not microservices) with centralized logging, security configuration and having simple to implement synchronous request-response model (with a possibility to add messaging, if needed, later)?
Make your services talk to each other via a proxy that will take care of these concerns (Back in 2007 I called this "edge-component" but the today it known as sidecar pattern)
A common way to do that would be to containerize your services, deploy to Kubernetes and use a service mesh (like Console's or istio, etc)
Currently we are implementing REST API's using the spring-boot. Since our API's are growing in number we are thinking of a solution to implement the REST API's using a different approach.
The approach is as below :
Expose a single service to receive all the HTTP requests.
We will have the URI's configured in a data base table to call the
next set of services. These service are configured to listen to
particular JMS messages.
The next set of services will receive the JMS messages and process
the data.
Below are my questions :
Will the above approach still represent the REST architecture ?
What are the downsides of above approach(we are aware of network
latency) any thing other then network latency ?
What are the REST architecture benefits will we be missing.
Or can we just say that our approach is the REST architecture done differently ?
You're making 2 major choices, each can be decided separately:
1) Having a single HTTP service
2) Using JMS as the communication between this service and the underlying microservices
Regarding #1, if you do this, you can no longer call your services REST since the whole point of REST is to use HTTP verbs together with your domain objects for a predicable set of endpoints. GET on /objects/ means the object is being fetched, POST on /objects means a new object is being created, etc... Now, this is OK, you can do it this way and it can work, though it will be "non-standard".
In fact, you might want to check out GraphQL https://www.howtographql.com/basics/1-graphql-is-the-better-rest/ as its pretty close to what you're trying to do.
These days really either REST or GraphQL seems to be the two popular approaches.
Another way to do REST, if you're looking to simply expose REST services on your domain objects without having to write a lot of code, is Spring Data REST: https://spring.io/projects/spring-data-rest and if you're comfortable with Spring already, this should be pretty easy to understand.
For #2, your choice of communication between your single gateway service and the underlying services. Do most of your calls require synchronous answers, such as a UI asking for data to display in a browser or phone? If so, JMS is not a good approach. JMS would be an ok approach if the majority of your services were asyncronous - for example someone submitting a stock trade request. The UI would just need to know the request was submitted, but it will actually be processed some time later and the result will be fetched asyncronously.
Without knowing much about your application, I would recommend sticking with HTTP between your services for simplicity sake unless there is a good reason to switch to JMS.
We're trying to split our monolithic core into microservices and add some new ones connected with each other using the message system (e.g. Kafka).
The next stage is to create API endpoints for communication between mobile apps and microservices through Api gateway.
What would be a good solution for developing API gateway to transmit data to/from microservices?
use message system as request-reply one (transform requests on
API gateway into message commands, wait for response from message
system with status or necessary data)?
create REST endpoints on necessary microservices (e.g. using REST.li) to send or
get data through gateway; use message system for consistency of data
based on produced events by microservices?
Thanks for advice and some ideas
This depends about the Architecture that you are adopting.
If I understood the question, you already have the broker with the kafka message server.
I think that you can use the architecture publish/subscribe to assyncronous message.
If in the backend architecture the legacy systems to support SLA, in this case you can use the rest endpoints necessary to the integration.
This is the gain of if to utilize API Gateway Pattern in the Architecture.
Thanks a lot.
I would like to say that the second option sounds more reasonable for many cases.
Event-Driven solution mainly fits in the cases in which there are several following processes, so the creating entity could be via Rest endpoint, while processes of that entity could be async via events.
To illustrate, Payment Flow could be like below:
1-) API GW -> Payment Rest Controller -> Payment Service - Create Payment
Payment service creates a payment entity, and then publishes "payment.created" event.
2-)Queue -> Payment Stream Controller -> Service - Update Payment
Payment Stream controller consumes the "payment.created" event, and then checks balances, and updates payment entity as Confirmed. After updating the entity, it could send "payment.confirmed" event.
...
On the other hand, I mean the first option, it would be very hard to maintain a very decoupled system, as you need to know all exchanges or queues.
However, I think combining two solutions could be better for some cases. For example, your API is exposed by a client with very high traffic and the task of the API is quite clear. In that situation, using MQ as a buffer for this API would be perfect.
First of all I don't code, I'm a BMS engineer where I use products which inturn uses REST API.
For programming that controller I use REST service & give the port as 80
Now I need to understand, how port 80(HTTP) and REST API works together and what difference is that with SOAP?
What in general RESTful service gives my controller? Please answer me in a layman language so that i can understand.
A "web server" receives the requests by listening at a port. Default port for HTTP request is 80.
SOAP and REST differs mainly in below aspects.
1)How a service gets discovered
2)Data transfer format across the wire
3)How request processed and response generated
SOAP messages are always XML. REST messages can be in JSON,XML...many other formats also supported.
Making REST based requests easier compared to SOAP based requests since "SOAP clients" are heavy weight and need special
libraries. Rest clients are light weight and can be easily generated from any device.
I have a question about the design of an application I'm working on.
I made a monolithic java application with sockets open 24/7, something like a game server. I'm just trying to say it's a single jar application instead of a modular servlet/page based web application.
I would now like to add a RESTful API to this application. So people/clients can make HTTP requests to my application to obtain certain info. Because of the monolithic nature of my java application I'm unsure of how to implement this. One other important thing: I'm expecting multiple requests per second, so it would be nice if I could have an existing http server handle the requests, and somehow forward them to my app to set up a reply, and have the http server send it again.
Some things I have thought of:
wrap my application in a tomcat application, although I'm not sure if tomcat can run an application continuously instead of mapping to servlets on request.
open a socket and parse incoming http requests myself (or there is propably a lib for that?). I fear this will have an impact on performance, and would rather use existing http servers because they are optimized for high traffic.
use an excisting http server to handle the requests (apache, lighttp, ...) and have it forward requests to my app via things like scgi, or use a server that can forward via XMLRPC. Are there any other technologies/protocols to do this?
Any advice on how to handle this?
Thanks!
I'd decouple your RESTful service endpoint as much as possible from your original application. This allows you to scale (add multiple servers for your REST endpoint), but also to change your original application without having to change your REST API directly.
Clients <== REST (HTTP) ==> RESTful endpoint <== legacy (sockets) ==> Legacy backend
So your REST server is one the hand a service provider for your clients, but represents at the same time also a client for your original backend.
I would design the RESTful API and then pick one of the existing REST frameworks for Java, like Restlet, and implement the REST service itself. At the same time you can start implementing a gateway between the REST server and your original backend, by using sockets.
Pay attention to scalability and performance (i.e. you may want to use connection pools for the rest <=> backend bridge and not spawn a socket per incoming API request) and also think of possible advantages of HTTP. You might benefit when you're able to use caching, etc. as far as your backend application logic allows so.