Wamp on Felix Seifert

autobahn-spring: Autobahn|Java and Spring

Sun, 27 Jan 2019 16:24:36 +0000

Are you an enthusiastic user of Spring and do you also want to benefit from the Web Application Messaging Protocol? Even though wamp2spring mainly serves as a router, Spring users often want to create several microservices communicating with each other. A comfortable solution is using the WAMP library Autobahn|Java. This article will describe how to combine Spring and Autobahn|Java.

Create a Controller for WAMP

Autobahn|Java could be implemented as a controller. Therefore, the bean of Spring should be created with the annotation @Controller. Topics and procedures could be handled exactly as described in the article about Autobahn|Java. The methods implementing this should be registered as listeners. This could be achieved in the constructor of the controller.

wamp2spring: Topics and Procedures

Fri, 02 Nov 2018 17:36:02 +0000

wamp2spring offers the option to serve as Web Application Messaging Protocol (WAMP) router publishing on topics and registering remote procedures. The article wamp2spring - Router for WAMP has already described how to set up a router with wamp2spring. In this article, we would learn how the router could publish on topics and register remote procedures. Understanding RPC and Pub/Sub might be quite helpful for creating microservices communicating via WAMP. The different ways of communicating via the protocol are described in the article Web Application Messaging Protocol.

wamp2spring - Router for WAMP

Sun, 21 Oct 2018 14:57:56 +0000

As I am a strong advocate of Spring Boot, I would present you with another way to set up a router for the Web Application Messaging Protocol (WAMP). This is based on the Java library wamp2spring and Spring Boot (you could also use the Spring framework). Besides setting up one or multiple WAMP clients (for example with Autobahn|Java), a router is needed so that the clients could communicate with each other via WAMP. I have already described the idea in the article Web Application Messaging Protocol. Even though there are multiple options for settings, it is quite convenient to set up a router with the default settings. A wamp2spring router itself could register remote procedures, as well as publish on topics, which could be addressed by the wamp clients. This article would present a solution of a router that does not register or publish.

Autobahn|Java - WAMP Library of Crossbar.io

Sat, 13 Oct 2018 19:35:04 +0000

You have already learned how to set up a local Web Application Messaging Protocol (WAMP) router. This article would describe how to make the first step in programming a microservice in Java using the library Autobahn|Java and, thus, how to use a WAMP router.

Idea of Autobahn|Java

A WAMP network usually consists of a router and multiple clients. The clients are often microservices which are part of, at least, one bigger service. While being connected with the router, these microservices can communicate with each other. The article about WAMP describes the different ways of communicating via this protocol. It is not relevant in which programming language the clients are being implemented, Autobahn|Java is the library of Crossbar.io to implement a client for a WAMP network specifically in Java. It is based on the framework Netty, which is used for asynchronous programming.

Local Crossbar Router for WAMP

Sun, 07 Oct 2018 12:55:32 +0000

When writing your own programme(s) using WAMP, they have to be connected to a WAMP router to be able to communicate with each other. There is a whole bunch of implementations you could use for running a router. In this article I will describe how to set up a local Crossbar.io router.

Why a Local WAMP Router

Web Application Messaging Protocol (WAMP) is a protocol which could be used by many (micro-)services to communicate in a network. The programming languages used by the (micro-)services do not matter and they also do not have to know the address of each other. This means that they could be run anywhere as long as they are connected to the router, they only tell the router where they could be found. Therefore, the router is an integral part of a network using WAMP. Crossbar.io runs a demo instance of its router which could be accessed by anyone. This sounds easy but involves some setup of your internet connection. The easier way would be setting up your own local router. In addition, you could use it for your own development when developing with others: When starting to code your own service from scratch while being connected to a remote router, others will probably not be able to access a stable version of your microservice. Therefore, you could run a simple mock-up for them remotely and develop the proper microservice locally.

Web Application Messaging Protocol

Fri, 05 Oct 2018 13:40:28 +0000

In the last Fiction2Science Hackathon, I learned to apply the Web Application Messaging Protocol (WAMP) for communication of services in the cloud. In this article, I will describe the protocol a little bit more detailed and refer to the implementation of Crossbar.io.

The idea of the Web Application Messaging Protocol (WAMP)

Lots of people might know Representational State Transfer (REST) APIs. This architectural style sets a group of constraints that allow services on the web to communicate. A caller calls a certain URL and passes some information to the callee. Afterwards, the caller of the URL would receive an answer from the callee. As long as multiple callers know the URL of the API, it could be called by multiple services. However, multiple callees are not possible. This is known as a Remote Procedure Call (RPC).

Fiction2Science: WAMP and Microservices

Fri, 05 Oct 2018 13:35:49 +0000

Last weekend, I attended the hackathon Fiction2Science of Continental. I was assigned to the Cloud Challenge where we dealt with the communication between microservices in the cloud.

The Cloud Challenge

After the official welcome, we gathered at our challenge areas with around 20 people participating in each challenge (total of 7 different challenges). Each participant indicated what his focus area is (frontend, backend or design). Based on this indication, we autonomously formed teams of four to five participants. Eventually, our team consisted of only three participants: one person focusing on design and frontend development, one developer who engaged in both frontend and backend development and me. In the beginning, I dealt mainly with backend development but eventually, I was also responsible for the presentation. At first, we learned the technique how our developed microservices would communicate. To help with this, we had a simple tutorial with some tasks that we had to solve. Then, we tried to understand how to use our programming language to publish and subscribe to topics and how to register remote procedures and call them. We continued to solve tasks to understand these required techniques a little bit more. Having learnt these techniques, we then developed our own service by combining several microservices. Finally, we had to present our own service in front of a panel consisting of professional Software Engineers and Innovation Managers.