SOA Reference Architecture : Service Component Layer (IV)

The Service Component Layer is partitioned into the following categories:

Service Realisation and Implementation 

  • Service Component : realises services
  • Functional Component : provides business functionalities in the realisation of the Service Component.
  • Technical Component : supports Functional Component. 

Service Publication and Exposure

  • Service Publisher : stores metadata about services in Service Repository (Governance Layer)
  • IDE : define and develop Service Components

Service Deployment

  • Service Deployment Manager : deploys Service Components to Services Container according to the Service Registry (Governance Layer) => automation.

Service Invocation

  • Service Invoker : invocation of the Service Components from the Service Layer.

Service Binding

  • Service Implementation Binder : transforms request from Service or Integration Layer to the required in-bound call of the Service Component (e.g. WSDL)
  • Method Input/Output Transformer : transforms from one format to another (Data Transformer - Integration Layer)
  • Service Implementation Adapter : used for legacy systems



The image below presents the interaction flow among runtime 
ABBs in the Service Component Layer :


  1. Service Invoker interacts with the Service Layer
  2. Call the Service Component
  3. transforms data formats
  4. passes control to the Service Implementation Adapter which interacts with the Operational Systems Layer
  5. map invocation into the Operational Systems Layer

Interaction with Cross-Cutting Layers

  • Governance Layer - Governance Service Repository : stores metadata and rules about services
  • Quality of Service - Access Controller + Policy Enforcer : enforce access control privileges and other policies
  • Information Layer : stores and retrieves metadata required by the components
  • Integration Layer : data transformation capability

Typical Interaction Sequences

This example illustrates the value of the Service component Layer : encapsulation.

For using legacy applications we will make usage of composition :


  • Each legacy application has an Adapter component.
  • A Service Enabler component is used to construct for example an SOAP-enabled Service Component.


Comments

Post a Comment

Popular posts from this blog

Spring JPA : Using Specification with Projection

You may probably know that using Specification with Projection is not possible at this moment. I'll show you how you can easily bypass this problem using the JPA Criteria. 1. Create an extended repository We begin by creating an extending global repository as follow : You can find more information here . 2. Add our custom method In order to limit the fields returned for each item, the consumer of my API must provide the required fields this way: /orders?fields=productId,name,quantity . ( Best Practices ) Basically, I'm defining the SELECT clause with the returned fields (cf. getSelections() ): 😎Happy coding...
Read more

Chip input using Reactive Form

The Chips component documentation from the angular material website, describes how to use the MatChipInput directive with a chip-list for adding or removing chips. I'll show you how you can implement the same component using Reactive Form. The HTML template: The TS component file:   As you can see, we use the FormBuilder class to simplify the form creation. We define our requirements as a  FormArray within our FormGroup. The requirements will be accessed in our template with this expression inside the *ngFor of <mat-chip></mat-chip> : *ngFor="let requirement of form.get('requirements').controls; let i = index;" In the ChipComponent class, the requirements array is accessed by using this expression: this.form.get('requirements') as FormArray; Thanks
Read more