“The illiterate of the 21st century will not be those who cannot read and write, but those who cannot learn, unlearn, and relearn”

Alvin Toffler

Throttling: Concept of limiting the amount of work a service can accept. It can be set by concurrent calls (maxConcurrentcalls {16:default}), concurrent instances (maxConcurrentInstances {Int43.MaxValue:default}) or concurrent sessions (maxConcurrentSessions {10:default}).

InstanceContext class is a runtime object whose purpose is to bind a channel to instance of service object. It allows separation of channel and service and allow system to continue to have open, reliable and secure channel while disposing the service when the transaction or operation is finished. Default is that on message for service, new InstanceContext is created (controlled by InstanceContextMode)

Behaviors control the runtime characteristics of wcf services. The behaviors can be specified for service or operations. Unlike Contracts, behaviors are always applied to class implementing the service.

Service behavior configurations

1. AutomaticSessionShutdown (default is false): specify whether to close the session automatically when client closes an output session.
2. ConcurrencyMode: specifies the thread support for the service. Different modes are (1)single- service instance is single threaded and does not accept reentrance calls (2) Multiple – service is multi threaded. The synchronization and state consistency must be handled manually because no sync guarantees are made (3) Reentrant – service is single threaded and can accept reentrant calls
3. ConfigurationName – specifies the value used to locate the service element in config file
4. IgnoreExtensionDataObject – indicate whether to send unknown serialization data between service and client (default us false)
5. IncludeexceptionDetailsInFaults (default is false): specifies the service to send the exception back to client
6. InstanceContextMode- indicates when the new service objects should be created. The new instance context object can be creates (1) per call, (2) per session (default)or (3) single
7. ReleaseServiceInstanceOnTransactionComplete (default true): whether current service object be recycled when the current transaction is complete
8. TransactionAutoCompleteOnSessionClose (default is false): whether pending transactions should complete when current session is closed
9. TransactionIsocationLevel: Data that will be affected by transaction is called volatile data. The level of access other transactions have to volatile data before your transaction completes is called the isolation level
   1. Chaos: pending changes from more highly visible transactions cannot be overwritten
   2. Readcommitted: volatile data cannot be read but can be modified during transaction
   3. ReadUncommitted (lowest): volatile data can be read and modified during transaction
   4. Repeatable read: Volatile data can be read but not modified during transaction. New data can be added during transaction
   5. Serializable (highest): Volatile data can be read but not modified during transaction. No new data can be added during transaction
   6. Snapshot: volatile data can be read. Prior to modifying the data, transaction check for dirty flag and raise error is the data is dirty.
   7. Unspecified (default): level is undeterminable
10. TransactionTimeout (default is 1 min) – specify time span for transaction to complete
11. UseSynchronixedContext (default true) determines on which thread the service operation will run. If true, service will run on current synchronization context.
12. ValidateMustUnderstand (default is true): force application to perform the SOAP header mustunderstand processing otherwise fault message will be returned
13. AddressFilterMode: use to set the mode for the address filter. The mode will be used by the service dispatcher to route incoming messages to incoming endpoints. Possible options are (1) any (filter matches on any address of incoming message ), (2) exact (filter matches on exact address of an incoming message) and (3) Prefix (filter matches on longest prefix of address of an incoming message)

Operation behavior configurations

1. AutoDisposeParameters (default true)- should parameters of methods be automatically disposed
2. Impersonation – property let you identify specific methods in which to execute under the impersonated caller’s identity. For example service run with higher credentials that those of client. If client pass low privileged credentials to service then the service will execute using higher credentials allowing client to use resources (he should not). The possible values are Allowed, Not allowed (default) and required
3. ReleaseInstanceMode: it is used to determine recycle point of the service object during the operation. Using transaction this property is handy as it ensure that volatile data is cleaned up before method call is processed. The modes are (1) After call, (2) BeforeAndAfterCall, (3) BeforeCall, and (4) None (default)
4. TransactionAutoComplete: If true (default), successful transactions will be committed and errors will result in rollback. If false, transactions will need to be completed or cancelled directly via code
5. TransactionScopeRequired (default is false) – specify whether associated method requires a transaction scope. If true, all calls to service must run in SynchronizationContrxt on same thread.

Services can be defined as group of operations. The service need to have ServiceContract attribute and operation need to have OperationContract attribute.

Service contact defines the requirements that must be met i.e. message exchange pattern, message types, and data types those messages carry; and indicates categories of run-time behavior. It promises

1. The grouping of operations in one service.
2. The signature of the operations in terms of messages exchanged.
3. The data types of these messages.
4. The location of the operations.
5. The specific protocols and serialization formats that are used to support successful communication with the service.

Message exchange patterns

In Request/reply MEP pattern, request sender receives a reply with which the request is correlated. It means that sender waits until the return message is received (assuming no asynchronous operation). This can slow the sender/client performance and responsiveness as operation is blocked for response. The advantage is that the faults (processing/communication) can be returned in the response message.

In Duplex MEP pattern, client and service can send messages to each other independently using one way or request/reply messaging. It is used for providing asynchronous experience to either side of the message exchange.

In One-way MEP pattern, client of service should not wait for the operation to complete. Since no return message is expected, the return type should always be void and no fault message can be returned. This pattern supports event like behavior from client to service.

Tools

1. SvcTraceViewer.exe: service trace viewer tool to view, group and filter trace messages
2. Service configuration tool to configure web.config for service in UI
3. Windows Management Instrumentation for diagnostics (WMO) is used to find the services listening on machine and bindings in use
4. Message logs and event tracing are used to examine abnormalities and trace working of service

Variable data publishing (VDP) is used to create the customized material for 1-to-1 marketing. It involves taking data from wide range of sources & creating data stream. It automate the production of unique, relevant, individually customized communication material for increasing sales, acquiring leads or secure customer loyalty.

It involves

1. Defining the data assignment rules
2. Creating template that support actions to enable defining the design and layout of templates
3. Data support (demographic and image data support) – the database can include client stuff, advertising agency or marketing team or purchased item from outside source. The service provider will be responsible for data cleanup and preparation of integration with document layout. 
4. Producing documents – automatic inclusion of data in template, translated versions, output in multiple formats such as html, pdf, eps, tif, gif
5. Supporting admin users to monitor user activities, upload new templates, create templates and user groups, assign user access, set output preferences

Join combines records from two tables in database. In programming, one should take special care when joining tables on columns that can take null values as null will never match any other value. It is recommended to explicitly use the “is null” or “is not null” predicates. There are different types of joins

1. Inner join – combile records from two tables based on join predicate
   1. Equi-join -(theta join) only uses equality comparision in join predicate
   2. Natural join – spcialized equi join where join predicate arise implicitly by comparing all columns in both tables that have same column names in the joined tables. Not recommended to use becasue of inconsistencies arising due to schema changes over time
   3. Cross join (cartesian join) is cartesian product where join condition is always true
2. Outer join – join table retain each record and does not require each record to have a matching record.
   1. Left outer join – contain all records of left table even if join condition is not met
   2. Right outer join – contian all records of right table even if join condition is not met
   3. Full outer join – combine results of both left and right joins
3. Self join –joining a table to itself over predicate

Inner join is commutative and associative while outer join is not. It is responsibility of query optimizer to determine how to execute join. It has freedom to decide on join order and method. The optimizer decide the query plan and invoke join operation.

·        User transactions only when required. Single statements do not require transactions as individual update, delete or insert statements are inherently transactional.  

·        Stored proc is the best place to put transaction because they (1) avoid transaction to be opened for too long (2) Ensure best performance as all actions exec without requiring any network communication

·        SQL server stored procs can perform distributed transactions (requiring multiple data sources hosted on multiple servers). Distributed transactions are governed by windows DTC (distributed transaction coordinator) service

·        Isolation level determines sensitivity of transaction to changes made by other in progress transactions. It is closely related to concept of locks. Transactions support ReadUncommitted, ReadCommitted, RepeatableRead, Serializable. Two types of locks are (1) Exclusive locks and (2) Shared locks

·        Isolation matrix

o   Read uncommitted has dirty read, non repeatable read, phantom data. Best support concurrency

o   Read committed does not have dirty read, has non repeatable read, phantom data. Good support concurrency

o   Repeatable read does not have dirty read and non repeatable read, has phantom data, Poor concurrency

o   Serializable read does not have dirty read, non repeatable read, phantom data but very poor concurrency

·        Savepoints marks a certain point in flow of transaction and all rollback to that point

1. work remaining on Y axis and time on X axis 

Product burn down chart

1. burn down in work budgeted and planned as compared to decrease in work across time
2. business value on Y axis (stories)
3. sprint on X axis (number)

Earned business value graph

1. actual business value earned compared to planned business value
2. business value on Y axis ($)
3. sprint on X axis (stories)

Release burn down chart

1. story points pending on Y axis and iterations on X axis

T Shirt estimation

1. Estimation of stories is done using code “small, medium and large”.

1. mindset of team that work is either in sprint or not (no partial or % complete)
2. finding product owner who has proper knowledge and mandate
3. owner prioritize the items within sprint
4. orphans and unassigned, bugs and misc – outside the storyline (within scope)
5. keeping team constant (business analyst and technology)
6. design and architecture (consultant)

Goal of daily SCRUM meeting

1. Foster communication
2. Allow potential synergy
3. Make sure everyone has clear goals and plans
4. Risk identifications and mitigation plan
5. Person by person or story by story update

Roles : Product owner

1. responsible for ROI of project (most valued functionality at certain date within certain budget)
2. signoff on sprint scope,
3. accept or reject work results
4. prioritizes feature according to market value

Roles : Master

1. leader and facilitator, responsible for removing impediments, ensuring processes
2. shield team from external interferences and improving collaboration
3. enforce engineering practices

Tools: Executive dashboard

1. Highlights
2. Risks
3. Issues
4. Links