ALM Architecture and Modeling Features

• Diagrams that comply with Unified Modeling Language (UML) 2.1.2: sequence, class, component, activity, and use case
• Layer diagrams
• Code-generated sequence diagrams and dependency graphs
• Architecture Explorer
• Architectural validation
• Integration with work items in Microsoft Visual Studio Team Foundation Server
• Extensibility for UML diagrams

Brainstorming a project using Visual Studio 2010

Business Context

•Introducing Tailspin Toys

 –Small Brick and Mortar hobby shop that sells model airplanes

–Want an online store front to supplement there in store sales

Brainstorming Session – Scoping  it out

• Define the solutions boundaries
• Identify who will be impacted by the solution
• Discover what valuable activities will be automated
• Uncover Constraints that will limit the solution
• Kick Start Requirements Gathering Process

Demo – Brainstorming

• Create Empty Solution
• Create Modeling Project
• Add Use Case Diagram
• Add Subsystem
• Change Color
• Add Vision Statement
• Add Actors
• Add Functional Requirements
• Add Constraints
• Iterate

Tips

• Limit workshops to 1 hour each
• Always start with a vision of the solution
• Clearly identify who lives inside and outside the system
• Describe goals from user’s point of view (business value)
• Generate lots of ideas and capture everything

Organizing Features into Use Case Models

Use Case Diagrams

• Discuss  and Communicate

–The scenarios in which your system or application interacts with people, organizations, or external systems.

–The goals that it helps those actors achieve.

_The scope of your system

• No Detail, only summarizes some of the relationships between use cases, actors, and systems
• Helpful in discovering scope -> which functional requirements are part of our system
• Lists only functional requirements, all others must be recorded separately

Guidelines

• Breakup user goals and tasks into separate digestible diagrams
• Use those diagrams as a structural guide for writing requirements as Use Case documents

A Few Words About Actors

• Actors are always external participants
• Actors Interact Directly with the system
• Actors represent roles
• Use Cases are always initiated by an Actor

Actions

• Create use cases
• Add actors
• Add subsystems
• Add Use cases
• Define association
• Add Actor Generalization
• Link to Artifacts
• Structure your use cases
• Define subsystems

Tips

• Think of actors as roles and not job titles
• Use business domain terminology
• Focus on actors goals not implementation details
• Always use strong active verbs in the names
• Focus on only one Feature area in a single diagram
• Stack cases in diagram to show relative order
• Use color and notes to document important details
• Avoid decomposing the use cases into too much detail. Use cases are about the users’ experience of your system, instead of its internal workings

Model Business Domains Using Conceptual Class Diagram

Conceptual Class Diagram
aka domain model or analysis class model

• Explore domain concepts and assign responsibilities
• Develop a consistent vocabulary of business concepts and terms
• –Used throughout the requirements modelUsed when communication between application and users
• Describe the types of information used within the system and exchanged with other systems
• Independent of requirements gathering method

Analysis Steps

• Identify the key terms used as data or data type elements
• Use the classes as nouns when writing requirements
• Use enumerations to define literal values or states used in business processes
• Iterate and refine this model as new requirements are captured

Tips – Domain Modeling

• Use friendly names (spaces, no abbrevations)
• Show just those classes needed in description of the requirements
• Focus on names and simple relationships (associations)Don’t worry about aggregation or composition – that comes later in detailed design
• Capture multiplicity to clarify the relationships
• •Add attributes and types only if they are needed to clarify the requirements –Stick with standard primitives for attribute types: boolean, int, stringAdd doman specific types if they add clarity (Temprature:Celcius, Duration:weeks)
• Stay implementation independent –Don’t assign visibilities – that comes later in detailed design –Avoid Modeling Keys or id’s – they are an implementation  detailsAvoid modeling verbs/actions/operations/functions

Activity Diagrams

• Next Generation Flow Charts
• Used to show processes –Business Processes –Work flows-Algorithms
• Compliment to Use Cases-Show task flow instead of structure

Actions

• Create Activity Diagram
• Add Activities
• Describing Control Flow –Describe decisions and Loops –Starting the activity –Ending the activity –Interrupting activity
• Describing Data Flow –With Object Nodes –With input and output pins
• Define action in more detail –Call Behavior Action –Call Operation Action
• Concurrent Flows

Tips

• Use them to capture and validate business processes
• Think in terms of the users actions
• Focus on actions that are visible from outside the system
• Use to show flow of actions that span multiple use cases
• Best diagram to show parallel operations
• Focus on only one activity in each diagram

Sketching out an Application using a Layer Diagram

Purpose of Layer Diagram

• Used to describe structure of an application at a High Level
• Identify the major components or functional units of the design and their interdependencies
• Each Layer represents a logical group of namespaces, projects or other artifacts
• You can make sure that code adheres to your layers by using layer diagram as a part of build process

Design a Projects Physical Structure using component diagram

Component Diagram

• Visualize the physical structure of a system
• Focus on the components of a system, their relationships, interfaces and ports
• Highlight the service behavior that they provide and consume through interfaces

Design Steps

• Create a Component Diagram to show the major parts of your system
• Draw Dependencies between the components or their interfaces to show the structure of the system
• Use interfaces on the components to show the services that each component provides or requires
• In large design, you can draw separate diagrams to decompose components into smaller parts

Sketch Interactions with Sequence Diagrams

Sequence Diagram

• Capture Dynamic Behavior –The lifecycles of objects and how they collaborate together to deliver the required system functionalitySequential Flow of time
• Show Interactions between nouns in your system –Actors –Classes –ComponentsSubsystems
• Interactions consists of messages between typical instances during run time

Revealing Responsibilities with Class Diagrams

Class Diagrams

• Shows Logical and structural aspects of the system –Data Types used to store and exchange dataRelationships between those types
• Implementation Independent –Can Represent many things •Language specific software objects •XML NodesDatabase Tables

Three Things About LINQ…

1. Data == Objects
2. Imperative -> Declarative
3. Works against objects, relational and XML

LINQ to Relational Data

LINQ to SQL

ASP.NET 2.0′s new features can be grouped into three categories: new controls (more than 50 in all), new features in the page framework, and new services. In addition, myriad enhancements have been made to existing controls and services.

What’s New for UIS:-

Master pages

•   Visual inheritance” for Web pages
•   Applied declaratively or programmatically

  Themes and skins

•   Theme controls, pages, and entire sites
•   Applied declaratively or programmatically

New controls (more than 50 in all)

•   Menus, TreeViews, Wizards, and more

  ASP.NET 2.0 introduces a number of new features designed to help developers build cutting-edge UIs with a minimum of effort. First there’s master pages, which enable pages to be templatized and which enjoy great design-time support in the Visual Studio 2005 IDE. Next, there’s themes and skins, which allow controls, pages, and even entire sites to be visually themed with the stroke of a mouse. Finally, ASP.NET 2.0 introduces about 50 new control types ranging from the simple (e.g., BulletedList and ImageMap) to the sublime (e.g., GridView, DetailsView, Menu, TreeView, and Wizard).

What’s New in Data Access

Data source controls

•   Declarative 2-way data binding

  Data controls

•   GridView – Like the DataGrid, only better
•   DetailsView – Companion to GridView

  SQL cache dependencies

•   Key cached items to database entities

  Simplified data binding expressions

  ASP.NET 2.0 makes building data-driven sites easier than ever before by introducing declarative data binding utilizing data source controls (which dramatically reduce the amount of code you have to write), providing new (and very rich) data controls such as GridView and DetailsView, introducing SQL cache dependencies (which allow cached items to be keyed to database entities), and offering an expanded and simplified syntax for data-binding expressions.

TEMPLATES

Data Controls allow template editing

•   Item
•   Edit
•   Insert
•   Header
•   Footer

  Can nest controls within each type

  Two-way to parent

What’s New In Security

  Membership service

•   Service for managing users and credentials
•   Provider-based for flexible data storage

  Login controls

•   Controls for logging in, creating new users, recovering lost passwords, and more

  Role Management service

•   Combine forms authentication and role-based authorization without writing code!

  ASP.NET 1.x simplified forms authentication by introducing declarative means for designating login pages and specifying authorization rules. ASP.NET 2.0 further simplifies forms authentication by providing the following features and services:

•   A membership service for managing users and credentials
•   Login controls for logging in users, creating new users, and more
•  A role management service for enacting role-based security

The result is that forms authentication is easier than ever before and can often be accomplished without writing any code.

Membership & Logins

•   Login APIs
•  Allows use of advanced features
•   Customize logins and registrations
•   Perform management activities on users

  A first look at ASP.NET 2.0′s Membership service and login controls.

1. Step 1: Open the LoginControls project in Visual Studio 2005
2. Step 2: Run MembershipInfo.aspx. Inform the audience that “View MembershipUser Info” link at the bottom of the page points to a page that requires authenticated access, so clicking it will send you to a login page. Click the link
3. Step 3: Fill in the new user form to create a new user and click the Register button to get to MembershipUserInfo.aspx
4. Step 4: Click the Logout button. MembershipInfo.aspx appears
5. Step 5: Click the “View MembershipUser Info” link again. Log in using the account you created earlier. Once more, MembershipUserInfo.aspx appears
6. Step 6: Click the “Return to Main Page” link. MembershipInfo.aspx appears
7. Step 7: Inform the audience that they just saw three login controls demonstrated: Login, CreateUserWizard, and LoginStatus. Also tell them that registering a new user, logging in as that user, and implementing the login/logout link required exactly 0 lines of code, and that this is just a taste of what’s to come when we explore membership, login controls, and role management

Using the Login API:-  It features a page containing two SqlDataSources, a DataGrid, and a DropDownList. The SqlDataSource that serves the DataGrid uses the value selected in the DropDownList to perform a parameterized query.

1.   Step 1: Open the WhatsNew project in Visual Studio 2005
2.   Step 2: Run SqlDataSource.aspx
3.  Step 3: Demonstrate that selecting a country from the drop-down list changes the contents of the DataGrid. State that coupling the drop-down list to the DataGrid in this manner requires exactly zero lines of code
4. Step 4: Open SqlDataSource.aspx in the designer and switch to Design View. Point out that this page contains two SqlDataSources, and that one serves the drop-down list while the other serves the DataGrid
5. Step 5: Switch to Source view and show the audience SqlDataSource1. Point out that it provides content to the drop-down list, and that its SelectCommand uses a SELECT DISTINCT query to retrieve a list of countries from Northwind’s Customers table
6. Step 6: Show the audience SqlDataSource2. Point out that it provides content to the DataGrid, and that it uses a parameterized query. Show the “WHERE [Country]=@Country” clause in the SelectCommand, and show the <SelectParameters> element and the <asp:ControlParameter> tag instructing the SqlDataSource to obtain a value for @Country from the drop-down list
7. Step 7: Show the ConnectionString attributes in the <asp:SqlDataSource> tags. Call attention to the <%$ … %> expressions that declaratively initialize ConnectionString with a connection string. Inform the audience that the connection string is stored in Web.config

ROLES:-

•   Allows segregation of users into groups or “roles”
•   Can allow or deny access based on these
•   Use the Roles API to perform management features

PROFILES:-

  Store per-user data persistently

•   Strongly typed access (unlike session state)
•   On-demand lookup (unlike session state)
•   Long-lived (unlike session state)
•   Supports authenticated and anonymous users

  Accessed through dynamically compiled HttpProfileBase derivatives (HttpProfile)

  Provider-based for flexible data storage

  The new profile service makes short work of storing personalization settings and other per-user settings persistently. Classic applications for it include storing “favorites” (like the “My eBay” portion of eBay, which, among other things, lists auction items that you’ve bookmarked so you can scrutinize them later on) and user preferences. The service is profile-based. You define a profile in Web.config, and ASP.NET dynamically compiles that profile, provides strongly typed access to it, and persists profile data. Moreover, profiles work with both anonymous and authenticated users.

Site Navigation:-

•   Navigation UIs are tedious to implement(  Especially if they rely on client-side script)
•   New controls simplify site navigation
•   TreeView and Menu – Navigation UI
•   SiteMapDataSource – XML site maps
•   SiteMapPath – “Bread crumb” control
•   Public API provides foundation for controls
•   Provider-based for flexibility

  Easy site navigation is an important element of modern Web applications. Because much of the time spent developing a site is devoted to building menus, tree views, and other navigational aids, and because changes to a site’s structure require commensurate changes to the navigation UI, ASP.NET 2.0 addresses the issue of site navigation head-on. Menu and TreeView controls simplify the task of building navigation UIs; SiteMapDataSource controls enable changes to a site’s structure to automatically propagate to the navigation UI; and SiteMapPath controls make short work of implementing “bread-crumb” elements showing the path to the current page.

CONFIGURATION:-

    Administrative tools

•   ASP.NET MMC snap-in
•   Web Site Administration Tool (Webadmin.axd)

  Configuration API

•   Read/write access to configuration settings
•   Simplified custom configuration sections

  Instrumentation

•   Perf counters, health monitoring, and more

  In ASP.NET 1.x, editing configuration settings meant manually modifying XML configuration files. In 2.0, two new tools–the ASP.NET MMC snap-in and the Web Site Administration Tool–enable most configuration settings to be applied through administrative GUIs. Both tools represent significant enhancements in usability and should prove especially valuable to admins responsible for managing remotely hosted ASP.NET Web sites.

  ASP.NET 2.0’s configuration API fills a hole in ASP.NET 1.x by providing an easy-to-use and extensible API for reading and writing configuration settings. Applications can now read their own configuration settings without parsing raw XML, and they see a merged view of those settings that includes settings inherited from configuration files higher in the directory hierarchy. Moreover, writing configuration settings is as easy as reading them, and implementing custom configuration sections requires little more than deriving from System.Configuration.ConfigurationSection.

  ASP.NET 2.0 is also far more heavily instrumented than 1.x. Thanks to the new health monitoring subsystem, a few simple statements in Web.config can configure an application to write an entry to the Windows event log when a login fails, e-mail a system administrator when an unhandled exception occurs, and more. In addition, you can extend the health monitoring subsystem by defining Web events of your own. Other enhancements in this arena include new performance counters supplementing the ones in ASP.NET 2.0, integration with ETW for high-performance end-to-end tracing of requests as they travel through the system, and new options for generating, capturing, and managing trace output.

 What’s new in Localization:-

Auto-culture handling

•   Declarative mapping of Accept-Language headers to relevant thread properties

Simplified resource handling

•   Declarative mapping of control properties to resources using <%$ … %> expressions
•   Strongly typed programmatic resource loading

  <asp:localize runat=”server”> and more

  The big news in localization is that most of it can be done declaratively, whereas in ASP.NET 1.x, localization required explicit code to map Accept-Language headers to Thread properties, initialize control properties from resources, and so on. ASP.NET 2.0′s ability to autocompile RESX files also plays a significant role in simplifying localization.

  “Auto-culture handling” refers to the new Culture=”auto” and UICulture=”auto” attributes that can be applied to a page or an entire application to automatically map Accept-Language headers to the current thread’s CurrentCulture and CurrentUICulture properties. “Simplified resource handling” refers to the fact that localization resources are now easier to load (no more ResourceManager!), and that RESX files can be autocompiled simply by placing them in the application’s Resources directory. The <asp:localize runat=”server”> element allows blocks of text to be localized using string resources.

 PROVIDERS:-

  New model for storing and managing state

•  
  • Makes storage adaptable to different media

Used by many key ASP.NET services

•  
  •   Membership service
  •   Role Management service and more

  Built-in providers make ASP.NET state storage very flexible

  Custom providers make it infinitely flexible

  Most ASP.NET 2.0 state management services use a new model called the “provider model” to make state storage infinitely flexible. In the provider model, a service doesn’t manage state by interacting directly with a data store; instead, it uses a provider. The model is highly extensible because if the providers shipped with the system aren’t sufficient for your needs—if, for example, you want to store membership data or session state in an Oracle database rather than SQL Server—then you can plug in custom providers that target Oracle data stores. Developers can write custom providers themselves or acquire them from third parties

   This is one specific example of the provider model–the one used by the Membership service. The application talks to the Membership service through classes such as Membership and MembershipUser. These classes, in turn, read and write membership data by calling a provider. (Each class has a property named Provider that identifies the associated provider.) Each provider interfaces with a particular type of data store. If none of the providers supplied with the Framework supports the data store you wish to use (for example, an Oracle database), you can write a provider of your own or acquire one from a third party. The Membership service is one of several services that are provider-based.

CONFIGURATION:-

Administrative tools

• ASP.NET MMC snap-in
• Web Site Administration Tool (Webadmin.axd)

  Configuration API

•   Read/write access to configuration settings
•   Simplified custom configuration sections

  Instrumentation

• Perf counters, health monitoring, and more

  In ASP.NET 1.x, editing configuration settings meant manually modifying XML configuration files. In 2.0, two new tools–the ASP.NET MMC snap-in and the Web Site Administration Tool–enable most configuration settings to be applied through administrative GUIs. Both tools represent significant enhancements in usability and should prove especially valuable to admins responsible for managing remotely hosted ASP.NET Web sites.

  ASP.NET 2.0’s configuration API fills a hole in ASP.NET 1.x by providing an easy-to-use and extensible API for reading and writing configuration settings. Applications can now read their own configuration settings without parsing raw XML, and they see a merged view of those settings that includes settings inherited from configuration files higher in the directory hierarchy. Moreover, writing configuration settings is as easy as reading them, and implementing custom configuration sections requires little more than deriving from System.Configuration.ConfigurationSection.

  ASP.NET 2.0 is also far more heavily instrumented than 1.x. Thanks to the new health monitoring subsystem, a few simple statements in Web.config can configure an application to write an entry to the Windows event log when a login fails, e-mail a system administrator when an unhandled exception occurs, and more. In addition, you can extend the health monitoring subsystem by defining Web events of your own. Other enhancements in this arena include new performance counters supplementing the ones in ASP.NET 2.0, integration with ETW for high-performance end-to-end tracing of requests as they travel through the system, and new options for generating, capturing, and managing trace output.

WEB PARTS:-

  Framework for building portal-style apps

•   Patterned after SharePoint Portal Server
•   System.Web.UI.WebControls.WebParts

  Rich UIs with minimal code

• Edit page layout using drag-and-drop
• Edit appearance and behavior and more

  Seamless personalization

Intercommunication (“connections”)

 Web Parts is a framework built into ASP.NET 2.0 for building highly customizable portal-style pages. End users can customize Web Parts pages by changing the page layout, adding and removing Web Parts, editing Web Parts properties, establishing connections between Web Parts, and more. Changes made to a Web Parts page are persisted by the Web Parts framework. Web Parts pages exhibit a degree of sophistication seldom seen in Web applications today, and they do it without requiring you to write reams of code. In fact, as with many of the other new features in ASP.NET 2.0, the vast majority of what you can accomplish with the Web Parts can be accomplished declaratively.

 What’s New in Compilation:-

Autocompile anything

•  
  •   CS files, VB files, RESX files, and so on
  •   Simply drop files into special directories
  •   Extensible with custom build providers

  New code-behind model (code-behind 2.0)

•  
  •   Fixes fragilities in version 1
  •   Relies on partial class support in compilers

  Precompile and deploy without source

 ASP.NET 1.x was capable of autocompiling pages (ASPX files), but CS files, VB files, RESX files, and other file types had to be compiled manually. ASP.NET 2.0 extends the autocompilation model to include a variety of file types. Rather than compile a ShoppingCart class and place the resultant assembly in the bin directory, for example, you can simply copy the CS file containing the ShoppingCart class into the Code directory and let ASP.NET compile it for you.

 ASP.NET 2.0 also permits Web sites to be precompiled to avoid compilation delays the first time a page is accessed. Along with precompilation comes a new feature that allows sites to be precompiled AND deployed without source code. Deploying without source code is useful when you allow a third party to host your site but want to keep the source code in-house.

• Comes from System.Data
•   Hierarchical set of namespaces for handing different database schemas:

1.   SQL
2.   Oracle
3.   OleDB
4.   ODBC
5.   MySQL, DB2, PostgreSQL, etc. also available

•   Uses ADO.NET instead of ADO

  Data Structures

•   DataSet
• DataReader
• DataAdapter
• xxxConnection
• xxxCommand
• xxxParameter
• DataTable
• DataRow
• XSD

  DataSet

•   Representation of database in memory
•   Disconnected by default
•   Contains:   Datatables :   DataRows ,  DataRelations
•   Uses XML for serialization

  Data Reader

•   Read-only
• Forward-only
• Results stored in network buffer
• Retrieved using the “.Read” method
• Created using the “.ExecuteReader” method of a command object
• Must “Close” the reader once done

  DataAdapter

•   Object that is a set of

1. Select and/or …
2. Insert and/or …
3. Update and/or …
4. Delete commands
5. Connection Object

•   Fills a dataset and maintains two way relation with the database

  DataTable, DataRow

•   Equivalent memory structures to table and row of database
•   Can be created for a particular data structure
•   .NET automatically creates strongly typed datarow/table elements which can be directly used in code

•   ASPX instead of ASP
•   Object Oriented
•   Object Model
•   Type Safe – no variant
•   Multiple Languages
•   Compiled
•   Code Behind

  Parts of an ASP.NET Page

•   Web Form
•   Code Behind
•   HTML Server Controls
•   Web Server Controls
•   Validation Controls
•   User Controls

  Web Forms

•  <form runat=“server”>
• Only one per page
•  Posts back to the same page (itself)

  Code Behind

•   Contains back end code
•   Separates page logic from page layout
•  Generates code automatically for design time actions
•  Creates handlers for events as required

  HTML Server Controls

•  Look and feel like normal HTML elements
•   Equivalents for all standard elements available
•  Adds runat=“server” to the control
•  Allows server side interaction with controls  (  Not possible with HTML elements)

  Web Server Controls

•   Recommended way to use and create controls
•  Lots of controls available out of the box
•   Includes DataGrid, DataList, Repeater and more
•   Contain full Object Model:

1. Properties
2.   Events
3.   Methods

• Automatic browser detection and rendering

  Validation Controls

•   Controls that allow input validation
•   Work at:   Client side (JavaScript),   Server Side
•   Currently present are:

1. RequiredFieldValidator
2.  CompareValidator
3.   RangeValidator
4.   RegularExpressionValidator
5.   CustomValidator
6.   ValidationSummary

  User Controls

1. User created controls
2.  Can be re-used in other Web pages
3.   Requires no extra knowledge
4.   Use file extension of ASCX

•   Leverage the Web application model and the power of the ASP.NET HTTP Runtime
•   Exact type fidelity between .NET computers is not a concern and only some types of arguments can be passed

Using .NET Remoting, you can:

•   Publish or consume services in any type of application domain (ex. console, Windows, IIS, Web Service, etc.)
•   Preserve full managed-code type-system fidelity in binary formatted communications.
•   Pass objects by reference and return to a particular object in a particular application domain
• Control activation characteristics and object lifetimes directly.
•   Implement and use third-party channels or protocols to extend communication to meet your specific needs
•  Participate directly in the communication process to create the functionality you need
•   Potential performance benefits by being able to select the most optimal form of communication.

  Both ASP.NET and .NET Remoting are interprocess communication implementations. ASP.NET provides an Internet Information Services (IIS)-hosted infrastructure that handles basic types well and is familiar to Web application developers. .NET Remoting is a generic and extremely extensible interprocess communication system that you can use to create XML Web services hosted in IIS (and have all the security, scalability, and session and application state of ASP.NET and IIS), or any other type of communication

  The type of communication you need and the programming model you are familiar with are the two main criteria that should drive your choice between the two programming models.

  Using Web Services

  •Use the Web application model and the power of the ASP.NET HTTP runtime

  •Exact type fidelity between .NET computers is not a concern and only some types of arguments can be passed

  Using .NET Remoting, you can:

  •Publish or consume services in any type of application domain, whether that domain is a console application, a Windows Form, Internet Information Services (IIS), an XML Web service, or a Windows Service.

  •Preserve full managed-code type-system fidelity in binary formatted communications.  Note: XML Web services use SOAP formatting, which does not preserve all type details

  •Pass objects by reference and return to a particular object in a particular application domain

  •Control activation characteristics and object lifetimes directly.

  •Implement and use third-party channels or protocols to extend communication to meet your specific needs

•Participate directly in the communication process to create the functionality you need

•Potential performance benefits by being able to select the most optimal form of communication.

Authorization

•   Custom code
•   Configuration settings in Web.config

  Encryption

•   SSL ( Watch out for performance hit )
•   IPSec

  WS-Security

•   Integrated security for Web Services
•   Global XML Web Services Architecture (GXA)

In Details:-

  Restricting access to an XML Web service

  XML Web services can be implemented so that only authorized clients receive access, but to restrict access, you need a way to authenticate clients. Then, based on the credentials presented by the client, you can decide whether to authorize access to the service.

  Securing an XML Web service is slightly different than securing a Web site in that you authorize computers or businesses to access the XML Web service instead of end users.

  If you know which computers need access to your XML Web service, you can use Internet Protocol Security (IPSec) or firewalls to restrict access to computers of known IP addresses. This technique is particularly useful when you want to restrict access to computers within a private network.

  In most Internet scenarios, however, the IP addresses of all your clients will be unknown. In this case, the most straight-forward approach to implementing authentication is to leverage the authentication features of the protocol used to exchange messages. For example, if you are sending and receiving SOAP messages over HTTP, you will want to leverage the authentication features available for HTTP. Microsoft® Internet Information Services 5.0 supports several authentication mechanisms for HTTP (see www.microsoft.com/technet/iis/authmeth.asp for more details).

  Basic – Use for non-secure or semi-secure identification of clients because the username and password are sent in plain text. Internet Information Services will authorize access to the XML Web service if the credentials match a valid user account.

  Basic over SSL – Same as Basic authentication except that the username and password are sent across the network with Secure Sockets Layer (SSL) encryption rather than in plain text. Basic over SSL is a good option for Internet scenarios, although using SSL has a significant impact on performance.

  Digest – Uses hashing to transmit client credentials in a secure way, though it is not widely supported on platforms other than Microsoft Windows®. Internet Information Services will authorize access to the XML Web service if the credentials match a valid user account.

  Integrated Windows authentication – Useful only for Intranet scenarios since it uses NTLM or Kerberos and cannot be used across proxy servers or other firewalls. Internet Information Services will authorize access to the XML Web service if the credentials match a valid user account.

  WS-Security WS-Security describes enhancements to SOAP messaging to provide quality of protection through message integrity, message confidentiality, and single message authentication. These mechanisms can be used to accommodate a wide variety of security models and encryption technologies. XML Web Services no longer have to rely on the security features of the underlying transport mechanisms.

  GXA is a framework from Microsoft for specifying generic higher-level services which augment XML Web Services. GXA provides an implementation of WS-Security which includes support for X.509 certificates and Kerberos tickets.

  WS-Security Index Page http://msdn.microsoft.com/webservices/understanding/gxa/default.asp?pull=/library/en-us/dnglobspec/html/wssecurspecindex.asp

  Using WS-Security with the Web Services Development Kit Technology Preview http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwssecur/html/wssecwithwsdk.asp

1.   Arguments and return data
2.   Whether to use existing classes or create new ones
3.   Security

•   Use output caching to improve performance
•   Define your input and output data structures using XSD schemas
•  Separate XML Web service from underlying business logic

  Web Service Façade 
  (Architectural Patterns)

• Re-architect an existing client/server or fat client architecture into a 3 tiered application environment
•  Web enable an existing client/server or fat client architecture
•   Provide integration with external business partners.
•   Provide integration with internal business systems.
•   Insulate existing user applications from changes in APIs, servers, or vendors of data and services.
• Integrating a “silo” application — unlock an existing application so it can participate in a larger business process.
•  Aggregate back-end systems so they’re exposed as one business process.
•   Integrating application running on in heterogeneous environments (Linux, Solaris, AS400, etc) with applications running on Windows.
•   Insulate existing user applications from changes in APIs, servers, or vendors of data and services.
•  Integrating a “silo” application — unlock an existing application so it can participate in a larger business process.
•  Aggregate back-end systems so they’re exposed as one business process.
•   Integrating application running on in heterogeneous environments (Linux, Solaris, AS400, etc) with applications running on Windows.

•  What is an XML Web service?
• What does an XML Web service do?
• XML Web Services in .NET lWSDL, DISCO and UDDI
• Developing XML Web Services
• Securing XML Web services
• Web Service Exception
• Web Service and .NET Remoting
• Web Service and BizTalk

  What is an XML Web Service?

A programmable application component accessible via standard Web protocols that provides a universal language for applications to talk to each other - XML Web services allow applications to communicate regardless of operating system or programming language via the Internet. They can be implemented on any platform and are defined through public standards organizations such as the W3C. And with XML Web services, not only can applications share data, but they can also invoke capabilities from other applications without regard to how other applications were built. Sharing data through XML allows them to be independent of each other while simultaneously giving them the ability to loosely link themselves into a collaborating group that performs a particular task.

 What is the difference between a Web site and an XML Web Service - Web sites are about presenting information to a user: they are the communication vehicle for servers to talk to users. XML Web services, on the other hand, offer a direct means for applications to interact with other applications. Applications hosted internally, as well as on remote systems, can communicate via the Internet by using XML and SOAP messages. XML Web services are built on standard Web protocols; HTTP and XML. The technology innovations for XML Web services are: DISCO (Discovery) and UDDI (Universal Description, discovery, and Integration) – Standards for locating XML Web services SOAP (Simple Object Access Protocol) – Explicit serialization (HTTP + XML description) protocol used in service exchanges WSDL (XML Web services Description Language) – XML document describing the location and interfaces a particular service supports – the client’s contract.

  What Does an XML Web Service Do?

•   Expose functionality as a service and allow applications to share data
•   Can be called across platforms and operating systems and regardless of programming language

  XML Web Services in .NET

  The .NET Framework provides a bi-directional mapping between the elements of the Web and the elements of the Framework.  XML Web Services actually map well to existing technologies and to the .NET Framework. This slide shows how the mappings can be visualized. For instance, you can see that the concept of application data maps to XML which carries the data while the objects in the framework provides the features we normally see in objects that are called locally or in client/server applications. The objects are instantiations of classes which provide methods that can be called by an application. So, from the perspective of the calling application, an XML Web service looks like a method (or function) call to a traditional object. The middle column titled Web shows the areas that define the services features across the Web. For instance, the XML Schema Definition (XSD) language represents an XML schema that describes a service just like a class provides the description for an object.

  Web Service Description Language (WSDL) and SOAP

•   “TypeLib for SOAP”
• Uniform representation for services : Transport Protocol neutral ,Access Protocol neutral (not only SOAP)
• Describes how to call an XML Web service

  DISCO

•  DISCO is a proprietary file format placed at the root of a Web directory
• Visual Studio generates the DISCO for your XML Web service when you generate your service
• Easy discovery model for HTTP

  Universal Description, Discovery and Integration (UDDI)

•   Registry (Directory) for Web Services
•   UDDI itself is a Web service – can be programmatically accessed
•   Businesses can publish to registry and query registry
•   May point to WSDL files
•   Initiative driven by Microsoft, IBM, Compaq, Intel, Sun, Oracle and 250+ other companies

  Visual Studio .NET and XML Web Services

•   Visual Studio .NET creates XML Web Services for you
•   Generates the plumbing i.e., SOAP, DISCO, WSDL, etc…
•   Automates the creation of the project files

  Creating an XML Web Service

  <%@ WebService Language = “C#“ Class = “MyClass“ %>

using System.Web.Services;
public class MyClass: WebServices
{
  [ WebMethod ]
  public int Compute1(int i1, int i2)
  {
    return i1 + i2;
  }

 [ WebMethod ]  public int Compute2(int i1, int i2)
  {
    if (i1 > i2) return i1 – i2;
    else return i2 – i1;
  }
} Note:  Use either [SoapDocumentService] or [SoapRpcService] attribute to control basic WSDL details  Web Services Description Language (WSDL) defines two styles for how an XML Web service method, which it calls an operation, can be formatted in a SOAP request or a SOAP response: RPC and Document.   The Rpc/encoded is deprecated, only use it when required for interop.  The [SoapDocumentService] is the default if not specified.

  Creating An XML Web Service
Demo

•   XML Web Services 101
•  Create a simple XML Web service

  XML Web Services Clients Create ASP.NET page to use XML Web Service Demonstrate: How to register Web services? •How to use a Web service? •How calling a Web service is like calling a function or method?

Generating Web Service proxy using “wsdl.exe”

•  Utility to generate code for xml web service clients and xml web services using ASP.NET from WSDL contract files, XSD schemas and .discomap discovery documents. 
• Allow greater control in generating the proxy class.

1. Specify the language (C#, VB.NET, or JS)
2. Specify the namespace for greater interoperability
3. Specify the web service url from a configuration file
4. Specify the protocol
5. Specify the proxy server if needed

(technical guide notes:-)

  wsdl.exe <options> <url or path> <url or path> …      – OPTIONS – <url or path> –     A url or path to a WSDL contract, an XSD schema or .discomap document. /nologo     Suppresses the banner. /language:<language>     The language to use for the generated proxy class.  Choose from ‘CS’,     ‘VB’, ‘JS’ or provide a fully-qualified name for a class implementing     System.CodeDom.Compiler.CodeDomProvider.  The default is ‘CS’ (CSharp).     Short form is ‘/l:’. /server     Generate an abstract class for an xml web service implementation using     ASP.NET based on the contracts. The default is to generate client proxy     classes. /namespace:<namespace>     The namespace for the generated proxy or template.  The default namespace     is the global namespace. Short form is ‘/n:’. /out:<fileName>     The filename for the generated proxy code. The default name is derived from     the service name. Short form is ‘/o:’. /protocol:<protocol>     Override the default protocol to implement.  Choose from ‘SOAP’, ‘HttpGet’,     ‘HttpPost’, or custom protocol as specifiied in the configuration file. /username:<username> /password:<password> /domain:<domain>     The credentials to use when the connecting to a server that     requires authentication. Short forms are ‘/u:’, ‘/p:’ and ‘/d:’. /proxy:<url>     The url of the proxy server to use for http requests.     The default is to use the system proxy setting. /proxyusername:<username> /proxypassword:<password> /proxydomain:<domain>     The credentials to use when the connecting to a proxy server that     requires authentication. Short forms are ‘/pu:’, ‘/pp:’ and ‘/pd:’. /appsettingurlkey:<key>     The configuration key to use in the code generation to read the default     value for the Url property. The default is to not read from the config     file. Short form is ‘/urlkey:’. /appsettingbaseurl:<baseurl>     The base url to use when calculating the url fragment. The     appsettingurlkey option must also be specified. The url fragment is     the result of calculating the relative url from the appsettingbaseurl     to the url in the WSDL document. Short form is ‘/baseurl:’.

  Returning Data from an XML Web Service

  DataSets can be returned from XML Web service and work well in most cases.  In addition, they can be easily generated with wizard.  DataSets are a feature of ADO.NET and therefore require the .NET Framework.

  If a consuming application can use a DataSet, it uses it as is. If the consuming application cannot use a DataSet, it receives XML from the DataSet.  You can also use XML methods of the DataSet to extract and return XML.

 Consuming Data from an XML Web Service

    Using ADO.NET DataSets

 Create an XML Web Service which returns and ADO.NET DataSet.

  Show how XML is returned to the browser, but DataSet returned to application that uses a DataSet

•   How to return data from a DataSet
•   How DataSets automatically serialize themselves
•   How to consume data from a Web service

  Additional notes: The BizTalk server can orchestrate and consume XML Web services.

  The SoapException can either be thrown by the common language runtime or by an XML Web service method. The common language runtime can throw a SoapException if a response to a request is not formatted correctly. XML Web service methods can generate a SoapException by simply throwing an exception within the XML Web service method. If the client accessed the method over SOAP, the exception is caught on the server and wrapped inside a new SoapException.

  The SoapException thrown has the following property values:

 Message: The Message property of the original exception.

 Code: Specifies a SOAP fault code representing an error occurred during the processing of a client call on the server, where the problem was not due to the message contents.

  Actor: The url of the XML Web service method.

  Detail: A null reference (Nothing in Visual Basic), but an empty detail element is present in the fault element.

  The code fragment demonstrates how to handle a CLR exception, wrap the exception in a SoapException, and rethrow the exception to the client

  Web Service Exception

  try {    // do something… } catch(Exception e) {   // clean up code…   throw new SoapException(…); }

  Designing an XML Web Service

  When you are designing an XML Web service, you must consider the following things: (Remember, stateless is good.)

• Group related operations and data into one method

  Network round trips are expensive. As with any distributed application, someone using XML Web services must consolidate method calls into chunkier operations that accept all needed data as parameters.

•   Use output caching to improve performance

  The output from an XML Web service method can be cached by the server and returned to clients without invoking the method. You can control the duration of the output in the cache by setting the CacheDuration property of the WebMethodAttribute on a per-method basis.

•   Define your input and output data structures using XSD schemas

  When you return a DataSet or an XML document, the client needs to know the structure of the data you are returning. Use XSD schemas to formally define this structure, but it is unnecessary to create them from scratch. A DataSet will generate the schema for you and XSD.exe can generate a schema given an XML document. You might want to tweak those generated schemas to cause them to more accurately and specifically describe the data you are returning and/or receiving.

•   Separate XML Web service from underlying business logic

  While you can implement the business logic in an XML Web service, it is not the best idea. Separating the business logic into components and then creating XML Web services that use those components is a better direction because it lets you design a business logic object model according to the application’s needs. Then this object model can be used from several facades including an XML Web service, ASP.NET pages or even a facade that is invoked by Visual Basic .NET clients using remoting.

• Design and test for interoperability

  Depending on your needs, some or all of your XML Web service clients may not be .NET clients. The .NET XML Web service builds on standards and is created for interoperability. To ensure your XML Web service can be invoked by the target client type, you must take into consideration the data structures exchanged between your service and the client. For example, when you return a DataSet, a non-.NET client will receive it as an XML document. The client then wants to make changes to it and send it back to your service to apply those changes. If your service is expecting a DataSet back, the client must update the XML document in a specific way (i.e. with before and after images of each changed row). It might be easier for the client in this case to deal with an XML document and make the updates directly. In any case, you must think through how non-.NET clients will interact with your XML Web service.

• Allow developers to use a consistent programming methodology
• Should be able to target multiple hardware platforms
• Should be able to work with Web uProvide an API to use across different OS versions

What is .NET?

• Is a framework consisting of: lLanguages lCompiler lClass Libraries lRuntime

Languages

1. Over 55 languages to choose from
2. Supports OOB:

• C++
• C#
• VB
• JS
• J#

Creates MSIL code

• So all languages are equal in functionality
• C++ can create unmanaged code

Compiler

• 2-Stage Compiler
• Stage 1: Compiles code to IL
• Stage 2:   Compiles Just-in-Time

Class Libraries

• Gives developer an extremely large set of hierarchical classes (namespaces) to work with
• Governs all aspects of system and application development
• Provides in built security mechanisms

Runtime

• Needs to be available on the target platform (Except in the case of Web applications )
• Runtime consists of the BCL and JIT
• Is loaded at the time of execution of a .NET application

Important Features

1. Performance :-   Much faster than equivalent Java application ,   At least as fast as native Windows application
2. Platform Independent:-   Device:   lDesktop, Laptop, Tablet, PDA, Phone, Web ,   lOS: Windows, BSD, Linux  ,   lBrowser: IE, Firefox, Mozilla, even Lynx!