Doorgaan naar hoofdcontent

Posts

Book review: Building Evolutionary Architectures

Key Takeaways             Three primary aspects of evolutionary architecture: fitness functions, incremental change and appropriate coupling Design for change on multiple dimensions (technical, data, security and operational) Combine DevOps (Continuous Delivery) practices with fitness functions to verify the architecture       Migrate to another architecture for good reasons (for example better team structure and operational isolation), not because “it’s the current trend” Building Evolutionary Architectures is a promising title for a book. I was also triggered and wanted to read the book. This is a review of the book with my own humble opinion. First a short description of the chapters is given. Chapter 1 - Software Architecture A definition of evolutionary architecture is described, which states that it supports guided, incremental...

Microservices reference architecture, tools and frameworks

"The Microservices train" made by Roger van de Kimmenade (see my Photos page ) Intro I am a fairly newby within the Microservices world but I have more experience with Service Oriented Architecture, Event Driven Architectures and more. So lately I began to read more about the architecture style of Microservices. In each blog item or news item I come across a new name of a tool/framework. So the idea came to try to make a reference architecture and a toolsheet in which each tool is mapped to that reference architecture. I have come to a state that I can use your help! Which concepts are missing and which tools can I add? Please leave comments. Reference Architecture This is my first go of a kind of hybrid Microservices reference architecture, in which an integration layer is used to expose COTS products and legacy. Tool/framework sheet The next sheet is freely available and contains a list of tools and frameworks, that can be used within the Microservi...

Microservices Conference 2018 in Berlin - A small recap

Conference On the 22 and 23rd of March i went to the "Microservices Conference 2018, MicroXchg" in Berlin. This blog post is a short recap of my experience of this conference, which was held for the 4th time. My goal was to learn more about the Microservices world, to fill my toolset of possible architecture solutions and of course to see Berlin a bit. Furthermore i interviewed Chris Richardson about Microservices and his upcoming book on Patterns. This interview is added to this blog as well. A note: everything within this blog is purely my own opinion. Location The location where the conference was held, was Kalkscheune in Berlin. A nice location with big conference rooms. There were 5 different rooms and everything was recorded. Overall program There were 4 parallel sessions with 1 indepth-session. The normal sessions were 50 minutes long, so this was a good time to get some more detailed information and there was also time for questions. As i wan...

Lets take you through some new features of WSO2 API Management 2.0.0

WSO2 has recently released a new version of the API Manager: version 2.0.0. So what are the new features of the product? I will take you through some new features. Packaging The API Manager consists of three packages to be downloaded: API Manager Tooling (For Eclise) Analytics (Full fledged Data Analytics Server, ready to be used) Traffic Manager The API Manager has a new component besides the Publisher, Store and Key Manager, and that is the traffic manager. This component handles the throttling policies. Advanced throttling With the previous product it was possible to set throttling limits, i.e. 20 calls per minute allowed. With the new possible some more advanced policies can be configured. Filtering based on properties. IP Address and range http request headers JWT claims Query parameters Custom Rules Note that this dialog is shown when logging into the admin console: https:// :9443/admin Also custom throttling policies can be conf...

WSO2 ESB - Design for testability

Introduction Testability is one of the underestimated qualities of software. This is also the case for WSO2 ESB projects. However it is important to design the integrations for testability and this starts with the way you setup the proxies. This blog gives some guidelines which you can use to design for testability. Sequences Sequences are a way in WSO2 to group Mediators. A proxy has by default an in-Sequence, out-sequence and optionally an error-sequence. These sequences can be split up in sub-sequences and this is a good way for reuse, but also a way to split up the design. A proxy usually contains the following functional parts: Validation Transformation Sending to an endpoint   These parts can be put in separate sequences. This has the advantage that the part scan be reused in other proxies. This is also the way to enable testing for these parts.  Design for testability The sequences are the basis for the testability of WSO2 ESB pr...

WSO2 ESB 5.0.0: Data Mapper

One of the features i missed within the WSO2 Developer Studio was a data mapper. We had to write our own XSLT or PayloadFactory within the product. But everything is going to change with the release of ESB 5.0.0 ! Or is it ? .... There is a first blog item on the datamapper that i read and tried: https://nuwanpallewela.wordpress.com/2016/04/10/how-to-use-wso2-data-mapping-mediator-in-esb/ A very good blog indeed. However when i tried the new developer studio, i was somehow disappointed. I am positive about the fact that the Mapper is a real resource (even project) now. But i miss a lot of features (like for example XPath functions, if-then-else-construct, constraints) within the mapper. As you can see from the picture below, only the following operators are supported: Concat Split LowerCase UpperCase And when you investigate the generated project files, you will notice that JScript? is generated to do the actual mapping. So my first impression is disappoin...

WSO2 API Management in DTAP

Using the WSO2 API Manager in a DTAP environment is slightly different than for example the ESB product. Nadeesha has written a good article about it:  http://wso2.com/library/articles/2016/03/article-architecting-a-multi-environment-api-manager-deployment-with-wso2-api-manager/ My conclusion of the article and some take aways: API Manager does not use Carbon Archive files because API Manager artifacts are both stored on file system and database Use import/export facility to migrate APIs There is also a bulk tool available to import/export a bulk of APIs Environment specific attributes must be given as parameters The downside of that last point is that each time new parameters are added, you must restart the API server. Each backend will have its own endpoints, so this will require new parameters. I would recommend a seperate file that must be imported within the  wso2server.bat file.