Understanding Service Types, Service Objects and Architecture

Think of SmartObjects as an abstracted data access layer that exposes data and operations from data providers (such as web services, data stores or REST endpoints) to applications running in K2. SmartObjects are essentially a “middle layer” between sources of data and applications that require the data. K2 provides a number of standard connectors (known as "Service Types" or "service brokers") that can expose common Line-of-Business (LOB) systems as SmartObjects. However, it is possible to extend the standard set of Service Types with custom Service Types that integrate with other LOB systems. In K2, SmartObjects are the preferred mechanism to integrate your applications with LOB systems and therefore it is quite common to write custom Service Types to connect to other technologies not supported by K2 out-of-the-box.

SmartObjects act as a translator (or “adapter”) which takes the native entities and operations of the LOB system and converts the data and methods into an easy-to-understand, consistent interface that the consuming applications can understand. Internally, this is achieved through the use of technology-specific "connectors" called Service Types that expose Service Objects. Designers can then create SmartObjects that refer to one or more Service Objects, and then use those SmartObjects in their applications.

SmartObjects are executed by the server. Essentially, the server acts as the "engine" that will query the provider through the Service Type when a SmartObject is executed. While you can certainly use or "call" SmartObjects in many consuming applications, it is not the application itself that does the actual processing to retrieve the data from the underlying system: that task is performed by the server. Furthermore, the server does not cache SmartObject data; K2 will always retrieve the latest data from the provider whenever the SmartObject is executed.

Custom Service Types are implemented by creating a JavaScript (JS) library. The library would implement all the necessary logic/references to expose the provider's native objects and operations as Service Objects, and handles all interaction with the provider. Once the library is written and built, you would host the resulting JS file in an accessible location or upload it to the server, and then use Management to register a Service Type. Once the Service Type is registered, you can create one or more Service Instances for the Service Type, and then designers can create SmartObjects that use the Service Objects. To learn about the process of creating and using custom Service Types in K2, see the topic Introduction to the JavaScript Service Provider