US has made more than $10 billion deals including military deal (which happens to be the sixth largest in US history) and 40 Boeing flight sales to private Indian Aviation operator and many others too with all these deals US could able to create 54,000 jobs back in their Home country

Think of us now? US has axed the H1-B, L1 quotas especially to Indians, they have hiked the fees, not only this they have targeted Indian at the port of entry to avoid Indian not to let them in US as many as possible over this 2 years. US have also taken crazy rules on the Indian citizens to deport them if they lose the jobs in US.

In spite of all of this, India is encouraging US to create Jobs back in their home country when we ourselves are struggling for the Jobs.

When would India start realizing all these facts, Wake up India, let’s build our country first and create lakhs of jobs in our countries before we sign up such a crazy deals.

The DotNetNuke content management system is designed to allow non-technical users to create and edit content and add custom features and personalize their web site look and feel. It can be extended with the addition of third-party DotNetNuke apps which include modules that provide additional web site functionality and tailored with custom graphics and layouts in the form of skins. More than 8,000 DotNetNuke apps are available for purchase on Snowcovered.com.

The DotNetNuke Corporation is the steward of the DotNetNuke open source project. The open source version of DotNetNuke is called the Community Edition and is available for free download on CodePlex. The Community Edition includes access to the source code of the framework and standard installation modules, and an MIT license [3] allowing flexible modification and distribution rights. The Community Edition is a popular web content management (WCM) system and application development framework for ASP.NET, with over 6,000,000 downloads and 600,000 production web sites as of October 2010.

Architecture

DotNetNuke uses a three-tier architecture model with a core framework providing support to the extensible modular structure. DotNetNuke can be extended using pluggable modules and providers that enable additional functionality. The look and feel of individual sites can be customized using skins. The following diagram illustrates the software layers of a typical DotNetNuke deployment: The current, 5.x generation of DotNetNuke requires IIS 6 and ASP.NET v2.0 to v3.5 and supports SQL Server 2005 and 2008. Previous generations of DotNetNuke supported SQL Server 2000 and ASP.NET v1.1.

Space Cake, Space Tea, Coffee Shops……..Amsterdam

Nice Beaches……Bali, Langkawi

Museums, History…..England, India

Fashion…….Paris

Technology, Hipe……………USA

Everest, Culture…….India

Tajmahal…….India

Tourism….France, Italy, Germany, Switzerland.

No Brainer Logic…… Dubai

Wildlife……South Africa

Wild Forest(Jungle)……Amazon

Never Visit……. Australia, New Zealand, UK (They are Racist Countries)

TOGAF 9 encompasses the entire enterprise architecture life cycle, which is important as architecture is a never ending journey, always changing and evolving. The figure below depicts the TOGAF Architecture Development Method (ADM) which covers the entire architecture life cycle.

The Open Group members were looking for an evolutionary step for version 9, not a revolution. Design goals for the release were greater usability, closer alignment with the business, and more guidance on SOA. To deliver on this, the Open group has expanded detail and clarification of existing proof points, focused on holistic enterprise change, created clear links between business and IT objects, including a metamodel for an enterprise architecture repository, and has provided more consistency of output deliverables. TOGAF 9 was developed around a web based view, and has a more modular structure than the previous version. Below is a depiction of the components.

There is also more guidance on how to use TOGAF in a consistent way within the enterprise. While there is no single architecture that fits all needs in all enterprises, there is a body of knowledge and capabilities to help organizations more successful in their enterprise architecture endeavors. This is what TOGAF 9 attempts to do – to show organizations how to apply the architecture development method (ADM) . And version 9 includes hooks to ITIL, Zachman, and other frameworks. This means that organizations looking to get a leg up on their SOA implementation by purchasing, for example, one of IBM’s industry solutions, will then have a way to incorporate the framework into TOGAF and bring it under a consistent life cycle management methodology. This will help organizations develop architectural competency and consistency – both essential to long term architectural agility and ROI.

For this release the Open Group has also created a metamodel for the TOGAF framework. In another post I plan to compare this framework to the OMG SOA Consortium framework. In an effort to increase usability, the Open Group has also published a metamodel on how the different components of TOGAF 9 relate to each other.

33 Features in WSS v3

Microsoft Office SharePoint Services 2007 Features:

107 Features Added in MOSS 2007*

Why it is used?

What is the significance of UML?

Download a PDF file from below link….. Enjoy…..

UML

Note: Right Click and select option as Save Target as….

Scrum Methodology

For many developers in the software industry, the agile methodology is nothing new. Most folks know that agile was a direct response to the dominant project management paradigm, waterfall, and borrows many principles from lean manufacturing. In 2001, as this new management paradigm began to pick up momentum, agile was formalized when 17 pioneers of the agile methodology met at the Snowbird Ski Resort in Utah and issued the Agile Manifesto. Their manifesto is now considered the foundational text for agile practices and principles. Most importantly, the manifesto spelled out the philosophy behind agile, which places a new emphasis on communication and collaboration; functioning software; and the flexibility to adapt to emerging business realities.

But for all of the strides the Agile Manifesto made in revising a philosophical approach to software development, it didn’t provide the concrete processes that development teams depend on when deadlines — and stakeholders — start applying pressure. As a result, when it comes to the nuts and bolts of running a team with agile every day, organizations turn to particular subsets of the agile methodology. These include Crystal Clear, Extreme Programming, Feature Driven Development, Dynamic Systems Development Method (DSDM), Scrum, and others. At my organization, we use Scrum and I’ve found it to be an incredibly effective management methodology for everyone involved, including developers and stakeholders. If you’re interested in learning about the other agile methodologies, there are plenty of resources out there. This blog is designed to provide some essential background for those who are new to Scrum.

What’s Unique about Scrum?

Of all the agile methodologies, Scrum is unique because it introduced the idea of “empirical process control.” That is, Scrum uses the real-world progress of a project — not a best guess or uninformed forecast — to plan and schedule releases. In Scrum, projects are divided into succinct work cadences, known as sprints, which are typically one week, two weeks, or three weeks in duration. At the end of each sprint, stakeholders and team members meet to assess the progress of a project and plan its next steps. This allows a project’s direction to be adjusted or reoriented based on completed work, not speculation or predictions.

Philosophically, this emphasis on an ongoing assessment of completed work is largely responsible for its popularity with managers and developers alike. But what allows the Scrum methodology to really work is a set of roles, responsibilities, and meetings that never change. If Scrum’s capacity for adaption and flexibility makes it an appealing option, the stability of its practices give teams something to lean on when development gets chaotic.

The Roles of Scrum

Scrum has three fundamental roles: Product Owner, ScrumMaster, and team member.

• Product Owner: In Scrum, the Product Owner is responsible for communicating the vision of the product to the development team. He or she must also represent the customer’s interests through requirements and prioritization. Because the Product Owner has the most authority of the three roles, it’s also the role with the most responsibility. In other words, the Product Owner is the single individual who must face the music when a project goes awry.

The tension between authority and responsibility means that it’s hard for Product Owners to strike the right balance of involvement. Because Scrum values self-organization among teams, a Product Owner must fight the urge to micro-manage. At the same time, Product Owners must be available to answer questions from the team.

• ScrumMaster: The ScrumMaster acts as a liaison between the Product Owner and the team. The ScrumMaster does not manage the team. Instead, he or she works to remove any impediments that are obstructing the team from achieving its sprint goals. In short, this role helps the team remain creative and productive, while making sure its successes are visible to the Product Owner. The ScrumMaster also works to advise the Product Owner about how to maximize ROI for the team.
• Team Member: In the Scrum methodology, the team is responsible for completing work. Ideally, teams consist of seven cross-functional members, plus or minus two individuals. For software projects, a typical team includes a mix of software engineers, architects, programmers, analysts, QA experts, testers, and UI designers. Each sprint, the team is responsible for determining how it will accomplish the work to be completed. This grants teams a great deal of autonomy, but, similar to the Product Owner’s situation, that freedom is accompanied by a responsibility to meet the goals of the sprint.

Understanding Forests

At the top of the Active Directory structure is a forest. A forest holds all of the objects, organizational units, domains, and attributes in its hierarchy. Under a forest are one or more trees which hold domains, OUs, objects, and attributes.

As illustrated in this image, there are two trees in the forest. You might use a structure like this for
organizations with more than one operating company.

You could also design a structure with multiple forests, but these are for very specific reasons and not common.

Domains

At the heart of the Active Directory structure is the domain. The domain is typically of the Internet naming variety (e.g. Learnthat.com), but you are not forced to stick with this structure – you could technically name your domain whatever you wish.

Microsoft recommends using as few domains and possible in building your Active Directory structure and to rely on Organizational Units for structure. Domains can contain multiple nested OUs, allowing you to build a pretty robust and specific structure.

Domain Controllers

In Windows NT, domains used a Primary Domain Controller (PDC) and Backup Domain Controller (BDC) model. This had one server, the PDC, which was “in charge” while the other DCs where subservient. If the PDC failed, you had to promote a BDC to become the PDC and be the server in charge.

In Active Directory, you have multiple Domain Controllers which are equal peers. Each DC in the Active Directory domain contains a copy of the AD database and synchronizes changes with all other DCs by multi-master replication. Replication occurs frequently and on a pull basis instead of a push one. A server requests updates from a fellow domain controller. If information on one DC changes (e.g. a user changes their password), it sends signal to the other domain controllers to begin a pull replication of the data to ensure they are all up to date.

Servers not serving as DCs, but in the Active Directory domain, are called ‘member servers.’

Active Directory requires at least one Domain Controller, but you can install as many as you want (and it’s recommended you install at least two domain controllers in case one fails).

Trust Relationships

Trust Relationships are important in an Active Directory environment so forests and domains can communicate with one another and pass credentials. Within a single forest, trusts are created when a domain is created. By default, domains have an implicit two-way transitive trust created. This means each domain trusts each other for security access and credentials. A user in domain A can access resources permitted to him in domain B while a user in domain B can access resources permitted to her in domain A.

AD allows several different types of trusts to be created, but understanding the two-way transitive trust is the most important to understanding AD.

Organizational Units

An Organizational Unit (OU) is a container which gives a domain hierarchy and structure. It is used for ease of administration and to create an AD structure in the company’s geographic or organizational terms.

Organizational Units

An OU can contain OUs, allowing for the creating of a multi-level structure, as shown in the image above. There are three primary reasons for creating OUs:

Organizational Structure: First, creating OUs allows a company to build a structure in Active Directory which matches their firm’s geographic or organizational structure. This permits ease of administration and a clean structure.

Security Rights: The second reason to create an OU structure is to assign security rights to certain OUs. This, for example, would allow you to apply Active Directory Policies to one OU which are different than another. You could setup policies which install an accounting software application on computers in the Accounting OU.

Delegated Administration: The third reason to create OUs is to delegate administrative responsibility. AD Architects can design the structure to allow local administrators certain administrative responsibility for their OU and no other. This allows for a delegated administration not available in Windows NT networks.

Groups

Groups serve two functions in Active Directory: security and distribution.

A security group contains accounts which can be used for security access. For example, a security group could be assigned rights to a particular directory on a file server.

A distribution group is used for sending information to users. It cannot be used for security access.

There are three group scopes:

Global: Global scope security groups contains users only from the domain in which is created. Global security groups can be members of both Universal and Domain Local groups.

Universal: Universal scope security groups can contain users, global groups, and universal groups from any domain. These groups are typically used in a multi-domain environment if access is required across domains.

Domain Local: Domain Local scope groups are often created in domains to assign security access to a particular local domain resource. Domain Local scope groups can contain user accounts, universal groups, and global groups from any domain. Domain Local scope groups can contain domain local groups in the same domain.

Sites

An Active Directory site object represents a collection of IP subnets, usually constituting a physical Local Area Network (LAN). Multiple sites are connected for replication by site links. Typically, sites are used for:

Physical Location Determination: Enables clients to find local resources such as printers, shares, or domain controllers.

Replication: You can optimize replication between domain controllers by creating links.

By default, Active Directory uses automatic site coverage, though you can purposefully setup sites and resources.

Replication

Since most Active Directory networks contain multiple domain controllers and users could theoretically attach to any DC for authentication or information, each of the servers needs to be kept up to date. Domain Controllers stay up to date by replicating the database between each other. It performs this using a pull method – a server requests new information from a different DC frequently. After a change, the DC initiates a replication after waiting 15 seconds (in Windows 2003) or 5 minutes (in Windows 2000). Windows Server 2003 uses technology to only replicate changed information and compressions replication over WAN links.

Windows Server sets up a replication topology to determine where a server updates from. In a large network, this keeps replication time down as servers replicate in a form of a ring network.

Active Directory uses multi-master replication. Multimaster replication does not rely on a single primary domain controller, but instead treats each DC as an authority. When a change is made on any DC, it is replicated to all other DCs. Although each DC is replicated alike, all of the DCs aren’t equal. There are several flexible single-master operation roles which are assigned to one domain controller at a time.

AD uses Remote Procedure Calls (RPC) for replication and can use SMTP for changes to schema or configuration.

FSMO Roles

All domain controll
ers are not equal. We know, it’s hard to hear. You’ve spent this whole time reading this tutorial thinking that all DCs are created equal and now we have to burst your bubble. Some DCs have more responsibility than others. It’s just part of life!

There are five roles which are called operations masters, or flexible single-master operations (FSMOs). Two are forestwide roles and three are domainwide roles. The forestwide roles are:

Schema master: Controls update to the Active Directory schema.

Domain naming master: Controls the addition and removal of domains from the forest.

The three domainwide roles are:

RID master: Allocates pools of unique identifier to domain controllers for use when creating objects. (RID is relative identifier).

Infrastructure master: Synchronizes cross-domain group membership changes. The infrastructure master cannot run on a global catalog server, unless all of the DCs are global catalog servers.

PDC Emulator: Provides backward compatibility for NT 4 clients for PDC operations – such as a password change. The PDC also serves as the master time server.

Global Catalog

As a network gets larger, it can contain multiple domains and many domain controllers. Each domain only contains records from its own domain in its AD database to keep the database small and replication manageable. The Active Directory domain relies on a global catalog database which contains a global listing of all objects in the forest. The Global Catalog is held on DCs configured as global catalog servers.

The global catalog contains a subset of information – such as a user’s first name and last name – and the distinguished name of the object so your client can contact the proper domain controller if you need more information. The distinguished name is the full address of an object in the directory. For example, a printer in the OU Accounting in the Learnthat.com domain might have a distinguished name of:

CN=AcctLaser1,OU=Accounting,DC=Learnthat,DC=com

The GC database is only a subset of the entire database called the Partial Attribute Set (PAS), containing 151 of the 1,070 properties available in Windows Server 2003. You can define additional properties for replication to the GC by modifying schema

In this tutorial, you will learn the basic structure of Active Directory, gain an understanding of how Active Directory works, learn how to install Active Directory, and learn the components of AD.

1. Dynamic Service and End Point discovery
2. Intermediate Routing Pattern ( Generic Routing Services)
3. Discovery announcement
4. Simplified Configuration
5. Protocol bridging and Fault tolerance
6. Standard End Points.
7. .svc-less activation of REST services or making REST URI nice.

Readers Note

I will discuss details of each feature in subsequent articles. This article is emphasizing on Dynamic Service and End Point discovery. So please tune in.

Dynamic Service and End Point discovery

Problem:

People say; you need to know only ABC of a service to expose End Point of that service. And client or service consumer needs to know only End Point to consume the service. But wait for a while here, and think; what if? Binding need to change at the service side from basic to WS over HTTP, This is very basic change but to accommodate this client has to update the service again. And this is very much error prone. It is very tedious task to update client about all the basic frequent change at the service side. To solve this issue, there should be some mechanism and that is called End Point Discovery or Dynamic Service.

In absolute technical words

WCF 4.0 supports WS – Discovery standard or protocol.

WS-Discovery Standard

1. This is a multicast protocol that issues SOAP message over UDP,
2. WS-Discovery is a Standard that defines a lightweight discovery mechanism for discovering services based on multicast messages. It enables a service to send a Hello announcement message when it is initialized and a Bye message when is removed from the network.
3. Client or consumer can discover services by multicasting a Probe message to which a service can reply with a ProbeMatch message containing the information necessary to contact the service.
4. Client or consumer can find services that have changed endpoint by issuing a Resolve message to which respond with a ResolveMatchmessage.

So, we can say WS - Discovery is a UDP based multicast message exchange. This message receives End Point information from Service and uses this as discovery information. Client uses discovery information to discover the available service on the network.

WCF Service Discovery API

WCF provides, WCF Discovery API for dynamic publish and discovery of web service using WS - Discovery protocol. This API helps service to publish them and helps client to find service on the network.

Modes:

Managed Mode:

1. In managed mode there is a centralized server called a discovery proxy that services use to publish themselves and clients use to retrieve information about available services.
2. When a new service starts up it sends an announcement message to the discovery proxy.
3. The discovery proxy saves information about each available service to storage.
4. When a client must search for a service it sends a Probe request to the discovery proxy and it determines whether any of the services that have been published match the request.
5. If there are matches the discovery proxy sends a ProbeMatch response back to the client.
6. The client can then contact the service directly using the service information returned from the proxy.

Ad-Hoc Mode:

1. There is no centralized server.
2. Service announcements and client requests are sent in a multicast fashion.
3. If a service is configured to send out a Hello announcement on start up, it sends it out over a well-known, multicast address using the UDP protocol.
4. Therefore, clients have to actively listen for these announcements and process them accordingly.
5. When a client issues a Probe request for a service it is also sent over the network using a multicast protocol.
6. Each service that receives the request determines whether it matches the criteria in the Probe request and responds directly to the client with a ProbeMatch message if the service matches the criteria specified in the Probe request.

Sample

In this sample, we will create a very basic service and at the client side, first client will discover the service in Ad-Hoc mode and then consume that.
To run and go through this sample, you need Visual Studio 2010 Beta.

To make a service discoverable, a ServiceDiscoveryBehavior must be added to the service host and a discovery endpoint must be added to specify where to listen for and send discovery message

Step 1

Open VS2010. Create a new project. Select project type as Web. From Web Project type choose WCF Service Application Project template.

Step 2
Delete all the code which is generated by Visual studio. After deleting Contract and Service Implantation is as follows.

IService1.cs

using System;
using System.Collections.Generic;
using System.Linq;
using System.Runtime.Serialization;
using System.ServiceModel;
using System.ServiceModel.Web;
using System.Text;
namespace WcfService1
{
    [ServiceContract]
    public interface IService1
    {
        [OperationContract]
        string GetMessage(string  msg);
    }
}

Service1.cs

using System;
using System.Collections.Generic;
using System.Linq;
using System.Runtime.Serialization;
using System.ServiceModel;
using System.ServiceModel.Web;
using System.Text; 

namespace WcfService1
{
    public class Service1 : IService1
    {
        public string GetMessage(string msg)
        {
            return msg;
        }
    }
}

The above is simple Service Contract and implantation of that.

Step 3:

Open Web.Config file. And modify the System.ServiceModel. Add the code which is highlighted below.

Web.Config

<system.serviceModel>
    <services>
      <service name=”WcfService1.Service1″ behaviorConfiguration=”WcfService1.Service1Behavior”>
        <!– Service Endpoints –>
        <endpoint address=”" binding=”wsHttpBinding” contract=”WcfService1.IService1″>     

          <!–
              Upon deployment, the following identity element should be removed or replaced to reflect the
              identity under which the deployed service runs.  If removed, WCF will infer an appropriate identity
              automatically.
          –>
          <identity>
            <dns value=”localhost”/>
          </identity>
        </endpoint>        
         <endpoint name =”udpDiscovery” kind =”udpDiscoveryEndpoint” />

         <endpoint address=”mex” binding=”mexHttpBinding” contract=”IMetadataExchange”/>
      </service>
    </services>
    <behaviors>
      <serviceBehaviors>
        <behavior name=”WcfService1.Service1Behavior”>
          <!– To avoid disclosing metadata information, set the value below to false and remove the metadata endpoint above before deployment –>
          <serviceMetadata httpGetEnabled=”true”/>
          <!– To receive exception details in faults for debugging purposes, set the value below to true.  Set to false before deployment to avoid disclosing exception information –>
          <serviceDebug includeExceptionDetailInFaults=”false”/>
         <serviceDiscovery />

         </behavior>
      </serviceBehaviors>
    </behaviors>
  </system.serviceModel>

Explanation of Config file

1. One new End Point is being added.
2. Kind of newly added End Point is udpDiscoveryEndpoint.
3. This End Point will be used to discover the service.
4. ServiceDiscovery behavior is also get added.

Step 4:

Press F5 to run the service. Service will get hosted in ASP.Net web server.

Step 5:

Add a new console project in solution.

Step 6:

Add Reference of System.ServiceModel.Discovery.dll in console project.

Step 7:

Add namespace using System.ServiceModel.Discovery;

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using ConsoleApplication1.ServiceReference1;
using System.ServiceModel;
using System.ServiceModel.Discovery; 

namespace ConsoleApplication1
{
    class Program
    {
        static void Main(string[] args)
        {
            DiscoveryClient discoverclient = new DiscoveryClient(new UdpDiscoveryEndpoint());
            FindResponse response = discoverclient.Find(new FindCriteria(typeof(IService1)));
            EndpointAddress address = response.Endpoints[0].Address;
            Service1Client client = new Service1Client(new  WSHttpBinding(), address);
            string str= client.GetMessage(“Hello WCF 4 “);
            Console.WriteLine(str);
            Console.ReadKey(true);
        }
    }
}

Explanation of the code

1. We are making object of DiscoveryClient class. This class is user to discover available service.
2. In constructor of this class, we are passing UdpDiscoveryEndPoint of the service.
3. Then we are calling Find method with contract name as argument to get FindResponse.
4. Now FindResponse variable having all the available address for contract passed in Find method.
5. We are creating the client proxy and passing discovered address as argument.
6. Calling the service operation on the client proxy.

Output: