On most of the resources on google, I see one of the major advantage of graphql is said to be its ability to be as aggregator service but I did not find any concrete example how it is different from other http endpoints(or Rest endpoints) ?
My understanding is that in case of GraphQL, there will be single http endpoint for everything. Then graphql server will determine which particular
data fetcher will be called. That is provided in very configurable way.
But in case of other MVC based architecture or rest based architecture, end points are separate for each request and then the flow start.
So in a way graphql provides the single entry point(or we can say address) for each request then graphql take care of further branching, but in other above
mentioned architecture there are separate addresses(or endpoints) for resources/request. Is it because of this reason we say graphql can work as aggregator service or is it something else ?
The GraphQL's main advantage is to provide to the client ability to query everything (objects) it needed and display it to user without discussing/creating specification for every request/response in the application. And in some cases clients need different responses for the same request (eg views might look differently for web and mobile clients).
I believe you can create multiple GraphQL endpoint in your application based on context of your domain, but it might be misleading in most cases.
Related
I'm starting to choose a way to create my webservice, so i found 2 ways to do it:
1) Using the package javax.jws, with annotation #WebService:
#WebService(...)
public class MyServiceImpl {
2) The other way is using javax.ws, with annotation #Path:
#Path("/MyService")
public class MyServiceImpl
In my understand using the second solution is more simple, because when i need to create the Client i just need make a HTTP call (GET/POST). Using the first solution i need create a WSDL client, more complex solution.
So, I would like to know which is the advantage in use FIRST SOLUTION.
The SOAP/WSDL style is useful when a formal contract must be established to describe the interface that the web service offers.The Web Services Description Language (WSDL) describes the details such as messages, operations, bindings, and location of the web service.
Also the SOAP/WSDL style is useful when the application architecture needs to handle asynchronous processing and invocation (e.g. using JAX-WS the assynchronous clients can be created).
The disadvantages of SOAP/WSDL style are
its complexity: tools are required to create a client
heavier on Bandwidth : SOAP requires a heavy XML wrapper arround each request or response
complicated security rules
The advantages of REST style are
simplicity: REST client can be accessed from any browser (however, this is only true for GET method. Data creation request requires also the XML wrapper).
lighter on Bandwidth : data on the wire are usually bare xml elements (not wrapped within the <Envelope><Body> tags).
REST application security rules can be setup using the http standards: the administrator (or firewall) can discern the intent of each message by analyzing the HTTP command used in the request.
For example, a GET request can always be considered safe because it can't, by definition, modify any data.
The disadvantage of REST style is that it still doesn't cover all business requirements
There is no common standard accepted yet for the formal REST service description
REST requests (especially GET method) are not suitable for large amount of data
REST doesn't cover all web services standards, like Transactions, Security, Addressing, Trust, Coordination,
In my company we have several basic REST services consumed by our web and mobile applications. (Please read REST as only JSON over HTTP with only POST calls).
In order to improve the performance of the mobile client (network overhead of many http calls) we would like to be able to aggregate some REST calls.
We would like to find a generic solution so the mobile client is free to choice which services to aggregate.
The solution currently found is a generic REST service that receives the json with the list of requests and delegates
to a pool of threads the execution of each request. When all requests are completed the service collects all the
responses in a list and return it as aggregated response.
This solution has some problems:
The spring or javax validation is not applied (is invoked in the aggregating service)
Session scoped data is not available in servant thread (a workaround found via ThreadLocal)
Filters and Interceptors are not applied on the single request (no solution yet)
Potentially others issues yet undiscovered
Does spring(mvc) offer a better way to do the same?
Can HandlerInterceptor help me in re-implement the same logic in a safer way?
Thanks
Vito
I'd like to synchronize the state to all the clients interested in particular entity changes. So I'd like to achieve something like:
exposing CRUD API on entity (via HTTP/REST and websockets)
and routing the response (of the modifying calls) to websockets topic
So technically, I'd be interested in ideas to mix spring-data-rest with spring websockets implementation to achieve something like spring-data-websocket.
There are a two solutions coming to my mind, and in fact both would be:
spring-data-rest to expose my entities via REST/HTTP API
websocket controllers (used for the modification calls on entities)
The websocket controllers would look like this:
#Controller
public class EntityAWebSocketController {
#MessageMapping("/EntityA/update")
#SendTo("/topic/EntityA/update")
public EntityA update(EntityA entityA) throws Exception {
// persist,....
return entityA;
}
}
Scenario 1: Websocket API called from REST/HTTP API
Rules:
client request is always REST/HTTP API
response is REST/HTTP API for all the operations
moreover for modifying operations the websocket message comes as well
Technically, could be achieved, by:
calling the websocket controllers from the spring-rest-data events (namely in the AfterCreateEvent, AfterSaveEvent, AfterLinkSaveEvent, AfterDeleteEvent)
Still the solution seems quite sick to me, as I'd need to go for:
client A --HTTP request--> Server (spring-data-rest controller)
Server (AfterXXXEvent in the spring-data-rest controller) --websocket message--> Spring websocket controller
Spring websocket controller --websocket message via topic--> all Clients interested in the topic
Server (spring-data-rest controller) --HTTP response--> client A
Scenario 2: Websocket API independent from REST API
Rules:
client request is REST/HTTP API for non-modifying operations only
response is REST/HTTP API for non-modifying operations only
client sends websocket message for all the modifying operations
websocket message is sent to client for all the modifying operations only
Well, if no other ideas come up, I'd go for the later one, but still, it would be great if I could have somehow generated C(R)UD methods exposed via websockets as well, something like spring-data-websockets and handle only the routes in my implementation.
As I feel like I'd have to manually expose (via *WebSocketControllers) all the CUD methods for all my entities. And I might be too lazy for that.
Ideas?
Scenario 2 talks about, in the last step, a single client.But I thought your requirement was for a topic since you wanted multiple clients.
If I wanted to complete 2 for your stated requirement, then you might want to maintain a list of clients and implement your own queue or use a ForkJoinPool to message all your clients listening in on your WebSockets. Having said that, A topic is definitely more elegant here but overall looks too complicated with different interfaces
For all messages from client to server, just go with a simple wire protocol and use a collection to parameterize, it could be
RParam1.......
At the server, you need a controller to map these to different requests(and operations). Somehow does not look like too much work.
Hope this helps.
The same architecture has bugged my mind for a while now and it will be a long story if I want to mention all the drawbacks and advantages of it so let me jump into the implementation.
The second scenario is valid, but as you mentioned its better to perform the crud actions on same websocket session. This shall remove the need for HTTP handshakes on every request, and reduces the body size of messages, therefore you will have better latency. Meanwhile, you already have a persisting connection to a server, so why not make good use out of it?
I searched around for a while and after 6 years from your question, I still couldn't find any websocket protocols that can make this happen, so I decided to work on that by myself cause I needed it for another dummy project.
Another advantage of such protocol could be that it doesn't require much changes to your already written controllers. So it should be able to support Spring Framework (for example) annotations and make websocket endpoints out of it.
The hard part about implementing such protocol in another framework like spring is that as its not nice to create ServletRequest and ServletResponse and convert them to your own websocket protocol, you loose some advantages. For example, any http filter you have written in your application till that moment, will be meaningless because its not really easy to pass your websocket messages through those filters.
About the protocol itself: I decided everything to be passed through json format, alongside a unique id for each request so we can map callbacks on client side to the request id. And of course there is a filter chain to add your filters to it.
Another hard to deal thing here is Spring Security as that too works like http filters in some cases. In my own lib I could finally handle annotations like #PreAuthorize but if you are using antMatchers in your HTTP Security Config, it would be a problem.
Therefore, creating websocket adapter to call http controllers will have many drawbacks.
You can check out the project here: Rest Over Websocket. Its written for Spring Boot.
I have a simple question about deploying web services. Currently I have two endPoints, see below:
Endpoint.publish("http://localhost:8000/eCalcWS/eCalc", new eCalc());
Endpoint.publish("http://localhost:8001/eCalcWS/eCalc_service", new eCalc_service());
Is it possible to have two web services on the same address? How would I do that?
Unfortunately you can not the way you want.
The design is that each endpoint is associated with web service implementor.
From spec:
The Endpoint class can be used to create and publish Web service
endpoints. An endpoint consists of an object that acts as the Web
service implementation (called here implementor) plus some
configuration information, e.g. a Binding
and on publish (my emphasis):
publish(String address, Object implementor)
Creates and publishes an Endpoint for the given implementor. The binding is chosen by
default based on the URL scheme of the provided address (which must be
a URL). If a suitable binding if found, the endpoint is created then
published as if the Endpoint.publish(String address) method had been
called. The created Endpoint is then returned as the value of the
method.
I remember I also encounter this problem quite a while back which is really bad as I needed to associate 2-3 different implementations with different URLs and it was impossible (got address already bind error).
The way I got around this if I recall was to create my own dispatcher.
I published an endpoint that accepted web service requests for multiple endpoints and dispatched the request to the corresponding implementation. I worked directly on the SOAP message.
But it was possible for me since the xml messages were really simple and quite few.
For you I would recommend to publish in different endpoints if your web service implementations are non-trivial and have complicated messages and expect a lot of clients as the endpoint really just deploys a simple http server under the hood.
I'm new to Java EE and have been struggling with some basic middleware concepts for several days now and believe I might have just had a breakthrough in my understanding of "how tings work"; a part of this question is a request for confirmation of my findings, and the other part is a legitimate question ;-).
Please confirm/clarify: My understanding of service buses/MOM (message-oriented middleware) is that they are by nature intended to process client requests asynchronously. This, as opposed to the normal request-response cycle, which is synchronous, which is usually implemented by some kind of service. In Java, such a bus/MOM could be something like Apache Camel, and the synchronous service could be something like an EJB(3). So if the client needs a request processed right away, the HttpRequest may go to a web service which then forwards the request on to the correct EJB; that EJB process the message and returns the result to the service, which then returns the HttpResponse to the client. As such, if the client has a request that does not block them and which simply needs to be processed, the web service forwards their HttpRequest on to some endpoint on a service bus and the request is treated like a message and is handled by various processors (filters, transformers, etc.).
So first off, please correct me if I am wrong in stating that an ESB/MOM solution is best suited for handling asynchronous requests, and that EJBs (again, 3.x) are best suited for responding to synchronous requests in real-time; or confirm that I am correct.
In that case, it seems to me that big applications would need both types of backends to handle synchronous (blocking) and asynchronous (non-blocking) client requests alike. So my theory would be to have my backend implemented as follows:
Use a full-blown app server like JBoss or GlassFish
In the app server's web container have two WARs: WebServices.war and ESB.war; which represent the backend "gateway" and service bus respectively
In the app server's business container have all my EJBs
Now, the WebService.war (gateway) can detect whether to relay the request on to the ESB or the EJBs
My second question is: am I way off-base here and have I missed the basic concepts of Middleware 101, or is this a half-way decent approach?
Edit: From the initial responses I already see that I was wrong in two areas: (1) that ESBs and EJBs can in fact be either synchronous or asynchronous, and (2) that, when using MDBs, EJBs can be wired up like an ESB.
So these correction pose some new mental obstacles for me:
When to go with an ESB, vs. when to go with a MDB/EJB solution; and
I really like Apache Camel's Processors API (implementation of EIPs); could I use MDB/EJBs but inside every EJB just use a Camel processor (Filter, WireTap, etc.)?
This is a big question and it deserves a big answer.
ESB's can handle synchronous or asynchronous requests and messages are typically used asynchronously.
However your backend implementation theory is pretty wrong.
JAX WS web services can run straight our of an EJB jar or an EAR and can do it that way in any app server. The EJB can put a message onto a queue or even be asynchronous.
You should not be relaying requests to the ESB but the other way around.
The ESB should be relaying and transforming requests and responses between clients and backends. One of the big ideas with ESB is that if a backend changes the client does not know or care since their contract is with the ESB not the backend.
All this said, if your application is already exposing web services, then you probably don't need an ESB and remember there is no one RIGHT or WRONG way to do something.
I do suggest that you write a more defined question that covers your specific problem, you will probably get a wealth of advice on how to solve it.
UPDATE
You also get message driven EJBs which would indeed let EJB's be chained together in a bus like fashion.
FURTHER UPDATE
So one scenario when I would use an ESB is if I need to expose non standards based services in legacy systems as a SOAP service. However there is more to consider, you should also implement a data dictionary for your organization, this will allow a greater chance that the ESB exposed services can remain the same even if your legacy system is replaced.
So as a concrete example, the organization should define in its data dictionary what a customer entity looks like, the ESB could expose a service to retrieve a customer. The ESB will perform some call on a legacy based system and then transform the result. If in future the backend system storing customers changes, the ESB exposed service can probably remain the same, and just the backend call and transformation needs to be updated.
Now hopefully with that in mind the next bit will make sense. All of this is possible with a "traditional" ESB such as JBoss ESB or Mule ESB BUT it is also possible using EJB + Camel (or other things).
The advantage of the out of the box ESB are the provided connectors, listeners and transformers. However if none of the out of the box features helps you then there is very little difference in the direction that you choose.
An advantage in home growing your ESB would be maintainability, it is much easier to find a resource who knows EJB well and can learn Camel quickly if they need to, than finding a specialized ESB resource or training a resource.
I hope that helped!
As you have noticed, the world of middleware/integration is kind of a mess in definitions and terminology. Let me clarify a bit.
A service is just a concept of "something" that delivers a capability. There are multiple ways to expose a service.
When refering to EJBs below, I mean EJBs except MDB (Message Driven Beans), which implement asychronous messaging.
Synchronously request/reply - where the reply is expected "rather soon" after the request. Usually implemented via Web Services and EJBs (RMI,etc).
As a published message to a number of subscribers that consume the data (typically price-lists are pushed out from a price-master system to various systems needing the information, such as the order system).
As a fire-and-forget message from one application to the other. Typcially, the order system needs to send an order to the invocing system, then the invocing system exposes a service to create invoices.
Conceptually, an ESB, is a soft thing. It's a concept/agreement on how a companys business services should be exposed so that applications across the company can consume/use those services. This could essentially just be a set of contraints "Only request/reply services are allowed using SOAP/WebServices and all messages should conform to the OAGIS XML standard". However, in most cases, the application/server/system environment at most companies are not homogenous. There are COTS products, mainframes with COBOL applications, .NET apps as well as Java EE applications. Therefore a common approach is to use an ESB software suite to implement the service bus in technology, or to construct adapters towards the bus. Apache Camel could be part of an ESB implementation to setup routing, transformation, conversion etc.
One thing that is tightly integrated with ESB is Message Oriented Middleware, which you speak ok. It's typically just a server that implements message queuing. The benefits from MOMs are a few in contrast to just ivoking EJBs/Web Services directly.
If asynchronous patterns (publish/subscribe, fire and forget and async. request/reply, then a relay server that has a high up time and is very stable will make it possible to, overall, have less failed transmissions of business messages.
MOMs, ususally makes it rather easy to implement adapters and an ESB that is very resilient to load peaks, network disturbances and hardware/software failure. Messages are often persistent and are stored to disk before relayed. Also transactions are often available, specifically in JMS compliant implementations. That guarantees that data is not lost on the way.
I hope I did not mess things up more than before. This is my view of this at least.