Working with SOA services

Learning objectives
By the end of this learning module, you will have learned:

About Service-Oriented Architecture (SOA) services.
How to create a SOA definition.
How to create a SOA implementation.
How to configure the service in an environment file.

With increased adoption of REST and JSON, the SOA services approach is no longer in wide use. This module is in support of our next lesson on using a custom service.

Key concepts

SOA allows for different systems to specialize in what they do well and expose their capabilities over a standardized set of "services". Then all of these services can be easily combined and re-combined into useful solutions. The core idea is that systems talk to each other over well-defined contracts (or interfaces). These interfaces are made up of Service Models (the methods provided) and Information Models (the data structures used) to standardize communication. The intent is to provide a versioned contract for communication between systems that can protect a dependent system from internal changes in a system that it depends on.

Historically, this idea became very popular during the 2000s and became closely associated with the technologies and protocols of XML, SOAP, WSDL, and related technologies. The promise of the approach generated a great deal of hope and hype - that each system could be treated as a black box and that from version to version, dependent systems could be protected from change. Unfortunately, it didn't live up to the promise of simplicity and actually generated increased complexity. So the industry came up with a new name - micro services, and a set of new technologies - JSON and REST. This was really a step backwards until the industry came up with a contract language, or Interface Definition Language, now known as Swagger or OpenAPI.
We have evolved with these developments. SOA services were used to fit into the Enterprise Service Oriented landscape of XML, SOAP, and WSDL. We don't use this approach very much any more, but it is still available when developing a SOAP application interface (SOA API). More recently, we use the REST Model Services for integration.
In this learning module, we will introduce you to the ideas of SOA services in support of the next lesson that consumes WSDL and SOAP.
SOA services are made up of the following parts:
- SOADefinition - specifies the interfaces, service models, and information models of the service.
- SOAImplementation (or Implementation) - specifies the implementation of the methods of the service.

Creating the weather service definition

Learning activity

To create the weather service definition:

In NexJ Studio, create a new Service Definition using the File > New > SOA Definition menu options and name it training:Weather.

In the Source tab, drag and drop or enter the following code:

XML

<SOADefinition name="training:weather">
   <Service>
      <Interfaces>
         <Interface default="true" ref="main"/>
      </Interfaces>
   </Service>
   <Interfaces>
      <Interface name="main">
         <Method name="getWeather">
            <Arguments>
               <Argument name="cityName" type="string"/>
            </Arguments>
            <Result type="weatherResult"/>
         </Method>
      </Interface>
   </Interfaces>
   <Types>
      <Type name="weatherResult">
         <Attributes>
            <Attribute name="tempurature" type="decimal"/>
         </Attributes>
      </Type>
   </Types>
   <Bindings>
      <Binding protocol="trpc"/>
      <Binding protocol="soap"/>
   </Bindings>
</SOADefinition>

In the Interfaces tab, create a new interface called main.
Add a method called Creating the Weather Service Implementation.

Creating the Weather Service implementation

Learning activity

To create the Weather Service implementation:

In NexJ Studio, create a new implementation using the File > New > SOA Implementation menu options, and enter the name: training:Weather.

In the Source tab, drag and drop or enter the following code:

XML

<SOAImplementation service="training:weather:1.0">
   <Interface name="main">
      <Method args="cityName" name="getWeather">
         <Script><![CDATA[(:: training:weather:1.0:type:weatherResult
   :tempurature  
   (case cityName
      (("Toronto" "Chicago" "New York") -5)
      (("Milan" "Madrid" "Barcelona") 7)
      (("Dheli" "Sydney") 24)
      (else 20)
   )
)]]></Script>
      </Method>
   </Interface>
</SOAImplementation>

Adding the service to the environment file

Learning activity

In your environment file, add the following code in the SOAConnections section.

XML

<SOAConnection auth="perimeter" binding="context" service="training:weather:1.0"/>

See if you can access the WSDL for the service at http://localhost:7080/training/soa/training:weather:1.0/soap?wsdl.

You'll have the opportunity to try the service in the next learning module.