Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I have two Java EE web apps that are going to be published on the same physical server, but on different network addresses.
APP A: Listens to a port on a public IP address and makes synchronous invocations to app B if necessary.
APP B: Listens to a port on a private IP address and makes synchronous invocations to app A if necessary.
For connecting APP A with APP B, I am considering the following alternatives.
RMI
Message Queue
Lightweight ESB
Please tell me if you see any clear advantage supported by facts on any of them, or if there's another technology I should consider.
Every integration method has its advantages and disadvantages, and its really hard to propose one based only on what you have provided, but here is some hints:
Quick and Easy: if you don't mind high coupling, and major changes in the applications are not expected (like DB engine, or replacing on with non-Java system), you can go with RMI or even DB Procedure calls.
Changes, Extendability and Scalability: if the applications are expected to be changing more than rarely -and they tend to do-, ESBs or Message Queues would be great, since they would produce a loosely coupled architecture. This would also make room for extendability (like if you would have a new application C, that would need to invoke A or/and B)
HTTP Availability: If HTTP communication is available between applications, Web Services is an excellent integration method.
Developers Knowledge: What technologies you/the team are familiar with.
These are actually small hints, if you wish to go further in your research, I strongly recommend reading Enterprise Integration Patterns the book.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
What are some major distinctions between EJB and the other technologies that perform the same function, and why is there such focus on the technologies that are, or are not supported, as opposed to other systems that refer to things such as "supporting EJB" as a feature that is either there, nor not?
The original concept of EJB was much closer to what are now called microservices, where the individual components could be deployed across a variety of different servers (EJB containers).
Whereas modern microservices mostly use HTTP calls or message queues, however, EJB communication happened over a Java-specific protocol called RMI, which uses Java serialization to route method calls across the network more or less transparently. This network intermediary is the reason for needing an interface (in earlier versions of EJB, it was even more complex!): On the "local" side, the object actually behind the interface is a proxy that will serialize your method call and transmit it to wherever the EJB implementation is deployed.
Java EE (Enterprise Edition) includes a collection of features that cover a wide variety of "enterprisey" operations, including transactions, service directories, persistence, Web (Servlets), and distributed method calls. Tomcat is calling out that while it implements the Servlet API, which is one part of Java EE, it doesn't implement all of these other components, and if you need them you'll need a different container, such as GlassFish or WildFly.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
What is the best approach in java to call a C function running on another server? My application written in Java and running on an application server on server 'A' and I need to call a C function running on another server 'B' that doesn't have java installed.
Should we build a web service on server B to accept requests from my Web application on server A? or just call it remotely using RPC? and what is the performance of both?
First of all:
Just call it using RPC
There is no such thing as "just" when talking RPC. Unless you already have some CORBA or whatever solution in place, you will have to invest a serious amount of time to get this working.
Using a web service adds multiple layers of abstraction, which can affect latency. But of course, that is the more flexible solution.
I think it is fair (in 2018) to state: a reasonable architecture would provide some sort of (restful) HTTPS service on B. You should only look into other options if there are hard pressing reasons.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
So usually, to have get and set methods in networking Java I use an enum, for example:
public enum MyEnum {
GET_NAME,
GET_ADDRESS;
}
etc. which the client application and server application would send between each other as a string and the appropriate task would be carried out.
I wanted to know how applications do this usually? What data do they send through the socket to make the program work, do they use ObjectStreams? Do they send bytes?
Wanted to know what the best practice would be to have a client-server setup for my own messaging application.
EXTRA INFO:
The client / server network I'm designing is for a PLUGIN in a GAME and therefore has to be instant / speedy ;)
All of that. Or something else.
The "industry" standard can be many things, depending on the domain you are looking at, or the decade when the solution was designed.
In 2018, most "new" client/server communication that gets defined doesn't operate on socket level. You rather define a set of restful APIs that the server offers, and data flows as JSON strings for example.
In other words: the official answer here is: there is no such as an industry-wide standard. To the contrary: what you are asking about (sending individual comments on socket level) is probably the exception, and not something that is common for real world architectures. People don't think in sockets and single commands. They think in terms of protocols, abstractions, maybe "remote procedure calls".
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
I were wondering what's the proper way to create a chat/communication software in Java for Android?
I guess it's a Socket (TCP/UDP).
If I do it my own way like using a web calls for PHP with backend scripts why it is not so appropriate way to create a chat? What's the difference between them? Using a calls instead of raw sockets? Does it use more battery or something? I just feel that sometimes it would be more easier to parse a JSON for messages and send data through web calls, but I feel that it's not a proper way to do so and application may have a critical issues like draining a battery or something which will make the project to be discontinued.
I would like to be sure is there any other ways to create a chat, than sockets and do every famous developers use a sockets as primary method for creating a communication software?
The protocol could be Socket or others such as XMPP
If you prefer using Socket, SmartFox might be one of the libraries that you can rely on. Smartfox offers SDK for a number of languages such as C#, Java etc.
Note however, that if you use socket for communication, usually json is NOT used, since most of the times, binary objects are used in the socket-based communications, say for example, SmartFox uses ISFSObject, which wraps all the data into a binary object.
Below posts might be useful for you to get started, though it is not written in java, but essentially the workflows are exactly the same.
Using SmartFox with C# (I) : Installations and 1st handshaking
Using SmartFox with C# (II) : Login and join room
Using SmartFox with C# (III) : Frequently used functions
Apart from the socket and xmpp appraoches, you can also opt to use WebRTC, where there is no such kinds of servers, and peer to peer communication is used. A good tutorial can be found here.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
Background:
I work in a organisation, uses hundreds of software systems, we identify which system owns which category of data, then carefully select the data we want to expose to the other systems. then pull them into a single Oracle database.AKA master data.
then each system read the status of the other system through this shared database pattern.
Problem:
access control, data handling, and lack of event notification, logic routing caused us lots of time and effort. We want to add a ESB layer in front of the
Potential Solution:
we are looking at SOA at moment, in specific Enterprise Service Bus Pattern.
we aware there are options like Camel, Mule and ServceMix. But I wander is there any resource, can assists our implementation?
is there any project been done the same way, e.g ESB fronting a Oracle database access?
I don't think you'll find much in this strict sense. ESB is basically made for transferring messages between enterprise services. A DB is not an enterprise service. In this case you'd need processing beans that handle your specific need.
What you could do, however, is to put a service in front of your DB. This service could then expose the DB in some format. For example, SOAP over JMS seems fitted to your use case. SOAP can handle security and access, JMS gives you asynchrousness and exactly-once delivery guarantee, which will be needed if working with a DB. ESB frameworks can handle JMS and SOAP very well.
So instead of looking for a "ESB backed database", as you called it, this service may be something that you can look for on the market, and then you can route client services by using an ESB, which makes sense.