Some principles are emerging for what one might call service-oriented programming languages. The principles are general, so they can help when thinking about code even when operating outside of these languages. A little demo of the code shown in this article can be seen in this video: The rise of cloud computing has thrown many developers into the world of developing software that consists of : components that can be executed independently and then be composed by means of message passing. services Microservices continue this practice by making each service "small", in the sense that it is organized around business capabilities, and potentially developed by an independent team. Developing (micro)service-oriented systems poses a challenge that motivated substantial efforts in the identification and dissemination of useful tools and design patterns, some new and some well-known. At the latest Microservices Conference (that's at the time of this writing), the people behind the programming languages and teamed up to tell a story that takes this even further: some principles are so important for service-oriented programming that programming languages should consider supporting them natively. Microservices 2020 Jolie Ballerina —The banner of the conference Microservices 2020, which was held online due to the COVID situation. In this article, I attempt at summarising some of these principles and the motivation behind them. You will also find a short video that applies these principles to a simple example. The list of principles is by no means complete. More will follow. If you have an opinion on the principles listed here, what principles are missing, and how these principles related to existing technologies, I'd love to hear it! The article consists of two main parts: motivation and principles. They can be read separately at different times, if you're in a rush. Motivation Developing service-oriented systems is challenging for many reasons. Let's revisit three of the main ones. The problem of integration is pervasive in service-oriented systems: Integration. The services that we have to compose might be implemented with different languages or frameworks. A service might need data from an application that is not controlled by the service developers (this happens often when integrating legacy applications, or even with new ones in the context of microservices). To obtain a working system, services (and clients) need to coordinate with each other. Dealing with these aspects can take a long time. We seem to be spending more and more time on integrating components rather than developing the components themselves. (In fact, some big consultancy companies might tell you that we're now spending time on integration than on anything else.) more The scenery of service-oriented computing is moving fast, and service-oriented systems easily fall prey to technical debt. For example, we might need to make our data available under a new format, or change the configuration of how our services can be reached. Technical debt is, by its very nature, easy to see with hindsight but very hard to predict. We should at least try our best to isolate and decouple the bits and pieces that are likely to change in the future from the code that implements the business logic of a service. However, working out what this decoupling should be and how it works is nontrivial. Technical debt. A very concrete example of technical debt is that we tend to fix assumptions on which components of an application will be distributed and which will run in the same executable. If you ever tried porting a monolith to a microservice architecture, you probably know the pain of revisiting these assumptions. Ideally, we should design components such that they could be grouped in the same executable or spread out over a cloud, but how should we go about this? Distribution. —Image by https://unsplash.com/@tvick . Principles of service-oriented languages We now move to describing a few principles that can help us in dealing with the challenges above. The principles are first presented by going through the design of a simple service, which clients can invoke to get back a greeting message. We keep the definitions of these principles purposefully generic. Later, we will reflect on their interpretation and utility. Greeter The principles are general, so you could apply them to your own code, or you might create a framework for another language that supports them (some frameworks support a few of these principles). To map concepts to code as directly as possible, I'm going to develop the example and show how the principles are incarnated in the . Jolie programming language In the Jolie development team, we chose the route of a programming language because it gives us a stronger tool for keeping developers on the right track. Languages influence how we think, so they are a good vector for making developers adopt practices without thinking too much about them. Ideally, adopting the principles should be obvious and efficient, while escaping from them should be hard and instill doubt. These objectives can be hard to achieve with a framework: we lose simplicity because we must learn how to use both the language that the framework is implemented in the framework itself on top of it; and we can keep using other libraries or the bare features of the host language, which put us at risk of breaking the principles. and — The logo of the Jolie programming language. That said, let's start visiting our concepts through the lens of our service example. Greeter APIs An API (Application Programming Interface) defines the contract between a service and its clients. An API should specify, at the very least: The data types that define the structures of the data that is going to be exchanged between the service and its clients. The operations that the service makes available to clients. APIs are essential to service programming, since they allow us to check whether a service offers what we need while at the same time abstracting from how the service is concretely implemented. This brings us to our first principle. Principle 1: formal APIs Service APIs should be defined in a formal language, which is ideally technology agnostic, unambiguous, machine readable, and based on well-known abstractions. Say that our service should receive client requests containing a name (the name of the person that we should greet), and send back a response that contains a greeting. We can define these data types as the following . Greeter record types We can now use these data types to define an (Jolie for API) that specifies an operation that our service is going to offer to clients to obtain a greeting. interface greet Above, means that operation receives a request and always sends back a response to clients. (Jolie also offers as an alternative, meaning that the client does not need to wait for a response.) We then define that expects requests of type and sends back responses of type . RequestResponse greet OneWay greet GreetingRequest Greeting Observe that what we have written so far is technology-agnostic, in the sense that our data types correspond to types that would make sense in most technologies. This principle is somewhat present also in the interface languages of and . Some frameworks that used the supported binding XML data structures to other formats in HTTP messages. protocol buffers OpenAPI Web Service Description Language Another important aspect when designing an API language with integration in mind is . If you are not familiar with structural typing, don't worry: we're going to revisit the concept later on. In a nutshell, this means that if a client and a service have defined their data types using different names or other details that do not matter when it comes to how data can be accessed, then these types should be deemed compatible. structural typing Principle 2: structural typing API languages should support structural typing. Services APIs are implemented by services, which are independently executable software artifacts. Jolie provides a native keyword to define a service, called . For instance, we can start writing the implementation of a service , which will implement our API, by writing the code below. service Greeter GreeterIface Principle 3: components are services Components are services that can, in principle, be independently executed. Services should be clearly identifiable in source code. Ideally, the scope of their definition is clearly delimited, e.g., supported by structured programming constructs (as above) that can be used at will. Access points A service exposes its APIs to clients by means of , which define how the service can be reached by messages. In Jolie, an access point is created by using the keyword . To define an access point, we must state: access points inputPort The at which clients can reach the service. location The transport that clients should use to communicate. protocol The (that is, the APIs) that can be accessed. interfaces Each one of these components has a corresponding primitive in Jolie. Below, we define an access point that: Accepts connections on TCP port 8080. Uses HTTP as transport protocol, encoding data with the JSON format by default. Exposes the API. GreeterIface We introduce a principle for access points as well, which we are going to reflect on later. Principle 4: decoupling of access points from business logic The definition of access points should be separate from the implementation of the business logic of the service. Behaviour (or business logic) Now that we have defined an access point for our service, we have to code the behaviour that implements the business logic for the API that we are exposing. Our API, , offers one operation, called . What we want to do is writing a behaviour that: GreeterIface greet Receives a message for . In Jolie, this is done simply by writing the name of the operation. greet Stores the received client request in a variable, say . request Computes a response containing a greeting, for example using a variable called . response Send the content of back to the client. response To receive a message for an operation in Jolie, we just write the name of the operation, followed by the name of the variable where we want to store the request and the expression that should be evaluated to get the response, in parentheses. In the curly brackets that go together with the input statement on , we can write the code that computes out greeting. greet Observe that our business logic implementation does not mention that or are encoded in the JSON format. In fact, as we are going to see, this implementation can work also with other wire formats without modifications. request response Principle 5: abstract data manipulation The implementation of business logic should, as far as possible, abstract from how data is represented on the wire. Taking stock Let's take stock and have a look at the complete program that we got so far. We are then going to reflect on a few important aspects of how we have programmed it. This is a complete Jolie program. You can store it in a file, say , and then launch it from the command line by executing the command . Visiting the URL would then get you the following reply. greeter.ol jolie greeter.ol http://localhost:8080/greet?name=Jolie You can watch a brief live demo of the development of and its invocation in the video below. Greeter Reflections on the principles We now reflect on the usefulness of the presented principles. Principle 1: formal APIs Thanks to principle 1, it is possible to devise tools that can: Check whether the API of the service is compatible with what clients need. Generate API descriptions in other languages, like those in or . OpenAPI WSDL These advantages are relevant for integrating services with other components and also for integrating with other technologies. Principle 2: structural typing Differently from many other languages, Jolie adopts a view on types: to determine whether two types are equivalent, Jolie looks at their definitions. This means that even if two services use two different names for the type of some data but the type structures are equivalent, then Jolie can tell that everything is OK. structural Consider, for example, the following data type . Team Now, say that we tried to send a message of type to a service expecting something of the following type . Team Group The types and have different names and their definitions use a different ordering of the fields. But fields are unordered in Jolie, and names to not matter thanks to structural typing. So the communication would not incur a type error. Team Group This kind of flexibility makes integration easier. It also allows Jolie to communicate easily with services written in other technologies, because the types of a Jolie service just need to be to those used by the other services, and not defined in the same language. Also, services can be developed a bit more independently, because we do not care about differences in details that do not matter. equivalent Jolie has adopted structural typing since 2008. More recently, Ballerina as well. uses structural typing Principle 3: components are services Principle 3 aids the programmer in having code that corresponds closely to the intended model (a service, in this case), which makes us more effective. Making it very easy to write many services can aid in dealing with technical debt and distribution. Say that we wanted to change to authenticate clients and get profile information, by using a separate component called (responsible for managing user profiles): Greeter UserProfiles In a language that is not service-oriented, we might be tempted to define that component as something that is not a service, which would then become an integral part of that is very hard to detach in the future. This technical debt could bite us in the future if we ever wanted to scale up and make a service that can be run independently. Greeter UserProfiles Differently, in a service-oriented language, we would be guided (Jolie would actually force us) to make immediately a service. Initially, we might decide to run and in the same machine, or even in the same process. But the principle leaves us free to distribute these services in the future, or even to make these services automatically redeployable (as in serverless). For this to work, it is important that (i) the language discourages knowing whether another service is running in the same execution environment (e.g., a process in the operating system) or not; and (ii) the language makes communications between services running in the same execution environment efficient. UserProfiles Greeter UserProfiles Principle 3 thins the different between monoliths and microservice architectures: a monolith is a collection of services, and distributing it requires less effort. (See also .) non-distributed microservices We are going to give a concrete example of this at the end of the next section, by combining principle 3 with principles 4 and 5. Principles 4 and 5: decoupling of access points from business logic and abstract data manipulation Principles 4 and 5 are in synergy, so we discuss them together. These principles help with getting code that can be reused with different data formats. For example, say that we wanted to send greetings encoded in XML instead of JSON. We just need to change the input port of to use as format, without the need for updating the implementation. Greeter xml Since the business logic implementation abstracts from the concrete representation of data (principle 5), we do not need to change the code within the block. main Another advantage is that we can define to the same service. For instance, we could make our service available both through HTTP and a binary protocol (here we use SODEP, a binary protocol distributed with Jolie). multiple access points Greeter Also in this case, reusing the business logic implementation for both access points does not require updating the block. same main The last advantage brought by these principles that we discuss here is that they help with integrating code written with different technologies. Since access points are defined separately from business logic implementations, we can write such implementations in different languages. In Jolie, this is achieved with the keyword . For instance, suppose again that our service needed a service that we want to implement in Java. We can achieve this by implementing a class that implements the necessary API as Java methods and then extending our example as follows (we omit the definition of the API of ). foreign Greeter UserProfiles greeter.UserProfiles UserProfiles (We keep error management simple here, but in the real-world you would want to have an explicit error case in the type of responses.) The code above will run the service defined in Java as class and make its API available on the efficient local memory channel . greeter.UserProfiles local://UserProfiles The construct used inside of enables the service to use the API of . outputPort Greeter UserProfiles Assume now that we wanted to run as a service that runs remotely and is available at the address using the binary protocol SODEP. We can simply reconfigure the output port of our service, without touching its business logic implementation. UserProfiles userprofiles:9090 Greeter Conclusion We discussed some principles that have emerged (some are emerging) as important in the development of (micro)service-oriented systems. Not only do they bring advantages in isolation, but they also present significant synergies. Some languages support a few of these principles natively, to make sure that developers can follow them effectively. supports all the principles that we discussed. supports principles 1, 4, and partially 3 (only one service per program). supports principles 2, 3, and partially 4 (references to external services are defined within the implementation of the business logic). Jolie WS-BPEL Ballerina The list of principles that we have discussed is certainly not complete. There are other principles that, for example, have to do with deployment, observability, and reconfiguration. There are also features that become possible thanks to the principles that we have described, which we have not talked about here. For instance, Jolie exploits the combination of principles 1, 2, 4 and 5 to offer native primitives for , which cover cases such as API Gateway and Circuit Breaker (a discussion can be read in ). These could be topics for future write-ups. architectural programming this paper Previously published at https://fmontesi.github.io/2020/09/30/service-oriented-programming-languages.html

Different

Keep

Mind

A Detailed Introduction to Service-Oriented Programming

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

How to Implement the Decorator Pattern in Microservices

100 Days of AI Day 1: From Newsletter to Podcast, Leveraging AI for Audio Transformation

10 Threats to an Open API Ecosystem

10 Indications That You Should Invest in Automation Via APIs

10 Best Practices for Securing Your API

The Noonification: Getting Your API Into Production (10/28/2022)

How to Implement the Decorator Pattern in Microservices

100 Days of AI Day 1: From Newsletter to Podcast, Leveraging AI for Audio Transformation

10 Threats to an Open API Ecosystem

10 Indications That You Should Invest in Automation Via APIs

10 Best Practices for Securing Your API

The Noonification: Getting Your API Into Production (10/28/2022)

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps