Application Frameworks

As you can see, the trend in Data Access is to abstract into higher and higher levels within your applications. As data access libraries are generating entity classes, the question around locating data validation logic can become a slippery slope. If a data access generated entity can validate correct data types, maybe it should also validate that postal codes and phone numbers are of the correct format. Should they also cross-validate postal codes with states/provinces?
Should these error messages be managed inside of my entities? The waters can be muddied quite quickly.
It is therefore worthy to briefly mention a few of the more popular application frameworks that embrace a holistic view of data access in the scope of an application.
CSLA.NET (Component-based Scalable Logical Architecture) is a framework developed principally by author Rocky Lhotka in conjunction with his popularseries of Business Objects books. When first released, CSLA was focused on
Visual Basic 6, but over the years it has remained very current on the latest  Microsoft technologies and is now principally maintained in C# and ported to VB. In CSLA, data is fully encapsulated by rich business objects that manage all behavior including persistence. CSLA facilitates the re-use of business objects in many possible client technologies including ASP.NET, WPF, WinForms, and Silverlight including distributed architectures using Web Services.
DevForce from IdeaBlade is a commercially available framework for building rich, distributed applications in Silverlight, WPF, WinForms, and ASP.NET.
DevForce builds on top of the Entity Framework for its persistence layer and includes a Business Objects server for distributed architectures. DevForce is a popular application framework and has been around since 2001.

SyncML Introduction

1    SyncML Framework
This specification can be implemented by using the SyncML interface from the SyncML Framework (See Figure 2). Not all the features of the SyncML Interface need to be implemented to comply with this specification.
1.1.1    Figure 2 SyncML Framework
The application “A” depicts a networked service that provides data synchronization service for other applications, in this case application “B”, on some networked device. The service and device are connected over some common network transport, such as HTTP.
In the figure above, the ‘Sync Engine’ functionality is completely placed onto the OMA DS server side even if some OMA DS client implementations can in practice provide some sync engine functionality, too. The ‘Sync Server Agent’ and the ‘Sync Client Agent’ use the protocol defined in this specification and the representation protocol [DSREPU] offered by the SyncML interface (‘SyncML I/F’) to communicate with each other.
2    Device Roles
Figure 3 depicts a synchronization example in which a mobile phone acts as an OMA DS client and a server acts as an OMA DS server. The client sends SyncML message including the data modifications made in the client to the server. The server synchronizes the data (including possible additions, replaces, and deletions) within the SyncML messages with data stored in the server. After that, the server returns its modifications back to the client.
2.1.1     Synchronization Example with Mobile Phone and Server
The example presented the figure above is very simple. However, this example describes the roles of the devices in this specification. That is:
SyncML Client – This is the device that contains a sync client agent and that sends first its modifications to the server. The client MUST also be able to receive responses from the SyncML server. Although the SyncML client has always the role to send its modifications first, in some cases the server can have a role to initiate synchronization. The SyncML client is typically a mobile phone, PC, or PDA device.
SyncML Server – This is the device, which contains a sync server agent and sync engine, and which usually waits that the SyncML client starts synchronization and sends the clients modification to the server. The server is responsible for processing the sync analysis when it has received the client modifications. In addition, it can be able to initiate synchronization if unsolicited commands from the server to the client are supported on the transport protocol level. Typically, the SyncML server is a server device or PC.
3    Sync Types