Some useful registry tweaks for developer!

To get command prompt on the right click:

1. Open regedit.exe from Run menu

2. Navigate to

HKEY_LOCAL_MACHINE/Software/Classes/Folder/Shell

and create a key called "Command Prompt".

3. Set the default string to "Command Prompt" or simply "CMD", since this text will come when you right click on a FOLDER.

4. Create a new key within the newly created command prompt named "command," and set the default string to

cmd.exe /k pushd %L

5. Refresh By pressing F5.

PS: This works on NT based System. Also, the right click should be on a FOLDER. If you open the folder and the click on the screen area, then it won't work.

==================================================================

To Get Tabbed browsing in Command Prompt:

1. Open regedit.exe from Run menu

2. Navigate to

HKEY_LOCAL_MACHINE/SOFTWARE/Microsoft/Command Processor

3. Set PathCompletionChar = 0X9

4. Set CompletionChar = 0X9

PS: 0X9 is Hex digit 9.

Risk Management Process

Risk Management Process
Every organization or business has a mission to accomplish. Their management should provide, that the work to accomplish the mission should go in its expected way by identifying and preventing the risks before those risks arise in a problem; in other words by including risk management in their regular management process.
By this perspective, Risk Management field has come into existence and has gained popularity in challenging environment of the world. Risk management has vital importance to all size of companies, organizations, business units or projects in different markets and sectors.
What is Risk?

Risk is a probable event or situation, with a potential for either positive or negative impact on the project.
Risks in projects can be placed under different categories like Customer, Infrastructure, Communication, Lack of Domain/Technical Knowledge etc

What is Risk Management?

Risk Management is the set of activities directed towards improving the probability for a positive impact or reducing the probability for a negative impact and managing the outcome if the risk event occurs.

What are the steps involved in Risk Management?

Risk management involves several important steps given below:
1. Risk identification
2. Risk classification, analysis and prioritization
3. Define strategies for risk management
4. Tracking and controlling risks

Communication on risks is a process which is relevant to all the 4 steps above.

1. Risk Identification:

· The risk identification process involves identifying the different sources of risk (or risk categories) and applying an appropriate risk identification technique to identify the project risks.
· Project manager along with the team should identify all positive as well as negative risks. Internal as well as external risks should be identified as both can affect the outcome of the project.
· An internal risk happens within the project and can be controlled within the project team. External risks are outside the control of the project team for example, earthquake, terrorism, power outage, changing market trends etc.

2. Risk Classification, Analysis and Prioritization:

· Risk is classified based on the categories or based on the source, after which the analysis is done.
· Risk analysis begins with a detailed study of the key risks that have been identified.
· The objective is to gather enough information about the risks to judge the risk exposure on key project goals (for example, cost, schedule, and performance, etc.) if the risk occurs.
· The total risk exposure could be determined based on probability (or likelihood) of risks and impact (or consequence) level of risks.
· Risk exposure helps a great deal in risk response planning and prioritization. This also helps in relating risks to costs and linking as a factor to cost estimates for the project.
· The risk quantification uses a numeric scale, usually from 0 to 1, to measure the probability of an event occurring, where 0 means an event would not occur and 1 means it will occur. The impact is measured on a scale of 0 to 10, where 0 means no impact and 10 means the maximum impact possible.

A guideline to select a Impact & Probability value for a Severity is given below:

Impact Range
Severity
1 to 3
Low
4 to 5
Medium
6 to 7
High
8 to 10
Very high

Impact value and its severity

Probability Range
Severity
0.1 to 0.2
Low
0.3 to 0.6
Medium
0.7 to 0.9
High

Probability value and its severity

To get the risk exposure, the following formula can be used:

Risk Exposure = Probability * Impact

For risks having direct impact on cost and having a high risk exposure, find out cost impact of risks that exceed a threshold value of probability (0.7) or impact (7). Even while planning out contingencies, one must take care that adequate contingencies are available for top risks.
Risks prioritization is done by ranking them all from highest to lowest.
The following is an example of a risk list:

Risk Description
Probability
Impact
Exposure
Comments
Link connectivity not ready on time during transition of project from onshore to offshore
0.2

9

1.8
Chances of this happening are very less, but its impact is very high. Hence overall exposure is not above threshold value.
Interface implementation not completed well before System Testing Phase
0.5
7
3.5
Though its impact is not very high, the probability is very high and that makes this risk a high priority risk.

Web Service Performance Considerations

Web Service is getting pervasive, it is hard to find a project without web services nowadays. When the SOA maturity level is "entry level", Web services are extensively used as an integration mechanism. In the higher maturity levels of SOA, applications are assembled out of Web services called SOBA or Service Oriented Business Applications. SOA itself is in the native stage of the Adoption curve.
Two key challenges of adoption are the performance and security of web services. Better performance is a catalyst for successful design deployment of web services.

This volume addresses the various performance considerations for the design of web services.

Web Service Performance Considerations

The focus of this article will be on performance considerations for Web services-based solutions. The value proposition of Web services is its enablement of interoperability, flexibility, reuse of assets, reduction in development and operational costs, and better relationships with business partners and customers.

The three most common web service performance bottlenecks are:
Parsing SOAP messages
Marshalling and un-marshalling of Objects to XML and vice versa
Providing security to the data


To improve Web Services, the following set of practices are used to direct the design to optimize performance:

1. Payload size versus payload complexity - It is always good to have simple and small messages as payload in any of the web services. Based on the business needs, occasionally it is needed to process complex XML. Larger messages result in longer parsing times while complex XML structures with nested elements result in longer times for the marshalling and un-marshalling of Objects and XML elements. The goal is here to reduce the payload size of complexity of the XML data document. It is good to choose to support a single invocation that includes a larger and more complex message versus supporting separate individual message transactions. Persistent connections are good for performance in case of a large number of messages of small payload size. In case of large payload Streaming connections are good for performance.

2. Document/Literal versus RPC/SOAP encoding - With Document/Literal approach there is no type encoding information. It is easy to validate the message as everything appears in soap:body message schema. The method names are available in the SOAP message and it is WS-I compliant. With RPC/SOAP the WSDL is as straightforward as it's possible for WSDL to be. It is easy for the receiver to dispatch the message to the implementation of operation as the operation names appear on the message. But the disadvantage is the type encoding info is usually an overhead, it cannot be easily validated and it is not WS-I compliant.

3. Parsing of SOAP messages - Minimize parsing XML data - Often a business function needs to be exposed as an XML service that leverages SOAP for both internal and external consumption by business partners minimizing parsing of the SOAP messages. In such cases, it is good to leverage on partially parse SOAP messages to minimize their impact on performance. While comparing DOM and SAX it is good to parse the messages with SAX but we have STAX parser developed for Java community which reduces the time to parse the XML messages. Other practices like zipping the message and binary encoding of message will help to improve the performance. It is recommended not to enable message validation through the parser if performance is a high priority. STAX gives a precise control over XML document processing with simple iterator base API and an underlying stream of events or cursor style object API. As distinct from other event-based approaches STAX allows to stop processing of the document, skip ahead to sections of the document, or get subsections of the document.

4. Marshalling and un-marshalling - It is good to design/define the message architecture to maximize the size of information that will be exchanged over the net. Messages with many elements and attributes and little data are part of any complex XML schema. Parsing SOAP messages is viewed as the biggest contributor to the performance issue. However, a complex message structure can also result in more than 50% of the processing time being associated with marshalling and un-marshalling of Objects and XML elements.

5. Security approach - Security has performance costs; the key information is secured and also makes sure that you are not securing the data which may not be secured over the network. WS-Security technologies are costlier than in terms of performance comparing with traditional SSL with HTTP. Best practice is to combine the two approaches, SSL for encryption and XML digital certificates (signatures) for authentication.

6. Web Service design - Design Web service interface to minimize the network traffic by defining a 'coarse-grained' API. With this design the number of requests from client service to server service will be minimized.

7. JavaBean versus EJB components - If the solution doesn't require the J2EE runtime support for transaction, security, and management that's enabled through the use of EJB components and the EJB container, then JavaBeans will suffice and will provide better performance. If the solution is using EJB components and deploying them locally within the same JVM as the SOAP engine, then ensure to deploy them in such way that they are called using pass by reference. By enabling pass by reference, the parameters of the method are not copied to the stack with every remote call, which can be expensive. Enabling pass by reference can improve performance up to 50%, when the SOAP engine (EJB client) and the Web service provider (EJB Server) are installed in the same application server instance and remote interfaces are used.

8. Optimizing performance using cache - For Web services that support HTTP, cache the results of their processing for use on future requests. And it is useful in the read-only type of web services.

9. Retrieval of service bindings from a UDDI registry - UDDI registries are used to publish Web services information for dynamic discovery. On client's service invocation, the UDDI registry returns access point of the service. It can be achieved with front-end the local service proxy created from the service provider's WSDL with a general proxy that queries the UDDI registry and caches the access points for a given period of time. The client application calls the general proxy that calls the service proxy to invoke the service provider.