Concepts

Overall description #

SICS API Server provides access to SICS functionality through Web Services. Web Services is an industry accepted standard for application interoperability.

SICS API Server enables the use of SICS as server component in a number of scenarios:

• Calling SICS functions from other applications, e.g. to request information from the SICS database (for example retrieving information for a business); perform an operation using SICS logic (for example exchanging a monetary amount using SICS’s exchange rates and rules, create a business or renew a business).
• Use SICS as a component in an Enterprise Architecture, allowing SICS to be integrated in external, (semi-) automated Business Processes
• Build new front-ends to existing SICS functions or modules using the customer’s choice of technology and “look-and-feel” (e.g. Browser Based front-end, Java front-end, Microsoft .NET front-ends)
• Reuse SICS’s repository of functions, business processes and data storage capabilities when building competitive advantage reinsurance applications, that has overlapping functionality with SICS.

Flexible client-server deployment #

From an internal application architecture point of view, the normal SICS end-user executable (SICS Workstation) belongs to category 2 in the illustration from Gartner Group below: SICS’s presentation layer and business functionality is packaged in the same executable, and consequently run on the same computer. Each executing SICS image serves one end-user. The database server serves all users. The SICS workstation communicates with the database (through JDBC) over a network.

• Since most customers deploy SICS using Citrix technology, the deployment architecture of SICS belongs to category 5: The SICS executable (containing both presentation and business functionality) executes on a Citrix Server that is connected to the database server over a LAN. The GUIs are sent to the end-user’s PC over a network (LAN or WAN - depending on where the user sits). Hence, only a very thin client (the Citrix client) is executed on each end-user’s PC. Some advantages with this deployment architecture are low requirements for end-users’ PCs, low WAN bandwidth requirements, easy- and low-cost operation/maintenance of the end-user’s PCs and that the architecture is scalable. A disadvantage is that one Citrix server can serve only a limited number of end-users (typically 20-30 depending on configuration), meaning a medium- to large sized organisation must operate multiple Citrix servers.

The SICS API Server component is a “headless” server component, i.e. it does not have a presentation layer of its own. However, one of the purposes of SICS API Server is to allow development of new, customized front-ends for selected SICS functions or modules. These front-ends can be developed in any programming language or development tool. The resulting client (e.g. a Java or HTML browser-based client) can be deployed in a 3-tier architecture: The client may run on the end-user’s PC, communicating with SICS API Server over the network (WAN / LAN). SICS API Server will communicate with the database server over a LAN (same as for the normal SICS workstation). Each SICS API Server installation can serve many end-users simultaneously (although with some limitations, as discussed in section “Multi-user, Serialized Processing”).

Figure 1 - Gartner Group’s Five Stages of Client/Server Computing

This flexibility in deployment applies also if SICS API Server is used as a component in an Enterprise Architecture or if its services are invoked directly by another application. SICS API Server may execute on any computer that is accessible by the calling application or Enterprise Architecture components over WAN, LAN or over the Internet.

“Headless” Reuse of SICS Business Processes #

In the normal SICS on-line system, users access and execute functionality through SICS’s Graphical User Interface (GUI). The various windows and dialogues display data to the user and let the user enter and modify the data. The appropriate security, business logic, validation and data transformation logic is invoked before the data is committed to the relational database.

All program logic that constitutes one “Logical unit of work” (i.e. all logic that takes place from a user initiates a transaction and until the transaction is cancelled or committed to the database) - is governed by Business Processes within SICS. Each business process executes a number of sub-processes (security check, pre-condition check, data entry, business validation, syntax validation, database commit). In case of a validation error, the system presents a message to the user and sets the business process back to the data-entry state.

The program logic for each sub process (or business process “state”) is programmed and encapsulated in separate layers in the internal SICS architecture.

By exploiting the object-oriented capabilities SICS internal architecture, SICS API Server reuses the business processes that are implemented for the SICS Workstation. But instead of accepting data from various windows, the business process takes its data from the XML formatted SOAP message. Status messages and validation errors are returned in the output SOAP message and not through the GUI or popup dialog boxes.

The diagram below shows how SICS API Server and the SICS Workstation components are packaged from the same underlying source code. (I.e. the same source code is reused in the two software components). The difference is in the interface layer. Where the Workstation has a Graphical User Interface, SICS API Server has a Web Services (XML based) interface.

This also means that when an error is corrected in SICS, the correction is typically only done once (i.e. there is no duplication of source code between SICS API Server and the SICS Workstation).

SICS API Server - Business Process Reuse #

Figure 2 - Business Process Reuse

Open Standards - SOAP and Web Services #

Several standards have emerged from widespread use of Internet and from the need for standardizing the description, exchange, transformation and presentation of data across applications.

These are some of the standards that SICS API Server utilizes:

Web Services / SOAP was chosen as the messaging protocol for SICS API Server because it is language- and vendor-neutral and easy to implement.

Alternative protocols are CORBA, RMI, and DCOM. These protocols assume a tighter link between requestor and provider. SOAP gives a rather loose coupling, which provides greater flexibility.

Note that if SICS API Server is used within an Enterprise Architecture, its services may be published to external applications through other protocols than Web Services. The Enterprise Architecture may contain adapters that can transform messages to/from different communication standards.

SOAP can be used in two modes, RPC mode (Remote Procedure Call) or Document mode with two types of encoding: soap encoding and literal (i.e. no encoding). SICS API Server can serve clients using both RPC and Document and it also support both soap encoding and literal. SICS API Server uses version 1.1 of the SOAP protocol as described in http://www.w3.org/TR/2000/NOTE-SOAP-20000508/.

Web Services WSDL files provide operational information about the service:

• Service interface
• Implementation details
• Access protocol
• Contact endpoints

WSDL Describes

• Types (e.g., XML data types)
  • Kinds of arguments and return values of operations
• Messages
  • Input and output parameters of an operation (sort of like a function declaration)
• Port Types (groups of operations)
  • Represents an abstract service interface
• Bindings
  • Port type associated with protocol
  • How things look on the wire (payload structure)
• Ports
  • Associations of bindings with network address
• Services
  • Groups of ports

The WSDL documents are typically broken into two parts, one describes the interface and the other describes the implementation, and bindings.

‘Interface’ WSDL file:

• Describes the data types that are coming in and going out over the wire.

• Describes the operations that can be performed, their inputs, outputs, and faults.

• Inputs and outputs are named data types specified earlier in the document.

• Binds the services to a message protocol, e.g., SOAP (may be a separate document). ‘Implementation’ WSDL file:

• Consolidates a series of ‘ports’ into a collection of services.

• Associates a ‘port type’ with a port.

In SICS API Server each entry point is described through a pair of WSDL files: An interface file and an implementation file. This is complemented by XML schema (.xsd) files that define the data types used within the Web Services request and response messages