Good points, Julien. Let me elaborate:
Actually an ability to decouple protocol adapters from service implementation is a huge advantage. For example:
a) your service consumes from AMQP only, while you can attach many protocol adapters to the same bus. In practice it means that you can easily expose your service using a variety of APIs. So I can create a service Foo consuming from IoT Connector (AMQP) only and at the same time expose this service via MQTT, REST, CoAP, WebSockets, etc. All the protocol conversion are automatically handled by IoT connector + protocol adapters.
b) this model of architecture is "cloud-friendly" (aka "PaaS-friendly"). You can easily scale out your application by scaling IoT connector, protocol adapters and services. I can imagine putting those components into Docker+Kubernates and taking advantage of auto-scaling features.
c) this model make it easier to provide IoT infrastructure and business logic (services) separately. It is extremely important from the business point if view, as it allows you to distinguish dedicated IoT infrastructure teams and dedicated services teams.
d) IoT infrastructure (IoT connector + protocol adapters) communicating indirectly with the services is easier to extract and reuse. It makes it cheaper and more stable then IoT infrastructure created from scratch for every project.
e) IoT infrastructure working independently from services is easier to productize, and therefore - monetize.
> When the device connect or send a message you need to read
> the scenario state and make a decision on the next message to
> send (simple HTTP call works here, without needing to install
> any middleware).
Services communicating via HTTP are less resistant for failures. If service A calls service B without middleware, it is the responsibility of a service A to retry if B is down for a moment. Client side load balancing is usually more complicated to develop and maintain (even with libraries like Apache Camel or Netflix Ribbon), than relying on the messaging to do this job for you.
Messaging gives you also some communication patterns that make it easier to scale out communication (like fan-out or competing consumer).
Finally relying on messaging is much easier for a large scale PaaS/cloud deployments where new nodes can be easily added or destroyed, as you don't need service discovery, load balancing, etc.
> In my opinion bus/queue is something you can keep out of the picture
> in the first step.
Actually I believe it is essential for us to agree on the communication pattern before we proceed. I personally would say +1 for AMQP 1.0 as it is interoprable between all platforms (Java, .Net, Ruby, Python, Node.js etc.). It is also a mature protocol with many existing implementations that have proved to be solid and scalable.
Cheers!