we are developing more java applications. Very simple descriptions.
frontend applications - web app, interact with users
middleware app - provide some functionality for frontend app
transport app - app which communicates with external systems.
These applications communicate with each other through xml transport over http.
Scenario from real life looks like, user create some action in frontend app, frontend app calls
middleware app, and usually middleware app calls transport app (which usually calls some other external system).
Also frontend app could call directly transport app, it depends on flow and business logic etc.
Like you see there are plenty of http calls, frontend app create http call and call middleware app and, middleware app create
http call and call transport app, transport asks some other system and send response back to middleware etc.
My question is. Is this really good architecture? Looks like too much overhead to me. There should be some other better solution,
how to transport data between apps, even they are running in one server.
Data are in 99% simple xml's, created through xstream.
Could be JMS appropriate solution for that?
Thank you
I agree with you that although it will most certainly work OK, the approach with http calls between layers is probably a bit heavy-handed.
JMS would be a very good match if the calls between the different layers are asynchronous and essentially fire and forget (you fire a message and aren't immediately interested in the outcome of the work the destination has to do when it receives your message). Although there are people who do request-reply with JMS I don't feel it's the most natural and elegant usage of a message oriented system.
If what you're doing is synchronous (you call a backend and wait for it to respond to your request) I'd go with normal (stateless) session beans, the creation and management of those has been simplified a lot in EE6.
Another advantage with EJB's is that you don't incur the overhead of the different XML serializations and deserializations that are needed in the scenario you describe.
Related
Consider this scenario: I have N>2 software components (microservices) that can communicate through two different communication protocols depending on how they are deployed. In other words, I have two deployment scenarios:
The components are to be deployed on the same machine. In this case I don't know if it makes sense to use HTTP to communicate these two components, if I think about performance. I understand that there are more efficient ways to communicate two processes on the same machine using java, such as sockets, RMI, RPC ...
The components are to be deployed on N different machines. In this case, it seems to me that it makes sense for me to use HTTP to communicate these components.
In short, what I want to do is to be able to configure the communication protocol depending on the way I perform the deployment: On a single machine, for example, use RMI, but when I deploy on two machines, use HTTP.
Does anyone know how I can do this using Spring Boot?
Many Thanks!
Fundamental building block of protocols like RMI or HTTP is socket communication. If you are not looking for the comfort of HTTP or RMI, and priority is performance, pure socket communication is your choice.
This will raise other concerns like, deployment difficulties. You should know IP address of both nodes in advance.
Another option, is to go for unix -domain socket for within server communication. For that you have to depend on JunixSocket.
If you want to go another route, check all inter process communication options.
EDIT
As you said in comment "It is simply no longer a question of two components but of many". In that scenario, each component should be a micro-service And should be capable to interact with each other. If that is the choice most scalable protocol are REST/RPC both are using HTTP protocol under the hood. REST is ideal solution for an API to be developed against a data source using CRUD operations. RPC is more lean towards action oriented API. You can find more details to identify the difference in between REST and RPC here.
How I understand this is...
if the components (producer and consumer) are deployed on the same host then use an optimized protocol and if on different hosts then use HTTP(s)
Firstly, there must be a serious driver to go down this route. I take it the driver here is performance. You would like to offer faster performance on local deployment and compartively compromised speeds on distributed deployments. BTW, given that we are in a distributed deployment world (or atleast where we are headed) HTTP will be what will survive. Custom protocols are discouraged.
Anyways... I would say your producer application should be in a self healing / discovery mode. On start-up (or periodically) it could check the health of the "optimized" end-point and decide whether it the optimized receiver is around. The receiver would need to stand behind a load-balancer. If the receiver is not up then go towards HTTP(S) and setup this instance accordingly at runtime.
For the consumer, it would need to keep both the gates (HTTP and optimized) open. It should be ready to handle requests from either channel.
In SpringBoot you can have a healthCheck implmented and switch the emitter on/off depending on the health of optimized end-point. If both end-points are unhealthy then surely the producer cannot emit anything. Apart from this the rest is just normal dependency-injection.
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.
I'm looking for some advice on the simplest way to create some product registration communication. I have a Java desktop application that needs to be re-newed every year. When a user downloads and install this app (through JNLP) they get a limited demo-version. There is code in place on the client to "register" the product and unlock all of the features.
My next step is to build the server-side components. There will be a database with customer ID numbers and other information about the customer. When the user clicks register, some contact information will be sent to the server as well as some product registration ID. The server will check this against the database and then either give the client the o.k. to unlock the features or the user will be informed that the registration id was not valid. This seems like a very standard thing. So what is the standard way to do it?
I have my own VPS and I'm running Tomcat, so I'm really free to implement this any way I choose. I was planning on building some web service, but I have never used REST before.
Use REST; REST is nothing more than using plain HTTP 'better'. Since you are already using HTTP, somehow you are already doing REST like calls and moving these calls to full fledged REST will be easy.
Implementing REST calls is easy. You have two approaches:
Low end: using URLConnection objects on the client, servlets on the server and following some REST conventions on using HTTP methods and 'clean' URLs (see here). Advantage is that you need no 3rd party library and minimize the footprint. Maintenance and evolutions are harder though.
High-end: a framework and specifications like JAX-RS. Using Restlet you can be up in running with a REST server in a couple of hours without having to deploy a servlet container.
Don't use SOAP. The only reason you would want to use SOAP is that you want to contractualise using a WSDL what you are exposing (you can do the same with REST btw, see the Amazon documentation for instance). Trust me, SOAP is way too heavy and confusing for what you are trying to do.
I'm starting to develop what should become a client-server Application using Hibernate, Spring and Eclipse RCP (for the client). This is the first time I'm designing an application from the beginning so I'm just making my first steps.
I have set up Spring on both client and server using RMI for remoting (but I wouldn't mind using something else if there was a clear advantage). So right now I'm able to call exposed services of the server from different clients to get information from the database. What I haven't done is get any kind of authentication in place, so basically the server just answers to the different clients without knowing anything about them, there is not concept of a session yet. Of course this has to change since I need different user to have different roll and so on, but right now the problem I'm facing is getting the server to notify the client when certain thing happen.
My idea to solve this problem was to have a queue of events at the Server and have the clients get them every 3 second or so. The server would then identify the client by it's session token and send the appropriate events. Yet my partner in this project is concerned that this technique (polling) might waste too much bandwidth unnecessarily.
So to bring it to the point. What are the standard techniques for a server to notify a client about changes using Spring? Please notice that I'm not developing a web application and that this is only intended to be used withing a private network. That is one of the difficulties I've been facing: every single tutorial about Spring security or remoting assumes you are making a web application, but I really don't want to get lost into the details of Spring MVC and web applications in general.
Any resources would be appreciated. A good and long tutorial on the matter would be great.
EDIT: Hmm, it looks like JMS might be what I'm looking for.
As I understand, the issues you are facing is identifying a client in request and correlate different client request i.e. have something like a session.
Spring also support RMI over HTTP protocol (Using Hessian and its own HTTP Invokers). Check out this link (Section 17.3). Now once you have transport as HTTP, it has inherent Basic Authentication and session which can be leveraged to get around the issues you are facing.
This is just a pointer. I would be curious to know how eventually you resolved your problem.
I have to design a distributed application composed by one server (developed in Java) and one or more remote GUI clients (Swing application with windows).
As stated before the clients are Swing GUI application that can connect to the server in order to receive and send data.
The communication is bidirectional (Server <=> Clients).
Data sent over the network is mainly composed by my domain logic objects.
Two brief examples: a client calls the server in order to receive data to populate a table inside a window; the server calls client in order to send data to refresh a specific widget (like a button).
The amount of data transmitted between server and clients and the frequency of the network calls are not particularly high.
Which technology do you suggest me for the server-clients communication?
I've in mind one technology suitable for me but I would like to know your opinions.
Thanks a lot.
The first technology that came to my mind was RMI - suitable if you're communicating between java client and java server. But you may get difficulties if you want do switch the client technology to - say - a webinterface.
I would go with RMI but implement the whole architecture using Spring framework. This way it is independent of technology used and can be switched to other ways of communication (such as HTTP or other ) with almost no coding.
UPDATE: And Spring will allow you to have none of RMI specific code.
I believe sockets should do the trick. They are flexible and not especially hard to code/maintain. Most entry level programmer should also be able to maintain them. They are also fast and adapt to any kind of environment.
Unless, your server is going to be off-site or you expect to have firewall issues. In that case, web services are the way to go since your basic communication happens through port 80.
I would second msparer's suggestion of RMI, except I would just use EJB3 (which uses RMI as the communication protocol). EJB3 are very easy and even if you don't use the other feaures EJB gives you (e.g., security) you can still leverage Container Managed Transactions (CMT). It really does make development easy.
As for the server->client communication, you would probably want to use JMS. Again, using EJB3 this is pretty e3asy to do with annotations. The clients will subscribe to the message service and receive update notifications from the server.
And yes, I am currently working on an application that does this very thing. Unfortunately we are using EJB2.1. Still, it is my opinion that this is where EJBs really shine. Using EJBs in a web app is frequently overkill, but in a distributed client/server app they work very well.
You can try using ICE http://www.zeroc.com for establishing server-client connection.