CresentOne Academy

This topic is a bit more 'technical'. We try to explain some terms and principals. How do they relate to a learning platform about an ERP platform? Well, these terms and principles are used to explain several developments and solutions implemented in the platform. These expainations can be useful to the technical inclined.

If you are not working in the realm of development and software architecture, this topic will not be in your center of interest. But it maybe a interesting topic if you are triggered by terms in one of our documentations.

Topics

So lets start with the terms that are subject to this topic:

• SOA -  Service Oriented Architecture
• SOAP - Simple Object Access Protocol
• REST - Representational State Transfer

• Microservices - An architectural pattern

Questions

We ask ourselves a few quetions:

1. What is the differences between SOAP, RESTful and microservices?
2. What is the differences between a protocol, an architectural style and an architectural pattern
3. can I use the terms SOA and RESTfull APIs together?

1 - SOAP, RESTful APIs, and microservices are all different approaches to designing and implementing web services. Here are the key differences between them:

• SOAP (Simple Object Access Protocol):

  • Protocol: SOAP is a protocol, which means it has a defined set of rules for structuring messages. It typically uses XML for message format and can operate over various lower-level protocols such as HTTP, SMTP, or JMS.
  • Standard: SOAP is a protocol standardized by the W3C (World Wide Web Consortium) and is a well-defined specification with a strict set of rules.
  • Complexity: SOAP messages tend to be more complex due to XML formatting and the strict structure defined by the protocol.
  • Security: SOAP has built-in security features such as WS-Security, which allows for secure communication between services.

• RESTful APIs (Representational State Transfer):

  • Architectural Style: REST is an architectural style, not a protocol. It relies on stateless, client-server communication and typically uses standard HTTP methods (GET, POST, PUT, DELETE) to perform operations on resources.
  • Data Format: RESTful APIs can use various data formats such as JSON, XML, or even HTML. JSON is the most common format due to its simplicity and ease of use.
  • Statelessness: REST APIs are stateless, meaning each request from a client contains all the information needed to understand and process the request. The server does not store any client context between requests.
  • Simplicity: RESTful APIs are simpler and easier to implement than SOAP APIs, making them popular for web and mobile applications.

• Microservices:

  • Architectural Pattern: Microservices is an architectural pattern for developing applications as a set of small, loosely coupled, and independently deployable services. Each service represents a specific business capability and communicates with other services via APIs.
  • Organization: Microservices break down a monolithic application into smaller, manageable services that can be developed, deployed, and scaled independently.
  • Technology Agnostic: Microservices can use various communication protocols, including RESTful APIs, but they are not limited to any specific technology. Services can communicate through APIs, message queues, or other means.
  • Scalability and Flexibility: Microservices architecture allows for better scalability and flexibility, as different services can be developed and deployed using different technologies and programming languages.

In summary, SOAP is a protocol with strict rules for message formatting, RESTful APIs are an architectural style for designing networked applications using standard HTTP methods, and microservices is an architectural pattern that focuses on breaking down applications into small, independent services for better scalability and flexibility. RESTful APIs can be used in both SOA and microservices architectures, but microservices are not limited to any specific communication protocol and can utilize various communication methods.

• Protocol:

  • Definition: A protocol is a set of rules and conventions that define how data is transmitted and received over a network. It specifies the format of messages, the order of messages, and the actions to be taken on the transmission or receipt of a message.
  • Example: HTTP (Hypertext Transfer Protocol) is a widely used protocol on the internet. It defines how messages are formatted and transmitted, and what actions web servers and browsers should take in response to various commands.

• Architectural Style:

  • Definition: An architectural style is a set of principles and constraints that guide the overall design of software systems. It defines the organization of the system components, their relationships, and the principles governing their interaction. Architectural styles provide a high-level abstraction of the system's structure.
  • Example: REST (Representational State Transfer) is an architectural style commonly used in web services. It emphasizes stateless communication, uniform resource identifiers (URIs) for resource identification, and standard HTTP methods (GET, POST, PUT, DELETE) for interaction. RESTful APIs adhere to the principles of the REST architectural style.

• Architectural Pattern:

  • Definition: An architectural pattern is a general, reusable solution to a recurring problem in software architecture within a specific context. It provides proven solutions to common design problems and helps in structuring the system's components and their interactions. Architectural patterns are more specific and detailed than architectural styles.
  • Example: Microservices is an architectural pattern where a software application is divided into small, independent services that communicate with each other through well-defined APIs. Each service represents a specific business capability and can be developed, deployed, and scaled independently. The microservices pattern addresses the challenges of developing and maintaining large, monolithic applications by promoting modularity, scalability, and flexibility.

In summary, a protocol defines rules for communication, an architectural style provides high-level design principles and constraints for organizing system components, and an architectural pattern offers a specific, reusable solution to common design problems within a particular architectural style. Architectural patterns are typically more detailed and focused than architectural styles, and they help architects and developers solve specific design challenges effectively.

• SOA is a design pattern in software design where services are provided to other components by application components, through a communication protocol over a network. SOA is not limited to any specific technology or protocol and can include various types of communication methods, including RESTful APIs.
• REST (Representational State Transfer) is an architectural style that uses HTTP methods (GET, POST, PUT, DELETE) and HTTP status codes to represent and manipulate resources. RESTful APIs adhere to REST principles and are designed to be stateless, scalable, and stateless, making them ideal for distributed systems and web applications.
• In the context of SOA, RESTful APIs can be one of the communication methods between services. In other words, you can design your services in a service-oriented architecture and implement some of these services using RESTful APIs. RESTful APIs are commonly used in modern SOA implementations due to their simplicity and scalability.

So, in summary, SOA and RESTful APIs can coexist, and RESTful APIs can be a part of a service-oriented architecture.

CrescentOne version one

Now more than two years back our company was acquired by Constellation INC. Besides a lot of changes in our daily operation we had to change our company name and had to move to a new 'major release' with another name.

C1V1 is the first release where all references to our former mother company are removed. At this moment, last quarter 2023 we are preparing the migration of the European 'add-ons' to fit in this version.

Part of the project will be preparing the content for the courses needed to support the projects for customers that will move to this new version. So expect courses that teach the fundamentals with updated screens and functions. In addition to that we will develop some courses that are fit for the more experienced 'Glovia' users and will support the migration projects to this new version.

More on that soon on this learning platform of CresentOne.

Eat your own dogshit. A term that I learned years ago when visiting Microsoft HQ in Redmond.

During the last years at CrescentOne I was invited to support the development of an Academy. With a background in didactics, building courses, running workshops and training sessions I do know what it takes to develop a course. How to effectively teach complex topics and how to measure progress and result.

As always, it takes time to develop that first cours(es) with enough content and a 'this is a good course' feeling. Can it improve? Sure and it will. In my brain, structures start to develop right after that moment. What is the next 'layer'? What is the next logical topic that will add a lot of value to students? This process never stops.

In a earlier post we informed about the tracks in development at the moment. And we do add content every day.

A second main track is called onboarding. Onboarding in an organisation is a poorly managed process in most organisations I know. If you're lucky you are asked to read the ISO handbook, or maybe follow some silly 'how to create a safe password' courses.

Don't get me wrong, organisations need to agree on how to govern these procedures. But really...

In my opinion recruitment doesn't stop after signing the contract. The time to get a new hire up and running has an impact on the department, the organisation as a whole and the return on the investment.

It is perfectly possible to present a set of effective courses, real challenges, that prepares new hires, currious collegues or interns to move from 'noobs' to well skilled starters.

Every instruction on technology is a candidate to add to this onboarding tracks. And that is exactly what I do. Most or those courses do have substantial content, are medium to hard. A lot of the content is curated - existing YouTube instructions, whitepapers or other discussions. The content challenges the students to think, form an opinion, try by them selves.

In these courses, measuring the progress, is not the first concern. But how would it be when we took onboarding by eating our own dog shit, more serious?

I believe that presenting these courses to the mix, will shorten the onboarding, lower impact on the organisation and improve the confidence of new hires. I believe that collegues working for years for the organisation, will be taken over by those new hires, if they do not spend time on those topics. I believe the cost of recruiting will be lower, because we know what we expect from the candidates.

I believe we should add this opportunity to our development programs to develop the organisation.