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.

Design patterns serve several important purposes in software development:

1. Reusability: They encapsulate proven solutions to common problems, making it easier for developers to reuse these solutions in different parts of their code or in different projects.
2. Abstraction: Design patterns provide a higher-level abstraction that helps developers think about and communicate the structure of their code more effectively. They provide a common language and framework for discussing design decisions.
3. Maintainability: Using design patterns can improve the maintainability of software because they promote well-structured and organized code. Developers can more easily understand and modify code that follows established patterns.
4. Scalability: Patterns can help ensure that software is designed in a way that allows it to scale and adapt to changing requirements without requiring major redesigns.
5. Community Knowledge: Design patterns are well-documented and widely recognized within the software development community. This means that developers can leverage the collective wisdom and experience of the community when applying these patterns.

As the term software embrace a very large domain, there are several categories of design patterns. Each one is specialized for a particular portion portion of the code. These patterns includes:

1. Creational Patterns: These patterns deal with object creation mechanisms, trying to create objects in a manner suitable to the situation. Examples include the Singleton, Factory Method, and Abstract Factory patterns.
2. Structural Patterns: Structural patterns focus on defining the composition of classes and objects. Examples include the Adapter, Bridge, and Decorator patterns.
3. Behavioral Patterns: Behavioral patterns are concerned with the interaction and communication between objects. Examples include the Observer, Strategy, and Command patterns.
4. Architectural Patterns: These are high-level patterns that deal with the overall structure of an application. Examples include the Model-View-Controller (MVC), Model-View-ViewModel (MVVM), and Layered Architecture patterns.
5. Concurrency Patterns: These patterns address issues related to managing concurrent access to shared resources in multi-threaded applications. Examples include the Mutex, Semaphore, and Read-Write Lock patterns.

Design patterns are not one-size-fits-all solutions, and they should be applied judiciously based on the specific requirements and constraints of a software project. Experienced developers use their knowledge of design patterns to make informed decisions about when and how to apply them to solve particular problems.

The list of pattern is long and is also evolving as the software developer community evolve. At the Some time pattern like facade, adapter/wrapper, proxy and observer stand the test of time and are the most known among developers. Let’s see each one of them

Facade Pattern:

• Purpose: The Facade pattern provides a simplified, high-level interface to a complex subsystem or set of classes. It acts as a “facade” to shield clients from the underlying complexities of the system.
• Use Cases: It’s useful when you want to provide a simplified and unified interface to a complex system, making it easier for clients to interact with it. It promotes loose coupling between the client code and the subsystem.

The image below present the pattern using a Class Diagram:

Example of Use: Multimedia Player Facade

Suppose you are building a multimedia player application that can play various types of media, such as audio and video files. The underlying multimedia framework is complex, with different classes and interfaces for handling codecs, rendering, audio output, and video display.

In this example, we could consider implementing a class of name MultimediaPlayerFacade that acts as a simplified interface to the complex multimedia framework. It encapsulates the initialization and usage details of the audio and video players, making it much easier for client code to play multimedia. The client code is simplified and less coupled to the underlying multimedia framework, which can change without affecting the client code.

The Facade pattern here provides a cleaner and more maintainable way to interact with a complex subsystem, shielding the client code from its intricacies.

Adapter Pattern also known as Wrapper Pattern::

• Purpose: The Adapter pattern allows two incompatible interfaces to work together by providing a wrapper around one of them. It acts as a bridge between two interfaces, making them compatible without changing their source code.
• Use Cases: It’s used when you have existing code with interfaces that are not compatible with the interfaces you need to use. The adapter pattern allows you to reuse existing code without modification.

The image below present the pattern using a Class Diagram:

Example of use: Legacy System Integration

Imagine you are working on a modern e-commerce application that needs to integrate with a legacy payment gateway. The legacy payment gateway has an outdated interface that doesn’t match the modern payment service interface your application uses. You can use the Adapter pattern to bridge the gap.

To integrate the legacy payment gateway with your modern payment service, you can create an adapter class. In this way you can use the Legacy Payment Adapter to make payments through the legacy payment gateway using the modern payment service. In this way the adapter acts as a bridge between the modern payment service interface and the legacy payment gateway.

Proxy Pattern:

• Purpose: The Proxy pattern provides a surrogate or placeholder for another object to control access to it. It can be used to add an additional layer of control over an object, such as lazy loading, access control, or caching.
• Use Cases: It’s useful when you want to control access to an object, especially in situations where the creation or access to the object is expensive or where you need to add functionality around object access.

The image below present the pattern using a Class Diagram:

Example of use: Image Loading Proxy

Suppose you are building an image viewer application, and you want to implement a feature that loads and displays high-resolution images from a remote server. However, loading these high-resolution images can be slow and resource-intensive. To improve user experience and optimize resource usage, you can use the Proxy pattern. You can use the ImageProxy to load and display images in your application without loading the high-resolution image until it’s actually needed. Consequently you can delay the creation and loading of resource-intensive objects, improving the performance and resource utilization of your application.

Observer Pattern:

• Purpose: The Observer pattern defines a one-to-many dependency between objects so that when one object changes state, all its dependents (observers) are notified and updated automatically.
• Use Cases: It’s commonly used for implementing distributed event handling systems, where multiple objects need to react to changes in another object’s state. Examples include GUI frameworks where UI elements update when underlying data changes.

The image below present the pattern using a Class Diagram:

Example of use: Weather Monitoring System

Imagine you are building a weather monitoring system that collects weather data from various sensors and notifies multiple display devices when the weather conditions change. In this scenario, you can apply the Observer pattern to implement the system. You could imagine a class of name ConcreteWeatherStation as the subject that collects weather data and notifies its observers (in this case, maybe various display objects) when the data changes. The Observer pattern allows multiple display devices to receive and react to updates without being tightly coupled to the weather station.

Summary of Software Patterns or Design patterns

Software patterns, also known as design patterns, are widely recognized and essential approaches for organizing code and solving recurring design problems in software development. Among these patterns, the Facade pattern simplifies complex subsystems by providing a unified interface, making it easier for clients to interact with intricate systems. The Adapter pattern bridges the gap between incompatible interfaces, allowing different components to work seamlessly together. The Proxy pattern acts as a surrogate for an object, controlling access and adding functionality, which can be valuable for resource optimization and security. Lastly, the Observer pattern facilitates the creation of distributed event handling systems, enabling one object to notify multiple observers about changes, enhancing code modularity and flexibility. These patterns represent just a subset of the many design patterns available, and they serve as valuable tools in the developer’s toolkit for building maintainable, scalable, and efficient software systems.

In the case you would like to learn more I would recommend you to have a look at the following book from “the gang of 4“

It is a classic and several libraries will probably have a copy.

The post What Software Patterns (or Design Patterns) are and an introduction to the most common one appeared first on Francesco Lelli.

Service Encapsulation is often used to hide the internal representation, or state, of an object from the outside. In this way, we can present to the outside world a cleaner, simpler, and more coherent view of the internal systems. Many services which were not initially planned for a Service Oriented Architecture (SOA) may get encapsulated or become a part of a SOA in this way.

In the example of ACME Social and University of Nowhere, both the parties agreed on exchanging information in order to improve the existing geolocation service of ACME Social. In particular, ACME Social would like to receive the following information from the University of Nowhere:

• Retrieve a list of unique IDs of the students
• Retrieve the email addresse(s) of each student
• Get the class that the student is supposed to follow
• Retrieving the exact coordinates of the location of a given student according to the University of Nowhere.

Service Encapsulation: Can we design it as a stateless service?

Probably yes, even though students and their respective locations will change. From the point of view of the methods, we can expect that their behavior will not change over time. A possible UML diagram that describes the interface of the service could be as follows:

The class represents all the functionalities requested by ACME Social in 4 methods. It does not have attributes and this approach will keep the design simple. IDs, emails, as well as geocoordinates will be shared as Strings in order to use one of the basic types of a service.

In the case we will decide to implement a WS-I compliant service, we can assume that the calls of the methods can fail and may trigger exceptions on the service consumer’s side.

What about the concerns of ACME Social and the documentation of the service?

As the service represents the entry point of the systems of the university of Nowhere, we need to carefully balance the complexity of the interface that we need to design. On the one hand, it must be able to mask all the idiosyncrasies of the IT of the university in order to facilitate its consumption by ACME Social. On the other hand it must be able to deliver everything that is needed and agreed. The figure below shows how this interface sits at the intersection points of two different worlds with different needs and goals:

ACME Social, i.e. the client of the service needs a clear answer to the following questions:

• What does the service do? Answering to this question will require a proper documentation of the methods. The name may be intuitive, but some of its behavior may not. Therefore, it needs to be carefully documented.
• How can we use the service? The best way to answer this question is with an example of use. ACME social may use different languages so the example(s) need to be written in Java and Python (for example) and the code must be well documented (see these best practices).
• Where can we locate the service? The URL of the service, together with the way to get the authorization of use, should be part of the documentation. In addition, the service should be part of an UDDI registry as well.

ACME Social is not at all interested in:

• How to represent internally the request received from ACME social
• How to implement the service
• Where to host the server needed for running the service
• How to publish the service in the Internet
• How to keep it running

These aspects are of fundamental importance for the University of Nowhere. However, these concerns should not be shared with the consumers of the service.

A #service Encapsulation example using a location service. #servicedesign #programming
Share on X

The post A Service Encapsulation Example Using a Location Service appeared first on Francesco Lelli.

There is more to object oriented programming. If you want to be able to write code that you can re-use 2 weeks after, you want to put attention to how to write good quality code. This activity takes time, but if you want to be able to look back at what you have done (and you want it!) you have to pay the price.

Next, consider the importance of commenting your code and the proper way to do it. This is a fundamental activity. However, more commenting is not necessarily better then less commenting.

This second set of talks digs deeper into the profession of software engineer/ programmer and promotes an attitude that fosters collaboration and ethics.

One of the problems that the industry is facing is that in the past 50 years, the number of programmers doubled every 5 years. Therefore, the industry remains young and the experienced coders face the trouble of passing their knowledge to the new generation. In one line: act professional!

Test driven development is a software development process that relies on the repetition of a very short development cycle: Requirements are turned into very specific test cases, then the code is improved so that the tests pass. This is opposed to software development that allows code to be added that is not proven to meet requirements. This, together with making correct estimates and saying no is the right attitude for delivering successful results.

Software architecture refers to the fundamental structures of a software system and the discipline of creating such structures and systems. Each structure comprises software elements, relations among them, and properties of both elements and relations. In the video below, you will learn the fundamentals of software architecture, its rules, the value of discipline in the production of quality code, and the responsibility of disseminating the need to implement these good practices in the community of programmers.

Challenges in software and software management include the problem of adjusting software production time to delivery times. In other words, we are talking about the divergence between the needs of the client, the commercial commitments, and the needs of the programmer to produce quality software. Software project management is comprised of a number of activities, which contain planning of project, deciding scope of software product, estimation of cost in various terms, scheduling of tasks and events, and resource management. This last talk is about some of these challenges:

In summary, quoting from Uncle Bob:

Even bad code can function. But if code isn’t clean, it can bring a development organization to its knees. Every year, countless hours and significant resources are lost because of poorly written code. But it doesn’t have to be that way

#HowTo write clean #code by Uncle Bob ( Robert Cecil Martin ) #softwaredevelopment #CodeNewbie #HowtoPerfect
Share on X

How to write clean code? In case you would like to know more, here you can find a link to his book:

Clean-Code-Handbook: https://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882

The post How to write clean code by Uncle Bob (Robert Cecil Martin) appeared first on Francesco Lelli.