We Keep Coding

MICROSERVICES - communication between them

I've got one question concerning microservices architecture. I am designing a system based on microservices. I've read few articles and I think I understand the idea. However, I don't how microservices should communicate with each other while they have separate business responsibilities....
What I mean is that if I have a system for booking train tickets, I would divide backend application into modules:
Client (login,logout,registration)
Reservations (booking a train seat for user,getting all reservations for user)
ConnectionsDetails
(searching for connections,getting connection details)
Trains
(information about trains- seats number,class etc.)
Now, I can only think that if user search for connections module ConnectionsDetails communicate with Trains module and ask about particular train details. But how could other microservices communicate? If user wants to login - she/he asks directly Client module, if she/he wants to get all her reservations - asks Reservation module DIRECTLY etc...
So my question is, how should modules communicate if they do different things? I'm sorry if my question is trivial or stupid, I'm just starting with microservices.
EDIT:
I didn't mean what tools could I use for communication. My question is about logic. In the example I showed, why one microservice could ask another microservice about sth if client can directly ask the another one? As I said earlier, how they should communicate(about what should they ask each other exactly) if they do separate things?

To find the right contexts, borders and communication channels is imho one of the most difficult parts of a microservice architecture. It is about finding the data you need, how the relationships are and which service is responsible for what (responsible means the only one allowed to change it). Have a look at the Blog from Martin Fowler.
Microservices is not modules. Each service should be an independent service regarding development and deployment. And yes, they may communicate to each other but a client may also communicate to them individually. The Microservice approach is also about using the right tool for the problem. So each service can be implemented in a different programming language. They can use different kind of storage like RDMBS, NoSQL or Key-Value store. An they will be scaled individually - many instances for ConnectionsDetails and fewer for Reservations e.g.
What will happen if one service is not available? Each service should be as fault tolerant as possible and try to decrease it's service gracefully if nothing else is possible. You should think about minimising the needed communication between the services by choosing the right borders, make data independent and maybe introduce caching. Don't forget about the CAP theorem, a microservice approach makes it more visible. Here are some slides about resilience that may help. Do not share the same database or replicate everything between services.
"how should modules communicate if they do different things?". You should choose a language independent way of communication and depending on your problem a synchronous or asynchronous method. As a language independent format JSON or XML are most common. Synchronous communication can be based on REST, asynchronous communication on messaging. The authentication ("Client") is typically a REST service, sending the booked tickets via Email is more a message driven asynchronous service.

As I think that is a major question about classical SOA vs. Microservices.
I guess you can find many opposite answers to that.
so IMHO:
If in your architecture services communicate each other they are not microservices, since there are dependencies between them.
Instead of that if each microservice has all needed functionality (or say components) and do not depend or communicate to each other then they are microservices.
So in your example you have 4 components.
Clients, Reservations, ConnectionsDetails, Trains.
But, microservices may not necessary match them exactly.
As you said "if user search Connection"...
So "Search Connection" that is microservice which includes all needed components (Client, ConnectionDetails, Trains) and is independent.
And finally, how components (not microservices) will communicate to each other is up to you. With microservices you have a luxury to use straight POJO with no transformations, protocols, transport layers at all.
Or you can make communications more formal, which push you back closer to classical SOA rather than microservices.

building a web application in eclipse

As a concluding assignment for the technologies taught in a data management course, we have to write a web application using the technologies taught throughout the course, this mostly includes xhtml, css, JSP, servelets, JDBC, AJAX, webservices. the project will eventually be deployed using tomcat. we are given the option of choosing the technologies that we see fit. since this is my first time developing a web application I am having some uncertainties about where to start, so for example now I am writing the object classes that will be used in the database and implementing the operations that will be performed on the database, but I am not sure about how to make these operations available to a client through the website, I mean I think I have to write a servlet through which I can extract the request parameters and set the response accordingly, but I would still like a more specific overview of what I am going to do, so if someone can link me to a tutorial with an example that makes use of these technologies while illustrating the stages of the design so that I can see how all these things are linked together in a web project.
thanks

Java Enterprise applications typically use a layered architecture as illustrated below:
In short:
The presentation layer provides the application's user interface. In a web application, this typically involves the use of a MVC (Model-View-Controller) framework.
The service layer exposes coarse grained services implementing the business logic of an application. They act as entry point and are typically responsible of transaction demarcation.
The data access layer abstract physical storage systems (e.g. a database) and expose CRUD (Create, Read, Update, Delete) methods and finders.
Domain objects represent the business concepts of your domain (Client, Order, Product, etc) and are typically used across all layers, from the data access layer to the presentation).
I don't want to make things too confusing and to throw in too much technologies or frameworks (are you allowed to use frameworks?) that could fit in this diagram. Just tell me if I should.
Regarding your question about the presentation layer, I already hinted the answer: use the MVC pattern.
Basically, the View is the part that renders the user interface (e.g. JSP). From the view, the user sends input to a controller (a Servlet acting as entry point). The controller communicates and interacts with the model (standard Java classes), set appropriate data in the HTTP request or Session and forwards the request and response to a view. And this restarts the cycle.
If you need more details, let me know.

Baby steps are needed. Get something running and then expand on it.
Start with this tutorial, get it running and then start asking questions http://www.eclipse.org/webtools/community/tutorials/BuildJ2EEWebApp/BuildJ2EEWebApp.html
This will give you a Servlet and a JSP running on Tomcat from Eclipse. From there you can expand.

Sun documentation is pretty good: The Java EE 6 Tutorial, Volume I.
There is also a working sample application released by the Java BluePrints program at Sun called the Pet Store Demo.
I have also put together a string of tutorials aimed at beginners who are wanting to learn how to build Java web applications (within the Eclipse environment). I have tried to keep it as simple as possible.

In web project can we write core services layer without knowledge of UI?

I am working on web project. We are using flex as UI layer. My question is often we are writing core service layer separately from web/UI layer so we can reuse same services for different UI layer/technology. So practically is it possible to reuse same core layer services without any changes/addition in API with different kind of UI technologies/layers. For e.g. same core service layer with UI technology which supports synchronized request response (e.g. jsp etc.) and non synchronize or event driven UI technology (e.g Ajax, Flex, GWT etc.) or with multiple devices like (computers, mobiles, pdas etc.). Personally I feel its very tough to write core service layer without any knowledge of UI. Looking for thoughts from other people.

It is possible of course. Services layer is most often stateless, so it just offers methods to be called with parameters that come from the UI. You can imagine it as an API that you call from your UI layers. It is important not to pass anything UI-related as a parameter. For example, don't pass HttpServletRequest or HttpSession as parameters - obtain the values needed and pass them.

My question is often we are writing
core service layer separately from
web/UI layer so we can reuse same
services for different UI
layer/technology
The service layer should be agnostic of the UI, so that's actually very good.
For e.g. same core service layer with
UI technology which supports
synchronized request response (e.g.
jsp etc.) and non synchronize or event
driven UI technology (e.g Ajax, Flex,
GWT etc.) or with multiple devices
like (computers, mobiles, pdas etc.).
A business operation exposed in a service layer should theoretically not depend on who calls it and which technology. But you seem to be facing to common symptoms:
different UI do actually require slightly different business operations (e.g. the amount of data returned may differ for mobile and non-mobile caller)
the business operations is coupled with the remoting technology (e.g. synchronous vs. asynchronous)
For 1. the question you must ask yourself is whether you can factor these slightly different operations elegantly, or the opposite, how to expose variations of the same operations elegantly. In both cases, it should be possible to design a service API that is consistent and fit the need of various clients.
For 2. the question you must ask yourself is how to decouple the business operations from the remoting technologies. A bridge or adapter or an extra mediation layer could be introduced, but that should not lead to over-engineering.
I know it's sometimes hard to decouple the business operation completely from its actual usage. Let's consider pagination: if the business operation is "I want data for query X", the concrete operation exposed does also embed some knowledge of the UI, namely the paging.
I can only provide a general advice: fight for a clear separation between UI and business when it comes to data, formatting, etc. and when you can't, try to figure out the most generic API that makes sense for all clients.
Personally I feel its very tough to
write core service layer without any
knowledge of UI.
I agree it's hard sometimes, but you seem to be doing it right -- so continue this way :)

It shouldn't be difficult to write core services without knowledge of the UI at all.
The core services just need to know what data is needed to perform their tasks (where it comes from doesn't matter).
Once you have the core services designed, you can then build several different UIs on top of them that collect the necessary data and pass it to the services...which would then perform their specific duties.

What remoting approach for Java application would you recommend?

I wonder how is the best way to integrate Java modules developed as separate J(2)EE applications. Each of those modules exposes Java interfaces. The POJO entities (Hibernate) are being used along with those Java interfaces, there is no DTO objects. What would be the best way to integrate those modules i.e. one module calling the other module interface remotely?
I was thinking about: EJB3, Hessian, SOAP, JMS. there are pros and cons of each of the approaches.
Folks, what is your opinion or your experiences?

Having dabbled with a few of the remoting technologies and found them universally unfun I would now use Spring remoting as an abstraction from the implementation.
It allows you to concentrate on writing your functionality and let Spring handle the remote part with some config. you have the choice of several implementations (RMI, Spring's HTTP invoker, Hessian, Burlap and JMS). The abstraction means you can pick one implementation and simply swap it if your needs change.
See the SpringSource docs for more information.

The standard approach would be to use plain RMI between the various service components but this brings issues of sharing your Java interfaces and versioning changes to your domain model especially if you have lots of components using the same classes.
Are you really running each service in a separate VM? If these EJBs are always talking to each other then you're best off putting them into the same VM and avoiding any remote procedure calls as these services can use their LocalInterfaces.
The other thing that may bite you is using Hibernate POJOs. You may think that these are simple POJOs but behind the scenes Hibernate has been busy with CGLib trying to do things like allow lazy initialization. If these beans are serialzed and passed over remote boundaries then you may end up with odd Hibernate Exception getting thown. Personally I'd prefer to create simple DTOs or write the POJOs out as XML to pass between components. My colleagues would go one step further and write custom wire protocols for transferring the data for performance reasons.
Recently I have been using the MULE ESB to integrate various service components. It's quite nice as you can have a mix of RMI, sockets, web services etc without having to write most of the boiler plate code.
http://www.mulesource.org/display/COMMUNITY/Home

Why would you go with anything other than the simplest thing that works?
In your case that sounds like EJB3 or maybe JMS, depending on whether the communication needs to be synchronous or asynchronous.
EJB3 is by far these easiest being built on top of RMI with the container providing all the additional features you might need - security, transactions, etc. Presumably your POJOs are in a shared jar and therefore can simply be passed between your EJBs, although I tend towards passing value objects myself. The other benefit of EJB is, when done right, that it's the most performant (that's just my opinion btw ;-).
JMS is a little more involved, but not much and a system based on asynchronous communication affords certain niceties in terms of parallelizing tasks, etc.
The performance overhead of web-services, the inevitable extra config and additional points of failure make them, IMHO, not worth the hassle unless you've a requirement that mandates their use - I'm thinking interop with non-Java clients or providing data to external parties here.

If you need network communication between Java-only applications, Java RMI is the way to go. It has the best integration, most transparency and the least overhead.
If, however, some of your clients aren't Java-based, you should probably consider other options (Java RMI actually have an IIOP-dialect, which allows it to interact with CORBA, however - I wouldn't recommend doing this, unless it's for some legacy-code integration). Depending on your needs, webservices are probably your friend. If you are conserned with the networkload, you could go webservices over Hessian.

You literally mean remotely? As in running in a different environment with therefore different availability characteristics? With network overheads?
Assuming "yes" my first step would be to take a service approach, set aside the invocation technology for a moment. Just consider the design and meaning of your services. You know they are comparativley expensive to invoke, hence small busy interfaces tend to be a bad thing. You know that the service system might fail between invocations, so you may favour stateless services. You may need to retry requests after failure, so you may favour idempotent service designs.
Then consider availability relationships. Can your client work without the remote system. In some cases you simply can't progress if the remote system isn't available (eg. can't enable the employee if you can't get to the HR system) in other cases you can adopt a "fire-and-tell-me-later" philosophy; queue up the requests and process responses later.
Where there is an availability depdency, then simply exposing a synchronous interface seems to fit. You can do that with SLSB EJBs, if everything is Java EE, that works. I tend to generalise expecting that if my services are useful then non Java EE clients may want them too. So SOAP (or REST) tends to be useful. These days adding a web service interface to your SLSB is pretty trivial.
But my pet theory is that any sufficiently large IT system ends up needing aynch communications: you need to decouple the availability contraints. So I would tend to look for a JMS-style relationship. An MDB facade in front of your services, or SOAP/JMS is not too hard to do. Such an approach tends to highlight the failure-case design issues that were probably lurking anyway, JMS tends to make you think: "suppose I don't get an answer? suppose my answer comes late?"

I would go for SOAP.
JMS would be more efficient but you would need to code up an message driven bean for each interface.
SOAP on the other hand comes with lots of useful toolkits that will generate your message definition (WSDL) and all the neccesary handlers (client and server) when given an EJB.
With soap you can (but dont have to) deal with certificate security and secure connections over public networks. As the default protocol is HTTP over port 80 you will have minimal pain with firewalls etc. SOAP is also great for hetrogenious clients (in your case anything that isn't J2EE) with good support for most common languages on most common platforms.

Message Oriented Middleware (MoM) Vs. Enterprise Service Bus (ESB)

I come from a background of MoM. I think I understand ESB conceptually. However, I'm not too sure about the practical differences between the two when it comes to making a choice architecturally.
Here is what I want to know
1) Any good links online which can help me in this regard.
2) Can someone tell me where it makes sense to use one over the other.
Any help would be useful.

Messaging tends to concentrate on the reliable exchange of messages around a network; using queues as a reliable load balancer and topics to implement publish and subscribe.
An ESB typically tends to add different features above and beyond messaging such as orchestration, routing, transformation and mediation.
I'd recommend reading about the Enterprise Integration Patterns which gives an overview of common patterns you'll tend to use in integration problems which are all based above a message bus (though can be used with other networking technologies too).
For example using open source; Apache ActiveMQ provides a loosely coupled reliable exchange of messages. Then you can use Apache Camel to implement the Enterprise Integration Patterns for smart routing, transformation, orchestration, working with other technologies and so forth.

I put MOM solutions and ESB solutions on two distinct planes.
I consider MOM a building block for ESB solutions. In fact, ESB solutions reach their own loose coupling and asynchronous communication capabilities, just using the paradigm offered by the specific MOM implementation.
Therefore, MOMs represent solutions for data/events distribution at customized level of QoSs (according to the specific vendor implementation), instead ESBs represent solutions providing capabilities to realize complex orchestrations in a SOA scenario (where we have multiple providers offering their services, and multiple consumers interested in consuming the services offered by the first ones).
Complex orchestrations imply communication between legacy systems, everyone of these with its own data domain representation (rules and services on specific data) and its own communication paradigm (one consumer interact with the ESB using CORBA, another one using WS, and so on).
It is clear that ESB represents a more complex architectural solution aimed to provide the abstraction of data-bus (such as the electronic buses that everyone have in his own pc), able to connect a plethora of service providers to a not well specified plethora of service consumers, hiding heterogeneity in (i) data representation and (ii) communication.
Sorry for the long post, but the concepts are complex and it is very difficult to be effective and efficient in a short statement.

An ESB is typically a layer that routes, logs, transforms, and performs other 'technical' (i.e. non-business) functions on messages. It could process messages from a messaging system (such as something JMS-based), or it could work with other types of message (such as SOAP-based web services). In that respect, it's more general than MoM.
Disclaimer: I am an IBM WebSphere consultant - although I am not contributing here in an official capacity.

ESB with web services in its true form provides Application loose coupling by sending the data through one the elements of the message.
MOM provides not only Application Loose coupling but process loose coupling along.
ESB comes with additional features supporting Governance centric approach.
Both can be used independently or together depending upon the scenario.

IBM and Oracle have SOA certifications. Since they're the leaders in the marketplace (Gartner Magic Quadrant), I would read about how they define SOA and ESBs (along with methodology and the components needed to support SOA like Governance, Registry, etc etc)

EBS is just yet another buzzword, as is SOA 2.0.
You can have a ESB system easily implemented with normal Web Services with a queue behind them.
You can have message routing and or orchestration with SOA 1.0 (Tibco, BizzTalk), one things does not stop the other really. More importantly, it is the semantics given to the messages exchanged in the system that play an important role, in this case events. Messages as events, are triggers about something that happened in your system, so the context is different.