Integrate with client-server architecture

The SDK's usage in this architecture is named Non managed mode.

The administration of card types is done by your application using the CardDesigner/EncodingConfigurator or CardComposer. The CardDesigner is only used to design the layouts. No data is stored locally. Your application has to store and manage card types itself. Production is done by creating a card job with layout data, encoding description data, variable text and image data. In this mode, no local files are referenced - all data is exchanged between your application and the components.

Typical examples for such an architecture are ASP.NET or J2EE applications where multiple workstations need to edit layouts or produce cards. The big advantage of this architecture is that no local data is used (except some device settings managed by the Configuration Manager). You may use as many workstations for card design and production as required. Every workstation accesses the card type definitions with layouts and encoding descriptions which are stored centrally in your server database. For this reasons, this is the recommended way to use the SDK in a Client-server architecture.

In this architecture the CardDesigner is only used to design card layouts. It no longer manages card types as done in the standard Windows or fat-client architecture.

The EncodingCongfiurator is used to select and edit prepared encoding description files. Layouts and encoding descriptions are administered and stored by your application in your server database as card types.

The CardComposer is available in this architecture. This application is optionally used to support your application to create or modify a card type definition. You can add, edit and remove layouts and encoding descriptions. The CardComposer itself uses the CardDesigner and the EncodingConfigurator.

As indicated in the figure, you may either call CardDesigner and EncodingConfigurator directly or use the CardComposer to retrieve the functionality of card type definition. For more information, see heading "Use CardDesigner EncodingConfigurator vs. CardComposer" in Define cards.

The Capture Component is the component to capture images at any time before production. Your application stores the images as BLOBs in your server's database. When producing the card, your application provides the binary image data for the production component, just as the textual data.

The Production Component is used for card production. You create a card production job by using a card definition that was formerly defined by your application (supported by using CardDesigner/EncodingConfigurator or CardComposer). The card definition is enriched with values for variable text fields and images and sent to the production component as card job. Note: In contrast to the standard Windows application architecture the complete data for layouts and encoding descriptions must be provided. Only providing a reference to a local card type is no longer sufficient.

The dotted line in the picture above indicates that the production component may also be triggered from the server side application part. Using the corresponding SDK's web service request, you can trigger it from anywhere without installed SDK software on the triggering machine.¹

¹ In principle it would also be possible to trigger the requests for capturing, card design and card definition from the server side application part. However, this approach has disadvantages which do not really recommend such a solution. The main disadvantage is the network access of a client initialized by a server. This is prevented in typical business network infrastructures where a client's firewall will block incoming requests. Furthermore, there may also arise issues when one of these methods, which uses a user interface and waits for a user's input, would be called on an unattended machine. For this reasons, all user interface combined requests are blocked by the SDK when requested from another machine. However, starting a CardJob from Server side may actually be a recommended feature with the real benefit of an independent and dedicated card production unit.

In this Client-server architecture, the components may be distributed on different machines for the following typical use cases:

An administration client may be used to edit the card types using CardDesigner/EncodingConfigurator or CardComposer
A registration client may only use the capture component to capture photos and other biometric data. It can also use the web service to build card previews.
A production client may be used to produce cards. As the production basically does not require any user interface, it allows the use of a dedicated PC or an embedded unit without screen. The Nexus IDBox is exactly such a device, available as appliance. Its only function is to process card jobs using a connected printer and encoding devices. Note that the SDK has to be installed on each of these systems.

The first example for this type of application is the HTML example, that demonstrates this architecture in combination with JavaScript. The HTML page, sent from a web server, is running in the browser and uses layouts and encoding information hosted on the application server. Note that the demonstration of this mode requires the Managed Mode option deselected in the example HTML page.

In addition, we also provide the Java (Client-Server) example which focuses on how to use the SDK in a Client-server application. It is not really a Client-server application, but demonstrates the typical SDK components and functionality for such an application. Especially, it is the only example that demonstrates the usage of the CardComposer. It also emphasizes the different use cases administration, registration and production and how they can be implemented in different workplaces.

The link to the examples is located in the folder with the corresponding name in the examples directory of the SDK installation. The HTML example can also be found entering the URL http://localhost/:54880/components.htm in your browser.