- 4 minutes to read

What is a Service?

You need to know the SOA architecture to maximize the usage of the Nodinite Repository Model.

A Nodinite Service represents one end of a communication chain and is, by definition a member, of a Nodinite System.

graph LR subgraph "Service" roSystem(fal:fa-dice-d6 System) roService(fal:fa-gear Service)--- |1..1| roDirection[fal:fa-directions Direction] roTCS(fal:fa-dot-circle Transport Contracts) roMessageType(fal:fa-file MessageTypes) roEndpoint(fal:fa-sign-in Endpoints) roService --> |1..1| roSystem roService -.->|0..*| roTCS roTCS -.-> |0..*| roMessageType roTCS-.-> |0..*| roEndpoint roService -.-> |0..*| roCF(fal:fa-paint-roller Custom Fields) roService -.-> |0..*| roCMD(fal:fa-tags Custom Metadata) roService -.-> |0..*| roR(fal:fa-lightbulb-on Resources) end

A Service in Nodinite has a unique name and contains information about the following other pre-defined properties:

  • System - either the sending or receiving side of the communication chain
  • Direction - one of the following
    • Send - One-way send, like to a file system
    • Receive - One-way receive, like from a file system
    • Two-way Receive - Like a Web Service that is being called by a consumer (Request/Response)
    • Two-way Send - Like a Consumer calling a Web Service, this is the outbound initiating call (Request/Response)
    • None - Not set, should be avoided
    • Unknown - Enough said...

Review the Endpoint Directions user guide for related information for Endpoints

You should name a Service like this:

  • SVC001 - Receive Invoices from Customer A
  • SVC001 - Send monthly salary to the bank

TIP: Having a unique identifier part like SVC001 in this example makes it possible to filter a large number of Services, making the administration much simpler

This naming convention will make the notion of Services easier to understand and follow. There are many information elements in the examples. Transportation of messages, this information in the Endpoints. The 'Invoice' and 'Salary' are the Message Types. In the examples, you will also find out the direction for the message. The source or destination was also mentioned; 'Customer A' and 'Bank' are the System.

Custom Metadata

As with all the entities of the Nodinite Repository Model, a Service can have any number of Custom Metadata fields assigned.

Custom Fields

As with all the entities of the Nodinite Repository Model, a Service can have any number of Custom Fields assigned.


New 6.0

The System Administrator can add one or more Resources from the Monitoring and assign these to the Service. Doing so presents the Service with the Monitoring State (the most severe state it the chosen one) in the Integration Landscape.
Service with Resource
Sample screenshot of the Interactive Landscape feature.

To add a Resource, Edit the Service, then click Edit on the Resources panel.

Empty Resource list for Service
Example when there is an empty configuration.

Next, select any number of Resources.

Service with associated Resource
Example with a Resource tied to the Service.

With Nodinite 6.1 you can also add Custom Metadata to Resources.

Transport Contracts

Transport contracts define one or more log points. The Transport Contract is always a combination of one or more Message Types, Endpoints,

Simple log point example

The most basic example would be exactly one specific message (Message Type) for example an invoice, that goes in (Receive) or out (Send) on one specific transport location (Endpoint). This

graph TD subgraph "Transport Contract " subgraph "Logpoint" roMT(fa:fa-file Message Type) roEP(fa:fa-sign-in Endpoint) end end

When you create a New Service the list of Transport Contracts is empty. You can either create new Transport Contracts from the management page OR if you are a Nodinite administrator you can more easily bind logged messages to the Service.

Empty Transport Contract

Shared Endpoint example

Let's imagine the actual endpoint in use is a shared endpoint like a shared mailbox (info@company.com). To separate different flows of information for end-users you can create multiple Services with different sets of definitions for Transport Contracts where you filter on relevant combinations of Message Types and Endpoints.

graph TD subgraph "Transport Contract " subgraph "Logpoint" roMT(fa:fa-file Message Type, 'Order') roMT2(fa:fa-file Message Type, 'Order Response') roEP(fa:fa-sign-in Endpoint) end end

Multiple Endpoints for the same Message Type example

Let's imagine now the same message (Message Type) is distributed on many different Endpoints (for example the old production environment and the new production environment).

graph TD subgraph "Transport Contract " subgraph "Logpoint" roMT(fa:fa-file Message Type, 'Order') roEP(fa:fa-sign-in Endpoint, 'Old port') roEP1(fa:fa-sign-in Endpoint, 'New port') end end

Transport Contract
Add, Edit or Delete Transport Contracts.

Read more about managing Transport Contracts on this page.

Next Step

Add or manage Service
Add or manage System
Add or manage Endpoint
Add or manage Message Types
Add or manage Integration

Next Step

Repository Model
Message Types
Endpoint Directions
Log Views