The term "Microservice Architecture" is now a popular term. Unlike many trends this one seems to have some momentum and is more about how people are actually developing services versus vendors commandeering and needlessly complicating something simple.
There is no concrete definition of Microservice Architecture but there are certain aspects that are thematic in its application. The focus on Microservices is a focus on business capability, and a refocus on object oriented roots and organizing code around business domains with data and business rules co-located in the same process or set of processes.
Microservices recognize that the world is polyglot programming, and the easiest integration is around JSON, HTTP and other web standards like WebSocket. Microservices embrace smart endpoints and dumb pipes.
Microservices is not SOA. In fact, it in many ways it is directly the opposite. For example SOA often embraces WSDL which is a very strongly typed and rigid way to define a service end point. A Microservices embrace JSON and tolerant readers with the idea that the interface may change a bit and it is nicer to allow some flexibility in what properties/fields make up a message. A smart end point and a dumb pipe would be the opposite end of the spectrum then something like BPEL and ESB provides or other orchestrations mechanisms for SOA. While SOA embraces services being stateless, Microservices embrace the need for state and embrace OOP fundamentals of keeping your business logic and data together. Read the SOA manifesto, and read the wikipedia page on SOA, try to do the exact opposite and you are a good ways down the road of adopting a Microservice architecture. Shun statelessness and embrace sharding, replication, eventual consistency and service data ownership. Shun WSDL and embrace JSON.
More to come.
Check out this Java Microservice lib in the mean time...