< class="prominent-subhead ">

Explanation of different access technologies that K2 offers when using SmartObjects.

This article has been archived, and/or refers to legacy products, components or features. The content in this article is offered "as is" and will no longer be updated. Archived content is provided for reference purposes only. This content does not infer that the product, component or feature is supported, or that the product, component or feature will continue to function as described herein.


The intention of this KB is to explain what the different access technologies are that K2 offers when using SmartObjects and suggested reasons when to use which access point.

Custom Web Service hosted on K2

The custom Web Service hosted on K2 is a 3rd party custom built Web- or Windows Communication Foundation (WCF) service that statically wraps to a specific SmartObject and its specific methods and parameters and knows about its specific behaviour. The SmartObject API is un-typed and uses a factory-like interface. Building this wrapper provides a static typed mechanism for developers to communicate with  SmartObjects. The wrapper needs to be updated when the SmartObject changes. Usually this kind of Web Service is built to interact with non-.net applications or distributed applications that cannot reference a custom assembly directly and can easily expose SmartObject data outside the firewall.


The K2 API is custom code accessing a SmartObject K2 API directly. This is beneficial for applications that can directly reference SmartObject API's and are code statically against specific SmartObjects and knows about its specific behavior. The SmartObject API is un-typed and you use a factory-like interface to hard code against specific SmartObjects. This code has to be updated when a SmartObject changes, but at least it is not tiered like a Web Service. This typically provides faster data access than custom Web Services purely due to less layers of indirection and serialization.

All SmartObjects in workflow is built against this API. It is highly performant and efficient.

K2 ADO.NET SmartObject Provider

The K2 ADO.NET SmartObject Provider is used when less code and less knowledge of the K2 API's are required. Developers who need to communicate with SmartObjects, with less knowledge about K2 or its API, can use standard ADO.NET nomenclatures to perform standard Create, Read, Update and Delete (CRUD) functions and even stored procedures type access into custom Line of Business (LOB) systems via SmartObject stack. A disadvantage is if the person using ADO.NET doesn’t know enough about the underlying Service Object or if it’s not a native SQL-based object, it can incur a lot of overhead to fetch all the data from backend systems to perform filtering in SQL. This is especially applicable to disparate composite objects.

K2 Reporting is using the ADO.NET Provider for RDL Reports due to its high performance

If the Service Object is considered native, the solution can be highly performant. K2 scrub the incoming SQL, but the query is passed directly on to SQL for execution on the native Database artifacts (eg. SmartBox, Reporting, DynamicSQL). Native SmartObjects will perform better with the ADO.NET Provider than with the SmartObject API.

The K2 ADO.NET SmartObject Provider is a very low barrier of entry regarding complexity into SmartObjects for developers that know standard SQL and can use data-bound controls.

Windows Communication Foundation (WCF) Endpoint

The WCF endpoint provides typed access into SmartObjects similar to custom services, except they are completely dynamic in nature. If a SmartObject is deployed, it immediately becomes available as a WCF endpoint without any code generation etc. When the SmartObject changes, the underlying WCF endpoint will automatically assimilate the new structure. (Old proxy stubs will still work as long as a field or method was not renamed or deleted)

No K2 knowledge is required with WCF endpoints, the entire SmartObject is self described in the WSDL (Web Services Description Language) and the developer has strongly typed access to it.

Similar to any other system, the WCF endpoint is limited in terms of performance when a "Get All" is performed without applying any filters.

REST and OData

REST and OData offers the exact same approach as WCF endpoints, except REST and OData make SmartObjects available to a much broader range of consumers over standard HTTP gets/posts. For example, Silverlight access for full CRUD into a SmartObject with a simple data-bound control is accomplished extremely easily.