A Super short note on SOA.
Date : 22 November 2016
Version: 0.5
By: Albert van der Sel
Status: Ready.
Remark: Please refresh the page to see any updates.
1. Introduction:
Suppose you are in a datacenter of some organisation, where a number of legacy systems
still have a prominent position, but that organisation also uses a mix of modern systems too.
Chances are, that there were all sorts of proprierty interfaces developed, proving for all sorts
of data exchange between those systems.
Many of such interfaces, will then have there own proprierty formatting and implementation,
and maintenance is likely to be difficult and time consuming.
The situation sketched above, could be a candidate for a SOA restructuring of those systems.
SOA uses (as much as possible) a standardized message format and exchange between systems.
Often, "connectors and interfaces" are used as needed to "tap" into the legacy systems,
while those interfaces are (usually) also connected to a Hub, or Bus, with routing functionality.
"Webservices" are those technological components which are indeed the "glue" to make that possible,
where those components adhere (as much as possible) to a set of standards.
Here, we see that SOA leads to a high level op "Application Integration".
Figure 1: Rather exaggerated view going from a forrest of Apps to SOA.
Ofcourse, the picture above is way from reality, except from some rare cases.
However, it should illustrate the main "target" of a SOA restructuring of IT business.
In a very succesful variant, business processes and modeling are really leading, and can with relative
low effort be translated to technical components for the actual implementation.
Often it is an XML-based workflow definition language in some "package", that allows businesses
to describe inter- or intra enterprise business processes, that are connected via Webservices.
Since XML data is usually a primary component of a SOA infrastructure, very large IO and processing/batches etc..
are no good candidates for a SOA conversion.
"Service Oriented Architectures" or "SOA", is an architecture (and also an understanding),
using a set of internet based technologies, architectured in such way, so that for
the components it generally holds that:
-have published contracts/interfaces,
-their delevopment is generally driven by Business processes,
-should be (in a high degree) Platform Independent,
-are Language Independent,
-should be (in a high degree) Operating System independent,
-should be "reusable" components,
-on a higher level, message passing is the prominent protocol,
-often operate in heterogeneous systems,
-often those heterogeneous systems are coupled through a message passing/routing Bus or Hub,
-use a "Registry" or repository, but preferably use some sort of dynamic discovery,
-often (generally) are loosly coupled (but that is not a very "hard" requirement).
Most of the above, applies to a software entity called "service", or more often, a "webservice".
Some keywords that are related to the technical implementations, then would be:
XML, SOAP (or REST), HTTP, WSDL, UDDI and probably an ESB (Enterprise Service Bus).
For about such a "Bus", it could well be a pretty "heavy" IBM Websphere, or Oracle Application Server
implementation, since such Application Servers can provide for a very "wide" infrastructure.
Where is the IPC? Well, SOA is certainly about communications between systems, but on a higher level.
For example, through message exchange of XML data using SOAP (or SOAP equivalent) envelopes via http.
Since it is heavily based on standards that came up with Internet technologies, we quickly think as TCP sockets
as to be the lowerlevel IPC. However, on a higher level, message exchange and message passing
are prominent IPC's in SOA. This is not to say that other IPC's are excluded.
We have Interprocess Communication on various levels. For a good understanding the typical messaging in SOA
needs to be described. I will try to do so.
2. High level message exchange:
1. XML
The datacontainer of a "message", is an XML document. This is a flat (ascii) file, starting with a declaration,
and next are lines starting and ending with "tags" which can be interpreted as data elements.
Here, unlike HTML, the tags do not say how data must be presented, but instead, how it must be interpreted.
A collection of "root" and "child" elements, sort of specify something that really looks like a record.
For example:
<customer>
<custID>428864</custID>
<name>John</name>
<order>117</order>
</customer>
Once the sender and receiver are aware of the "meaning" of the tags (like <custID></custID>),
that is, there exists agreement on the interpretation of the data, then usefull data exchange can take place.
Ofcourse, there is much more to say on XML, but that's not my goal here.
2. SOAP
SOAP (Simple Object Access Protocol) is a protocol used to "envelope" XML data, which resulting format then is
compliant to be send to a destination, using a high-level (IPC) protocol as "http" or "smtp".
This is no different than we already know from using the Internet, like accessing pages, downloading data etc..
So, indeed, a high-level application protocol as http is used to send- and recieve information.
Ofcourse, we know that http is an Internet standard, so the lower-level IPC protocol is sockets.
If you say that SOAP is good for "pure" data transmission, or "message exchange", then you are right.
However...., there is a second "way" where SOAP can be used.
SOAP can be viewed as the real-world successor of "XML-RPC", and that name probably rings a bell.
Indeed, SOAP can also be used for "message passing" which most folks interpret as accessing methods of remote objects,
or in simpler words, activating remote functions/procedures. This way, you can view it as the "Internet-way" of doing "RPC".
Or in the SOA context: SOAP can also be used to activate code on remote systems.
There are many ways how such XML-RPC could be implemented, but using SOAP/HTTP "end-points" is at least one "older" way to do that.
Here is an example for creating such endpoint in a database:
CREATE ENDPOINT SQLEP_test
STATE = STARTED
AS HTTP
(
PATH = '/EP_test',
AUTHENTICATION = (INTEGRATED),
PORTS = (CLEAR),
SITE = 'starboss.antapex.nl'
)
FOR SOAP
(
WEBMETHOD 'CustomerList'
(NAME='SALESDB.dbo.stp_ShowCustomers'),
WEBMETHOD 'InventoryList'
(NAME='SALESDB.dbo.stp_ShowInventory'),
BATCHES = DISABLED,
WSDL = DEFAULT,
DATABASE = 'SALESDB',
NAMESPACE = 'http://starboss.antapex.nl/test/showitems'
)
Note how also "real" methods (or stored procedures) are listed, like "stp_ShowCustomers", which can be called remotely, using SOAP.
The "key point" here, is that your webservice (the object with data and procedures) can be addressed using SOAP/HTTP.
See also section 1.6.
As a third way where SOAP is implemented, are UDDI SOAP requests and UDDI SOAP responses.
For that, please take a look below.
3. UDDI
Note how in the former subsection, we saw that through SOAP/HTTP, a procedure of a webservice could be accessed.
But how does a client service, "find" webservices, and their (exposed) methods?
You see it almost throughout all of IT. Often, there exists a (dynamical?) Repository, storing "mappings".
For example, the well-known DNS: it stores "friendly" names, and maps it to IP addresses.
Many other examples exist, like Active Directory. Such services acts like the "yellow pages" of a network.
When dealing with SOA and Web services, UDDI (Universal Description, Discovery and Integration) takes the role
of being a standard of registering webservices.
Figure 2: UDDI as a registering "repository or registry", for webservices.
Ariba, IBM, and Microsoft developed the first version of UDDI. As the name suggests, UDDI allows a webservice
to register the services it offers, and to discover and interact with other services on the Web.
At the heart of UDDI is the UDDI Business Registry, an implementation of the UDDI specification.
With the registry, a business can easily publish services it offers, and discover what services other businesses offer.
The registry is created as a group of multiple operator sites. Although each operator site is managed separately,
information contained within each registry is synchronized across all nodes.
Again, UDDI looks a lot like the familiar DNS, but this time for webservices and the "services" it may provide.
When you use a certain developing framework, you might use a SDK, or class libraries, or other "stuff",
that will provide for the neccessary UDDI interactions (maybe even "under the hood").
So, when a certain Service goes "live", the registering process might look like as shown in figure 2.
For registering and retrieving information, it uses the "UDDI SOAP requests" and "UDDI SOAP response" messages.
4. WSDL:
UDDI stores the published interfaces of the webservices, or the "published contracts/interfaces".
Now..., as the last step, we only need the "document" that indeed describes the methods of a webservice,
so that this document can be send to a UDDI service, and can also be obtained from UDDI.
For exactly that purpose, we have the WSDL document (or message).
WSDL stands for "Web Services Description Language". So, actually the name already tells you all.
Although WSDL can do more than is listed here, in essence, it specifies what operations are avaliable
in the webservice.
The WSDL document also defines the methods, parameter names, parameter data types, and return data types,
for the Web service. An application that uses a Web service relies on the Web service's WSDL document
to access the Web service's features.
In general, a WSDL can be rather lengthy, and rather complex. But sometimes the developing framework, supports
generating the correct WSDL.
Example of a few lines in a WSDL message:
<message name="GetLastTradePriceInput">
<part name="body" element="xsd1:TradePriceRequest"/>
</message>
We have seen some specific features in some common protocols in SOA, like SOAP (or REST), UDDI, WSDL,
which enables a high-level message exchange and passing, registering of services, and calling
methods of webservices.
That's it. Hope you liked it!