ice.NET Services

Service-oriented architecture (SOA) is relevant for information systems based on ice.NET for two reasons:

  • Software applications have to be integrated into a IT system landscape. In an overall IT concept services play a crucial role as a provider of functionality as well as way to define interfaces between system components.
  • Services are a powerful abstraction to help organizing the structure of the Business Logic of a software component. The definition and implementation of a service as a part of the business logic is technology-independent and therefore a suitable basis for the automatic generation of interfacing components to different communication technologies optimized for various usage scenarios (Smart Client, Rich Client, SOA Integration, etc.) from a single business logic implementation.

Services are especially suitable for the integration of Business Logic with User Interface technology because significant reuse effects can be achieved without affecting and therefore compromising the quality of the individual UI design.

Business Logic Layers

In general, the Business Logic of an information system can be separated horizontally in three layers:

The following table describes the functions of the three layers:

Layer Role Description
Model Persistence, Consistency The data model contains the static characteristics of the information system described in a standardized specification language (UML) in a detailed way. UML provides a powerful set of abstractions to describe the relevant consistency rules. The ice.NET platform can derive the technical integration to persistence technologies (SQL, XML) directly from data model.
Business Objects Functionality Business Objects represent the dynamic characteristics (behavior, functionality of the information system. The ice.NET Business Objects Framework („BOF“) supports the Design and Implementation of this functionality based on object-oriented mehodology. The structure of this functionality is described in terms of entities (types, classes). Therefore it is very fine-grained and not suitable to directly derive system interfaces.
Services Interface, Business Transactions The Business Services provide a technology-independent description of the visible "outer" functionality of the software system. The services are assembled from service methods that follow service-oriented architecture principles ("explicit", "autonomous", "contract-based/self-describing"). For service methods qualify suitable Business Objects methods that have been designed with interface characteristics in mind and separate, type-independent methods that have been specially designed for service usage. A complete set of coherent methods represent the "service". Based on this service definition, specific technical scenarios (e.g. SOAP Web Service) can be efficiently implemented with the help of suitable tools (e.g. the ice.NET Service Builder).

Explicitly establishing the Service layer enables efficient, tool-supported development of different system architecture alternatives without redundant maintenance of different, technology-specific implementations. Considering typical information system usage scenarios that require Web Clients („thin client“) as well as low-maintenance Smart Clients in addition to integration interfaces to other systems or the "Enterprise Service Bus", the relevance of efficient, automated, reproducable generation of the technology-specific system components becomes obvious. For certain special scenarios where decentral, mobile ("offline") processing capabilities are required, the classic architecture alternative "Rich Client" must be supported as well.

The following diagram illustrates the context and commonalities of the architecture alternatives:

All variants share the same business logic according to the layer pattern described above. The interoperability layer above the service layer does not contain any domain logic and can be automatically and reproducably generated from the interface definition of the service layer. Therefore, the implementation of the client layer (user interface or external interface) can access a unified programming interface. Client implementations on top of the unified interface are technology-neutral and compatible to all of the different architecture variants. For example the same desktop application can run against a local database (Rich Client) as well as a SOAP-based WebService interface installed on a central server or in a cloud environment (Smart Client).