WS-Policy

WS-Policy is a specification that allows web services to use XML to advertise their policies (on security, quality of service, etc.) and for web service consumers to specify their policy requirements. WS-Policy is a W3C recommendation as of September 2007. WS-Policy represents a set of specifications that describe the capabilities and constraints of the security (and other business) policies on intermediaries and end points (for example, required security tokens, supported encryption algorithms, and privacy rules) and how to associate policies with services and end points.

• To integrate software systems with web services
• Need a way to express web services characteristics
• Without this standard, developers need docs
• Provides a flexible and extensible grammar for expressing the capabilities, requirements, and general characteristics of Web Service entities
• Defines a model to express these properties as policies
• Provide the mechanisms needed to enable Web Services applications to specify policies

WS-Policy specifies:

• An XML-based structure called a policy expression containing policy information
• Grammar elements to indicate how the contained policy assertions apply

Terminology:

• Policy: refers to the set of information being expressed as policy assertions
• Policy Assertion: represents an individual preference, requirement, capability, etc.
• Policy Expression: set of one or more policy assertions
• Policy Subject: an entity to which a policy expression can be bound

Policy Namespaces:

• WS-Policy schema defines all constructs that can used in a policy expression

Prefix	Description	Namespace
wsp	WS-Policy, WS-PolicyAssertions, and WS_PolicyAttachment	http://schemas.xmlsoap.org/ws/2002/12/policy
wsse	WS-SecurityPolicy	http://schemas.xmlsoap.org/ws/2002/12/secext
wsu	WS utility schema	http://schemas.xmlsoap.org/ws/2002/07/utility
msp	WSE 2.0 policy schema	http://schemas.microsoft.com/wse/2003/06/policy

MongoDB Fundamentals

MongoDB is a document-oriented DBMS. It uses JSON-like objects comprising the data model, rather than RDBMS tables. Significantly, MongoDB supports neither joins nor transactions. However, it features secondary indexes, an expressive query language, atomic writes on a per-document level, and fully-consistent reads. Operationally, MongoDB features master-slave replication with automated failover and built-in horizontal scaling via automated range-based partitioning.
Instead of tables, a MongoDB database stores its data in collections, which are the rough equivalent of RDBMS tables. A collection holds one or more documents, which corresponds to a record or a row in a relational database table, and each document has one or more fields, which corresponds to a column in a relational database table.

MongoDB Storage
A storage engine is the part of a database that is responsible for managing how data is stored on disk. Many databases support multiple storage engines, where different engines perform better for specific workloads. For example, one storage engine might offer better performance for read-heavy workloads, and another might support a higher-throughput for write operations. MMAPv1 is the default storage engine in 3.0. With multiple storage engines, you can decide which storage engine is best for your application.

MMAPv1 Storage Engine
A memory-mapped file is a file with data that the operating system places in memory by way of the mmap() system call. mmap() thus maps the file to a region of virtual memory. Memory-mapped files are the critical piece of the MMAPv1 storage engine in MongoDB. By using memory mapped files, MongoDB can treat the contents of its data files as if they were in memory. This provides MongoDB with an extremely fast and simple method for accessing and manipulating data.
MongoDB uses memory mapped files for managing and interacting with all data. Memory mapping assigns files to a block of virtual memory with a direct byte-for-byte correlation. MongoDB memory maps data files to memory as it accesses documents. Unaccessed data is not mapped to memory. Once mapped, the relationship between file and memory allows MongoDB to interact with the data in the file as if it were memory.

Database Properties

Atomicity and Transactions
In MongoDB, a write operation is atomic on the level of a single document, even if the operation modifies multiple embedded documents within a single document. When a single write operation modifies multiple documents, the modification of each document is atomic, but the operation as a whole is not atomic and other operations may interleave. However, we can isolate a single write operation that affects multiple documents using the $isolated operator.
Get more information at Concurrency.

Consistency
MongoDB is consistent by default: reads and writes are issued to the primary member of a replica set. Applications can optionally read from secondary replicas, where data is eventually consistent by default. Reads from secondaries can be useful in scenarios where it is acceptable for data to be slightly out of date, such as some reporting applications. Applications can also read from the closest copy of the data (as measured by ping distance) when latency is more important than consistency.
Get more information at Consistency.

SOA : Service-Oriented Architecture

What is Service-Oriented Architecture?
Service-Oriented Architecture (SOA) is an architectural style. Applications built using an SOA style deliver functionality as services that can be used or reused when building applications or integrating within the enterprise or trading partners. It is a method of design, deployment, and management of both applications and the software infrastructure where:

• All software is organized into business services that are network accessible and executable.
• Service interfaces are based on public standards for interoperability.

Key Characteristics of SOA

• Uses open standards to integrate software assets as services
• Standardizes interactions of services
• Services become building blocks that form business flows
• Services can be reused by other applications
• Quality of service, security and performance are specified
• Software infrastructure is responsible for managing
• Services are catalogued and discoverable
• Data are catalogued and discoverable
• Protocols use only industry standards

What is an Enterprise Service Bus (ESB)?

• An enterprise service bus is an infrastructure used for building compound applications
• The enterprise service bus is the glue that holds the compound application together
• The enterprise service bus is an emerging style for integrating enterprise applications in an implementation-independent fashion
• An enterprise service bus can be thought of as an abstraction layer on top of an Enterprise Messaging System

Key Characteristics of an ESB

• Streamlines development
• Supports multiple binding strategies
• Performs data transformation
• Intelligent routing
• Real time monitoring
• Exception handling
• Service security

Real-time Transport Protocol

The Real-time Transport Protocol (RTP) is a network protocol for delivering audio and video over IP networks. RTP is used extensively in communication and entertainment systems that involve streaming media, such as telephony, video teleconference applications, television services and web-based push-to-talk features.

RTP is used in conjunction with the RTP Control Protocol (RTCP). While RTP carries the media streams (e.g., audio and video), RTCP is used to monitor transmission statistics and quality of service (QoS) and aids synchronization of multiple streams. RTP is one of the technical foundations of Voice over IP and in this context is often used in conjunction with a signaling protocol such as the Session Initiation Protocol (SIP) which establishes connections across the network.

RTP was developed by the Audio-Video Transport Working Group of the Internet Engineering Task Force (IETF) and first published in 1996 as RFC 1889, superseded by RFC 3550 in 2003.

RTP combines its data transport with a control protocol (RTCP), which makes it possible to monitor data delivery for large multicast networks. Typically, RTP runs on top of the UDP protocol, although the specification is general enough to support other transport protocols. An RTP session is established for each multimedia stream. A session consists of an IP address with a pair of ports for RTP and RTCP. For example, audio and video streams use separate RTP sessions, enabling a receiver to deselect a particular stream.

Node.js Module

A module encapsulates related code into a single unit of code. When creating a module, this can be interpreted as moving all related functions into a file. Node.js has a simple module loading system. In Node.js, files and modules are in one-to-one correspondence. As an example, foo.js loads the module circle.js in the same directory.

The semantics of Node.js's require() function were designed to be general enough to support a number of reasonable directory structures. Package manager programs such as dpkg, rpm, and npm will hopefully find it possible to build native packages from Node.js modules without modification.

Core Modules
Node.js has several modules compiled into the binary. The core modules are defined within Node.js's source and are located in the lib/ folder. Core modules are always preferentially loaded if their identifier is passed to require(). For instance, require('http') will always return the built in HTTP module, even if there is a file by that name.

exports VS. module.exports

• exports is an alias to module.exports.
• node automatically creates it as a convenient shortcut.
• For assigning named properties, use either one.
   > module.exports.fiz = "fiz";
   > exports.buz = "buz";
   > module.exports === exports;
   true
  
• Assigning anything to exports directly (instead of exports.something) will overwrite the exports alias.

Named exports - one module, many exported things
Anonymous exports - simpler client interface

More information: https://darrenderidder.github.io/talks/ModulePatterns/#/, https://www.sitepoint.com/understanding-module-exports-exports-node-js/

Mobile Backend as a Service (MBaaS)

Mobile Backend as a service (MBaaS), also known as "backend as a service" (BaaS), is a model for providing web and mobile app developers with a way to link their applications to backend cloud storage and APIs exposed by back end applications while also providing features such as user management, push notifications, and integration with social networking services. These services are provided via the use of custom software development kits (SDKs) and application programming interfaces (APIs). Backend as a Service also refered as “turn-on infrastructure” for mobile and web apps.

BaaS providers tend to fall into one of two categories: consumer BaaS or enterprise BaaS. The former focuses largely on “lighter-weight” brand apps (and games), whereas the latter centers on mobilizing sensitive, business-critical data from enterprise systems. As a whole, BaaS providers are disrupting the on-premise “Mobile Enterprise Application Platform,” or MEAP, category, while providing a lot more turn-key functionality for your mobile strategy than traditional API management and Platform as a Service vendors.

Web and mobile apps require a similar set of features on the backend, including push notifications, integration with social networks, and cloud storage. Each of these services has its own API that must be individually incorporated into an app, a process that can be time-consuming and complicated for app developers. BaaS providers form a bridge between the frontend of an application and various cloud-based backends via a unified API and SDK.

Providing a consistent way to manage backend data means that developers do not need to redevelop their own backend for each of the services that their apps need to access, potentially saving both time and money.

Although similar to other cloud-computing developer tools, such as software as a service (SaaS), infrastructure as a service (IaaS), and platform as a service (PaaS), BaaS is distinct from these other services in that it specifically addresses the cloud-computing needs of web and mobile app developers by providing a unified means of connecting their apps to cloud services.

Compress LOB data in the database

SQL Server stores the data in regular B-Tree indexes in three different sets of the data pages called allocation units. The main data row structure and fixed-length data are stored in IN-ROW data pages. Variable-length data greater than 8,000 bytes in size is stored in LOB (large object) pages. Such data includes (max) columns, XML, CLR UDT and a few other data types. Finally, variable-length data, which does not exceed 8,000 bytes, is stored either in IN-ROW data pages when it fits into the page, or in ROW-OVERFLOW data pages.

Enterprise Edition of SQL Server allows you to reduce the size of the data by implementing data compression. However, data compression is applied to IN-ROW data only and it does not compress ROW-OVERFLOW and LOB data. Any large objects that do not fit into IN-ROW data pages remain uncompressed.

The approach to address such an overhead is manually compress LOB data in the code. You can create the methods to compress and decompress data utilizing one of the classes from System.IO.Compression namespace, for example using GZipStream or DeflateStream classes. Moreover, that method could be implemented in CLR stored procedures and used directly in T-SQL code. The drawback to this approach, compression is CPU intensive. It is better to run such code on the client whenever it is possible. The second important consideration is performance. Obviously, decompression adds an overhead, which you would like to avoid on the large scope.

Compressing LOB data in the database could help you to significantly reduce the database size in the large number of cases. However, it adds an overhead of compressing and decompressing data. In some cases, such overhead would be easily offset by the smaller data size, less I/O and buffer pool usage.