In short Coupling, Cohesion and Granularity are part of SOA Design Principle and they can be summarized as follows:

• Service Coupling:
  • Definition: Refers to the degree of interdependence between two business processes.
  • Preferable State: Weak coupling is favored in SOA, indicating lower dependency for increased flexibility and maintainability.
• Service Cohesion:
  • Definition: Represents the degree of functional relatedness and focus of operations within a service.
  • Preferable State: Strong cohesion is preferred in SOA, indicating that a service should encapsulate closely related and well-defined functionalities.
• Service Granularity:
  • Definition: Denotes the scope of functionality exposed by a service.
  • Preferable State: Coarse granularity is recommended in SOA, suggesting that services should provide broad functionalities to address specific needs, promoting reusability.

Service Coupling:

Service Coupling is a critical design principle that examines the degree of interdependence between any two business processes or services within a system. It essentially evaluates how tightly or loosely these services are connected and the implications of changes in one on the others.

Characterized by the level of dependency, tight coupling signifies a strong interconnection where modifications in one service may necessitate corresponding changes in others. Conversely, weak coupling is the preferred state in SOA design. Weak coupling implies a lower level of dependency, allowing for greater flexibility, scalability, and ease of maintenance. Services with weak coupling can evolve independently, reducing the risk of unintended consequences when modifications or updates are made.

The benefits of weak coupling extend to the adaptability of the architecture to changes in business requirements. Services that are loosely coupled are more resilient to alterations, ensuring that adjustments in one part of the system do not propagate unexpectedly to other interconnected services.

For example, a service employing standardized interfaces and protocols can interact with other services more loosely, minimizing the impact of changes in one service on others. Achieving weak coupling often involves defining clear service interfaces, minimizing direct dependencies, and utilizing standards to facilitate interoperability between services. In essence, Service Coupling is a foundational principle in SOA design that promotes a modular, adaptable, and scalable architecture.

Service Cohesion:

Service Cohesion stands as a pivotal design principle governing the internal organization and functional relatedness within an individual service. It delves into the degree to which the operations encapsulated within a service are logically connected and focused on a specific set of functionalities.

Characterized by its emphasis on functional relatedness, strong cohesion is the ideal state for services in SOA. A service exhibiting strong cohesion encapsulates a well-defined and closely related set of functionalities, ensuring that its operations are united by a common purpose. This design approach enhances the service’s clarity, maintainability, and usability, as all contained functionalities contribute to a coherent and unified business capability.

In contrast, weak cohesion suggests a service with disparate functionalities that may not be logically connected, leading to a lack of clarity and potentially hindering the service’s effectiveness. Strong cohesion, on the other hand, facilitates a service’s reusability, as the encapsulated functionalities are designed to work together seamlessly, promoting a modular and extensible architecture.

For example, a service responsible for order processing should ideally encapsulate functionalities such as order validation, payment processing, and inventory management, exhibiting strong cohesion by focusing on a cohesive set of operations related to order fulfillment.

Achieving strong cohesion often involves careful analysis of the business processes and ensuring that the functionalities grouped within a service share a common context and purpose. This principle contributes to the creation of services that are not only well-defined and purposeful but also conducive to building a scalable and adaptable SOA.

Service Granularity:

The concept of Service Granularity plays a crucial role in defining the scope of functionality exposed by a service. It is essentially a measure of how broad or specific a set of functionalities needs to be in order to address a particular business need. The degree of granularity directly impacts the reusability, flexibility, and efficiency of the services within the architecture.

In SOA, the preferable state for Service Granularity is characterized by a tendency towards coarse granularity. Coarse-grained services encapsulate broader and more encompassing functionalities, capable of addressing significant business requirements in a single service invocation. This design approach promotes simplicity, reduces the number of service interactions, and facilitates easier maintenance.

Conversely, fine-grained services expose narrower sets of functionalities, potentially requiring multiple service invocations to fulfill a specific business operation. While fine granularity may seem intuitive for certain scenarios, it can lead to increased communication overhead and complexity, making the system more susceptible to performance issues and maintenance challenges.

For example, a coarse-grained service responsible for customer management might encompass functions such as creating, updating, and deleting customer profiles, providing a comprehensive set of functionalities within a single service interface.

Achieving the right level of granularity involves careful consideration of the business context and requirements. Coarse granularity is favored as it enhances the potential for service reuse, reduces the impact of changes on service interfaces, and aligns with the overarching goal of creating a modular and scalable architecture in SOA. Striking a balance between granularity and functionality is key to building an effective and adaptable service-oriented system.

Unlock the power of Service Oriented Architecture (#SOA )! Learn how #service Coupling Cohesion, and Granularity influence flexibility and #scalability in your #System . #softwaredevelopment #programming #API
Share on X

Service Oriented Architecture (SOA) Design Principle and Application Programming Interfaces (APIs)

The concepts of Service Coupling, Service Cohesion, Service Granularity, and APIs (Application Programming Interfaces) are intricately related in the context of designing and implementing a Service Oriented Architecture (SOA) or any modular and scalable system. APIs act as the external interface for services, and their design choices have a direct impact on the level of coupling, the cohesion within services, and the granularity of functionalities exposed. A well-thought-out API strategy is crucial for realizing the principles of a modular, scalable, and adaptable Service Oriented Architecture.

APIs and SOA operate at different levels of abstraction and have distinct purposes within the realm of software architecture. The distinction in their level of abstraction is rooted in their design principles, scope, and intended use. APIs are considered more low-level than SOA because they provide detailed interfaces for developers to interact with specific functionalities, while SOA operates at a higher level, focusing on the overall organization and alignment of services within a system. APIs are tools that facilitate the implementation of SOA principles at a more granular level.

This specific article focus on SOA design principles; if you want to know more on how to design a good API you can find more information here.

The post Service Oriented Architecture (SOA) Design Principle: Coupling, Cohesion, and Granularity appeared first on Francesco Lelli.

Answer from Wikipedia:

A two-sided market, also called a two-sided network, is an intermediary economic platform having two distinct user groups that provide each other with network benefits.

In other words it is a marketplace (online or offline) where different kinds of people meet and exchange valuable tangible or intangible goods and services.

Examples of two side marketplaces are literally everywhere and include companies like:

• Facebook
• Uber
• AirBnB
• Amazon
• Booking.com

and many more. These companies provide services that support and mediate the interconnection of groups of people in different manner.

Jeff Bezos gave a talk at MIT the 25th of November 2002 explaining some of the key characteristics of Amazon at that time. At the time, he was looking for new fresh graduates to join his ranks and explained some of features of these marketplaces that are still valid nowadays.

Some key aspects of this talk include:

• you need to help customers to find products and products to find customers. Actually, the second part is more challenging than the first one.
• How logistics is intertwined with computer science in several different ways
• The system needs to works at scale since its inception
• Real time experiments with feedback loop as opposite of batch data mining of the data
• Amazon Web Service was launched in 2001 with the key idea of providing an SDK and a solid API for external users in order to build customizable store fronts
• Amazon Web Services are connected to their affiliate program in order to give a percentage of the sales as commission (or referral fee) to their external developers

The talk also provides a few examples of how developers were coming out with new ways of taking advantage of the internet that they did not expect nor plan. In addition, he explains how extreme customization and recommendation was (and still is) an important feature of the system.

Clearly, there is much more to say about building a two sided marketplace and how various technologies evolved since then. However, this is a good start as an introduction to the API Economy

The post On Building a Two Sided Marketplace appeared first on Francesco Lelli.

An application programming interface (or API) is a computing interface which defines interactions between multiple software intermediaries. APIs in the web are literally everywhere and serve a never-ending and ever-growing set of purposes.

The plot below gives you an idea on the size of the economy and its estimated growth in the coming years. We should probably note that this estimate is pre-Covid. Therefore, I would not be surprised if the growth would be even greater.

The big 4 as well as McKinsey are regularly monitoring the phenomena. Here you can see the point of view of Deloitte on the API Economy in one of their recent whitepapers.

The #API #Economy and its role for #programming the Web
Share on X

From a technical point of view, the communication leverages the fact that machines exchange messages via the Web usually using a REST or a SOAP approach.

REST/SOAP and their role in programming the Web

Representational state transfer (in short ReST) is a software architectural style that defines a set of constraints to be used for creating Web services. Web services that conform to the REST architectural style, called RESTful Web services, provide interoperability between computer systems on the Internet. It leverages the GET/PUT/POST/DELETE of the HTTP protocol for implementing the CRUD methods that are usually used in DBs such as:

• CREATE procedures generate new records via INSERT statements.
• READ procedures reads the data based on input parameters. Similarly, RETRIEVE procedures grab records based on input parameters.
• UPDATE procedures modify records without overwriting them.
• DELETE procedures delete where specified.

SOAP (abbreviation for Simple Object Access Protocol) is more flexible and is just a messaging protocol specification for exchanging structured information. It is used in the context of implementing web services in computer networks. Its purpose is to provide extensibility, neutrality, verbosity, and independence.

#REST and #SOAP play an important role in #programming the web and the #API #Economy
Share on X

SOAP and REST are subject to a never-ending battle. Programmers and software architects tend to have a polarized view. I personally see them as two sides of the same coin. I will cover some of the aspects of the discussion in a future article. In this post, as I usually use SOAP in the lectures of SOE, I will use REST for describing how programming the web works.

Programming the Web from a technical point of view

This video summarizes the various concepts that rotate around REST as well as gives an example using data represented in JSON.

For a good API the protocol is only the beginning and there is always need for a SDK. They practically go in tandem. A software development kit (or SDK in short) is a collection of software development tools in one installable package. They facilitate the creation of applications by having a compiler, a debugger and perhaps a software framework. They are normally specific to a hardware platform and operating system combination. In other words, they are a set tools that make the adoption of a protocol easy.

This video explains how an API and a SDK complement each other:

the role of #SDK in #designing a good web #API and fostering protocol adoptions
Share on X

Useful resources for navigating the API economy

Where can I find an API? You can start by searching in google “<name of the company> API” and you will be surprised by the astonishing amount of companies that are using this approach. However, in case you are shopping for ideas, this approach may be limiting the possibilities. A better alternative could be to familiarize with the API Economy using this set of videos from the ProgrammableWeb:

You could also browse catalogs that are available in the Internet, such as:

• https://any-api.com/ Collection of APIs and tools for using them.
• https://www.programmableweb.com/category/all/apis A “historical” initiative that intends to list all possible APIs that are available in the web.
• https://apilist.fun/interviews APIs can be also a fun endeavor!

Useful #resources for navigating the #API #Economy and discover new services
Share on X

The post The API Economy: Resources for Programming the Web appeared first on Francesco Lelli.

An Application Program Interface (API in short) refers to a set of functions and procedures allowing the creation of applications that access the features or data of an operating system, application, or other service.

A good API should be:

• Easy to learn and use. It should not intuitive enough to that the documentation would not be needed for the majority of the cases.
• Hard to misuse. At the same time an API should be designed in a way that prevent misuse of the code. in other words it should force you to do “the right thing”
• Easy to read and maintain code that uses it. As the API will change over time you would like to minimize the changes that users will have to do/
• Sufficiently powerful. It should be able to satisfy the requirements of your users and mask the complexity behind. In other words the users should be able to solve their needs without knowing all the details of how the system works.
• Easy to evolve. As requirements will change over time the API should accommodate these changes without causing major disruptions in the code that is wrapping as well as in how the users are using it.
• Targeted to the appropriate audience. As different groups of people use different terminologies the API should take into account these aspects. In other words, what is good for a physicist may not be good for an economist.

This google tech talk share some insight on the process and the best practices around the design of a good API.

Joshua Bloch has an extensive experience in this matter and show how good APIs increase the pleasure and productivity of the developers who use them, the quality of the software they produce, and ultimately, the corporate bottom line.

How to #design a good #API : #advancedpractice in Object Oriented #programming. Practical examples in #Java but with #python works as well. #softwaredevelopment #SoftwareEngineer
Share on X

The post How to Design a Good API: Advanced Object Oriented Programming appeared first on Francesco Lelli.