Abstract: Microservices are an architectural style in which each service typically provides the complete stack of functions from a user or application programming interface through a domain model all the way to storage for that model. As a consequence, querying conjunct data from different microservices becomes a non-trivial engineering task. In this article, we review older and established general data integration theory in the enterprise context and then compare current microservice practice with enterprise information integration (EII) theory as an established approach to data integration. We find that microservices do not utilize all possible approaches for data integration that are common in enterprises. Specifically, microservices use middleware only partially and databases are not used at all to integrate data. Therefore, we further investigate whether, when, and how these two approaches can be used in a microservices context and present our findings. With our findings, we (i) clear the way for fellow researchers to investigate and improve unused integration strategies with microservices and (ii) raise the awareness of practitioners that some integration strategies may not work out of the box with microservices as they do in EII.
Keywords: Microservices, data integration, enterprise Information integration, EII
Reference: Schwarz, G. & Riehle, D. (2020). What Microservices Can Learn From Enterprise Information Integration. In Proceedings of the 53rd Hawaii International Conference on System Sciences (HICSS 2020), pp. 5513-5522.
When I started our software architecture course about eight years ago, I was happy to find out about a book series on the architecture of open source applications. I was thrilled: Not only code, but architecture descriptions! I expected great material for my course. Sadly, I had to realize that none of the chapters in this book series used UML, a staple of most academic software architecture courses.
Does this mean UML is not used in practice? Of course not. It is just not used in open source projects. This doesn’t imply that UML doesn’t have its uses. However, they may not be what tool vendors are telling you.
The old wisdom of “data structures over functions” has stood the test of time for probably 50 years now. It states that long-term, a system is better built on sound data structures than functions. While functions may hide clumsy data structures for a while, when faced with evolution and new user needs, poor data structures will come back to haunt you and will eventually bring down the system.
I just listened to Eberhard Wolff’sBED-Con talk on microservice-based system architectures, which he prefers to call Independent Systems Architectures (ISA). One purpose of calling it ISA is to emphasize that there should be no common data model and no shared reusable libraries between microservices. Obviously, by discounting reuse, ISA may increase development speed short-term while increasing cost and quality problems long-term. Eventually, in his talk, Wolff came around and argued that microservce implementation independence and reuse are a trade-off rather than an either-or decision.
While preparing a session on (object-oriented) object creation for my Advanced Design and Programming course, I noticed that there are at least two major ways of looking at how to decide on how to create an object. The traditional way is a (still unwritten) pattern language that utilizes the classic Gang-of-Four object creational patterns (and then some) to guide the developer in designing the object creation process.
Fortunately, object creation has a neatly defined design space with clearly independent dimensions and hence lends itself well to a structured discussion. Without further ado, here are the dimensions of this design space as I see them:
Addison-Wesley asked the patterns community (or at least those who were there at the beginning) about their opinion on various issues. This is the second post of what should have been three (though I probably will only get to the first two).
For this very specific question, I expect everyone to say: Retire Singleton!
I beg to differ; for its time, Singleton was right. “Its time” mostly means single-threaded C++ code, as written by 3 of the 4 authors of the Design Patterns book. Today, many will argue that multi-threaded Java programs have made Singleton obsolete and even harmful. In my take at design patterns that would be wrong. Singleton should not perish, it should simply be adapted to its time. What ever thread-local information you may have, some it will be global to that thread. How is that not a thread-specific singleton? Or, take a group of application servers acting as a group: How is the group communication protocol not to provide a global id that makes the group identifiable and provide some global state attached to it? This may not be your granddaddy’s good ol’ singleton, but a singleton it may be nevertheless.
This is also where pattern descriptions will pass (or fail) the test of time: Does the original description of Singleton allow for these variations or not? If not, it may have been too narrow a description. I’d assume then that specific usage examples, tied to the programming languages and systems and technologies of its time, dominated the description and the abstracion process “out of examples, timeless patterns” did not yet conclude.
Beyond Singleton, some may want to retire Visitor, mostly because we find functional programming concepts being added to programming languages more and more, and multiple dispatch (which Visitor is about) comes for free. I say: Simply be precise about the scope. Visitor is (kind of) fine for Java but in a different context may not be needed as a design pattern because it has been cast as a language feature.
Design pattern should evolve and there is nothing wrong with it. John would approve.
Addison Wesley is going to celebrate the 20 year anniversary of the Design Patterns a.k.a. Gang-of-Four book. For this, they reached out to the community and asked for contributions. Here are the questions they asked, suggesting we ask (and answer) our own ones as well:
How has Design Patterns affected you and your career?
How has it changed how you think about software development?
Do you have specific recollections of the book’s release?
How do you use design patterns today?
Which Patterns should be retired?
Which new Patterns should be added?
I’ll provide my answers to questions 1-4 here and I’ll answer questions 5-6 in separate follow-on posts later.
At FAU, we are now holding our so-named “software architecture” seminar for the second time. It is important to realize (for students as well as the general public) that “software architecture” is a metaphor (or, maybe more precisely, an analogy). Architecture is a discipline several thousand years old, while software architecture is only as old as software engineering, probably younger, if you make Shaw and Garlan’s book the official birth date of software architecture, at least in academia.
While cleaning up, I found this copy of the OOPSLA 2004 Dating Design Patterns skit script. The skit itself was, as Brian Foote called it, occasionally humorous. I’m providing it here (before throwing out the paper copy) for the intermittent professional entertainment on my blog. We performed the skit at OOPSLA 2004. Fortunately, I don’t have any photos of this. However, I did find the following photo of the Gang-of-Four celebrating the ten year anniversary of the Design Patterns book. I think the photo is attributable to Brian Foote as well. In the back, you can see the late John Vlissides, still “in costume” from the skit.
Seit ein paar Monaten ist die neue Ausgabe des Entwurfsmusterbuchs verfügbar. Dies ist meine Übersetzung des Klassikers “Design Patterns” von Erich Gamma et al. aus dem Amerikanischen. Mit der neuen Ausgabe kommen einige Neuerungen und Änderungen. An erster Stelle zu nennen wäre der neue Umschlag:
Erster Vorschlag für den Umschlag der neuen Ausgabe
Der tatsächliche Inhalt der Sprechblase in der endgültigen veröffentlichten Fassung ist ein anderer und lautet: “We present you the book that changed software design.” Da die Viererbande (Gang-of-four) noch auf ein Nachfolgebuch mit weiteren Mustern hofft, habe ich Addison-Wesley’s ursprünglichen Vorschlag entsprechend geändert.