Monday, September 13, 2010

Difference between abstract class and interfaces in .net

Many a times we encounter this question in our minds when deciding on what to choose between abstract class or interface while implementing projects. Further many not having clear idea of the pros and cons of both just choose either of them for implementation. In this post I am going to throw some light on the difference between abstract class and interface in .net and how to choose between the two.

Abstract Class

These are those classes which cannot be instantiated i.e. their objects cannot be made. We can declare a class abstract by using the keyword abstract before the class keyword.

abstract class ABC
{
.......
}

The important point here to note is that all OOPS concepts apply to the abstract class i.e. whatever we can do within a class can be done here too, like declaring a variable, creating a function, function overloading, function overriding, access modifiers (public, private, protected), inheritance, constructor, destructor, properties, events , indexers, etc. All these concepts can be implemented in a abstract class.

A abstract class can inherit from some other class also:

class A
{.....}

abstract class B : A
{.....}

This means that within a inheritance hierarchy the position of abstract class can be anywhere except the last class i.e. the last child class.

If inheritance is in this order A - >B - > C - > D - > E then all classes except class E can be abstract class.

Further a abstract class can implement interfaces also:

interface I
{......}

abstract class B : I
{.....}

An abstract class can implement combination of both class and interface also, but only one class and any number of interfaces


abstract class B : MyClass, I1, I2, I3, I4
{.....}

Another important point is that if we have declared a constructor in abstract class, it will be called whenever the child class object is made.

class A
{
    public A()
     {
           Console.WriteLine("hello");
      }
...}

abstract class B : A
{.....}

B ob1 = new B();

output will be: hello


Interfaces

Interfaces only provide with the declaration of methods, properties, events, indexers, or any combination of those four member types only. An interface cannot contain constants, fields, operators, instance constructors, destructors, or types. It cannot contain static members. Interfaces members are automatically public, and they cannot include any access modifiers. Also Interfaces contain no implementation of methods.

Interface MyInter
{
     void Check();
}

A interface can inherit only from any number of interfaces but not from classes. Further an interface cannot be instantiated directly.





Thursday, June 24, 2010

Windows Workflow Foundation (WF) - Benefits And Tutorials

Window WorkFlow foundation (WF) has changed the way we code and manage our applications. It has revolutionized the concept of coding in which one can see the processes and logics involved. In this post I am going to discuss about Window WorkFlow Foundation and its benefits.

Introduction

Everybody who writes code wants to build great software. If that software is a server application, part of being great is scaling well, handling large loads without consuming  too many resources.  A great  application should  also  be  as easy as possible  to  understand, both for its creators and for the people who maintain it.  Achieving both of these goals isn’t easy. Approaches that help applications scale tend to break them apart, dividing their logic into  separate  chunks  that can be hard to understand. Yet writing unified logic that lives in a single executable can make scaling the application all but impossible. What’s needed is a way to keep the application’s logic unified, making it more understandable, while still letting the application scale.

Achieving this is a primary goal of Windows Workflow Foundation (WF). By supporting logic  created using  workflows, WF provides a foundation for creating unified  and scalable applications.  Along with this,  WF can also simplify other development challenges, such as coordinating parallel work, tracking a program’s execution, and more.

WF was first released with the .NET Framework 3.0 in 2006, then updated in the .NET Framework 3.5.  These first two versions  were useful,  especially for independent software vendors (ISVs),  but  they haven’t become  mainstream  technologies  for enterprise developers. With the version of WF that’s part of the .NET Framework 4, its creators aim to change this. A major  goal of this latest release is to make WF a standard part of the programming toolkit for all .NET developers. Like any technology, applying WF requires understanding what it is, why it’s useful, and when it makes sense to use it. The goal of this overview is to make these things clear. You won’t learn how to write WF applications, but you will get a look at what WF offers, why it is the way it is, and how it can improve a developer’s life. In other words, you’ll begin to understand the workflow way.


A workflow based program is like traditional programs that allow you to coordinate work and perform operations but has some important differences:

  • Workflows use a declarative model (see Declarative programming) of writing programs by linking together pre-defined activities rather than an imperative programming model of writing each line of code
  • Workflows can handle long-running work by persisting themselves to a durable store, such as a database, when idle and loading again once there is work to be performed
  • Workflows can be modified dynamically while running when new conditions require a workflow to behave differently than when it was created
  • Workflows provide a distinct separation of business rules and host application code making it easier to modify the business rules
  • Workflows support sequential workflows for systems with sequential logic and state machine workflows for systems with event-based logic
  • Workflows usually have a visual counterpart that allows a flowchart-like description of their logic


Windows Workflow Foundation (WF) provides the declarative framework for building application and service logic and gives developers a higher level language for handling asynchronous, parallel tasks and other complex processing. WF is a set of tools for declaring your workflow (your business logic), activities to help define the logic and control flow, and a runtime for executing the resulting application definition.  In short, WF is about using a higher level language for writing applications, with the goal of making developers more productive, applications easier to manage, and change quicker to implement.  The WF runtime not only executes your workflows for you, it also provides services and features important when writing application logic such persistence of state, bookmarking and resumption of business logic, all of which lead to thread and process agility enabling scale up and scale out of business processes.



A Windows Communication Foundation (WCF) approach to workflow communication was added in .NET Framework 3.5. This functionality comes in the form of two activities, SendActivity and ReceiveActivity, which send and receive WCF messages respectively. Workflows which include a ReceiveActivity expose a selected interface method as a WCF service. This could allow external code to, for example, make a Web Services call to a running workflow instance. The WF Runtime provides infrastructure to ensure that if a WCF call is made to a workflow instance that is in a persisted state (i.e. waiting for some external event like a WCF call or a timer event), then the instance will be reloaded into memory so that the message can be delivered to the workflow instance. Workflows which include a SendActivity are able to call external services via WCF.



Tutorial Videos

A good video explaining the use of WF and its benefits is as follows:



A good video showing how to create a WF project is as follows:




Further Readings


For further reading refer to MSDN article.

Saturday, June 19, 2010

New Features in BizTalk Server 2010

New Features in BizTalk Server 2010
For more on this refer this msdn article and  What's New in BizTalk Server 2010 article on MSDN. The following points are picked up from these articles. Kindly refer them for more details.

With the release of BizTalk Server 2006, the fourth generation of the Microsoft business process integration server, customers gained the benefits of integration with Microsoft Visual Studio 2005 and 64-bit support. BizTalk Server 2006 also enhanced the existing administration functionality, introduced new capabilities for business activity monitoring (BAM), and enhanced the core messaging engine. BizTalk Serveris built on the core architecture of BizTalk Server 2006 and made strides in all dimensions of application-to-application, business-to-business, and business-process automation.
BizTalk Server 2010 further enhances the user experience and introduces features that enable BizTalk Server customers to better manage and represent their businesses in a BizTalk Server setup. This release of BizTalk Server also provides key usability enhancements for BizTalk Server administrators and developers. This topic describes the new and enhanced features available with BizTalk Server 2010 .

BizTalk Server Settings Dashboard

The BizTalk Settings Dashboard in BizTalk Server 2010 collates all the performance settings and provides a central console to manage them. For more information about how to use Settings Dashboard for performance optimization, see Managing BizTalk Server Performance Settings.

Improved Management Pack

System Center Operations Manager (SCOM) provides capabilities that can improve the manageability of Microsoft products through centralized and proactive availability and health monitoring. The BizTalk Server Management Pack for Operations Manager provides comprehensive discovery and monitoring of BizTalk Server components and applications. With BizTalk Server 2010 , the following enhancements are introduced in BizTalk Server management pack:
  • Separate views for enterprise IT administrators and BizTalk administrators. There are two different personas that need to monitor a BizTalk Server environment, the enterprise IT administrator and the BizTalk Server administrator.



    • An enterprise IT administrator is interested in monitoring the state and health of the various enterprise deployments the machines hosting the SQL Server databases, machines hosting the ENTSSO service, host instance machines, IIS, network services, etc. In general, an enterprise administrator is interested in the overall health of the “physical deployment” of a BizTalk Server setup.
    • A BizTalk administrator is interested in monitoring the state and health of various BizTalk Server artifacts and applications such as orchestrations, send ports, receive locations, etc. In general, a BizTalk administrator is interested in monitoring and tracking BizTalk Server health and if corrective measures are required to ensure that the applications are running as expected.
    The BizTalk Server 2010 management pack now provides two separate views to cater to both these personas.
  • Optimized discovery of artifacts across multiple machines. In a typical BizTalk Server setup, a BizTalk group contains multiple runtime machines. When such an environment is monitored using SCOM, monitoring agents running on the machines discover the same set of artifacts from the configuration database which results in duplicate artifacts getting displayed on the SCOM console. With BizTalk Server 2010 management pack, the monitoring agents discover the artifacts from a single machine.
  • Optimized discovery of relationships between artifacts. With BizTalk Server 2010 , the management pack optimizes the discovery of relationships between different BizTalk Server artifacts by properly sequencing the discovery of the artifacts before the discovery of relationships. For example, to establish the relationship between a receive port and a receive location, the management pack must first discover the receive port and receive location and then discover the relationship between them. In previous releases of the BizTalk Server pack, the ordering of discoveries was not proper.
  • Visual representation of health status. The SCOM implements color schemes to visually represent the health status of all BizTalk Server related artifacts. For example, the platform-level artifacts such as host instances can either be in a running or stopped state. This is represented with colors green and red respectively. Similarly, BizTalk application level artifacts can be categorized into three buckets: green, yellow, and red. If all instances of an orchestration are running and it is in a perfect running state, the health status is represented in green. If less than 70% of the orchestration instances are faulted, the health status is represented in yellow. If more than 70% of the orchestration instances are faulted or in case of critical errors, the health status is represented in red.

    The BizTalk Server 2010 management pack changes the parameters that are used for monitoring the health of a BizTalk Server deployment. While in the previous management packs only the configuration state (e.g. orchestration state) was considered for health monitoring, in BizTalk Server 2010 management pack the runtime state (e.g. the number of suspended instances) is also used to monitor the health status. For example, the visual representation of a send port may change to yellow or red not only if the send port is not properly configured but also if there are some suspended instances of the artifact.
  • Diagnostic support. In addition to exposing the artifacts with errors, the BizTalk Server 2010 management pack provides diagnostic support by including basic information about the error. For example, if a send port turns yellow from green, diagnostics is automatically run and the user can troubleshoot the reason for this change in the State Change Events tab of the Health Explorer.
  • Other performance enhancements. With the previous releases of management pack, when an artifact is monitored, even the smallest change to the artifact is written to the SCOM database. To avoid frequent calls to the database and to improve system performance, the BizTalk Server 2010 management pack highlights issue and changes to properties that require attention of an IT administrator and are less likely to be modified very frequently. The BizTalk Server 2010 management pack also fixes performance issues related to high resource utilization if the discovery intervals are set too low.
Where do I start? To start using the BizTalk Server 2010 management pack you must first install System Center Operations Manager and then download and install the management pack for BizTalk Server 2010 .

FTP Adapter Enhancements

The BizTalk FTP adapter exchanges data between BizTalk Server and an FTP server and enables integration of data stored on varied platforms with different line-of-business applications. With BizTalk Server 2010 , the FTP adapter is enhanced to provide the following feature additions:
  • Support for transferring data to and from a secure FTP server. The FTP adapter in BizTalk Server 2010 supports reading and writing data from a secure FTP server. The adapter provides support for file transfer from an FTP server over Secure Socket Layer (SSL)/Transport Level Security (TLS).
  • Support for downloading file from locations marked as read-only. In the FTP adapter available with the previous releases of BizTalk Server, the adapter deletes the file after downloading so that it does not download the file again in the next polling cycle. Due to this design, the adapter was limited to download files only from FTP locations that provide write access. With BizTalk Server 2010 , the FTP adapter is enhanced to support downloading of files from read-only locations as well.
  • Support for atomic file transfer in ASCII mode. The FTP adapter available with the previous releases of BizTalk Server provides atomic file transfer only for binary mode. With BizTalk Server 2010 , the FTP adapter is enhanced to support atomic file transfer for ASCII mode as well.
Where do I start? All the FTP adapter enhancements mentioned in this section are configured using adapter properties. So, to use these new features you must set the relevant binding properties while configuring the FTP adapter send port or receive location. For information on the FTP adapter features in BizTalk Server 2010 , see Enhancements to the FTP Adapter in BizTalk Server 2010. For instructions on how to configure the FTP adapter, see Configuring the FTP Adapter.

Enhanced Trading Partner Management

For more information about the enhancements to the Trading Partner Management feature in BizTalk Server 2010 , see Building Blocks of a Trading Partner Management Solution.

Enhanced support for HIPAA documents

For more information about the enhanced HIPAA support in BizTalk Server 2010 , see HIPAA Document Schema Version 5010.

Enhanced BizTalk Mapper

For more information about the enhancements to the BizTalk mapper feature in BizTalk Server 2010 , seeEnhancements to BizTalk Mapper.

Support for .NET Framework 4

For more information about how BizTalk Server 2010 supports .NET Framework 4 , see Updated .NET Framework Support.

Customer Experience Improvement Program in BizTalk Server

Microsoft introduces the Customer Experience Improvement Program in BizTalk Server 2010 . As part of this support in Beta, you are automatically opted-in to provide useful feedback to Microsoft regarding your usage of BizTalk Server. The data collected from you is anonymous and cannot be used to identify you. Microsoft collects feature usage statistics as part of this program.
By participating in this program, you can help improve the reliability and performance of various features of BizTalk Server. Post BizTalk Server 2010 Beta, you may also choose to opt out of this program. For more information about this program and its privacy policy, see Microsoft BizTalk Server CEIP Privacy Policy (http://go.microsoft.com/fwlink/?LinkId=188553).

Updated Platform Support

BizTalk Server 2010 includes support for the following software versions:
  • Windows Server 2008 R2
  • Windows Server 2008 SP2
  • Windows 7
  • Windows Vista SP2
  • SQL Server 2008 SP1
  • SQL Server 2008 R2
  • Visual Studio 2010
  • Microsoft Office 2007
  • Microsoft Office 2010
BizTalk Server 2010 also supports upgrade from BizTalk Server 2006 R2 and BizTalk Server 2009. For more information, see http ://go.microsoft.com/fwlink/?LinkId=128383









Updated .NET Framework Support
BizTalk Server 2010 supports building new applications only on .NET Framework version 4 . You can build both BizTalk applications as well as custom applications (such as custom functoids, custom pipeline components) using .NET Framework 4 . However, BizTalk Server 2010 continues to support the BizTalk Server 2006 R2 and BizTalk Server 2009 applications (BizTalk applications and custom applications) built on .NET Framework 3.5 SP2.
Ff629735.Important(en-us,BTS.70).gifImportant
BizTalk Server 2010 supports both .NET Framework 3.5 SP2 and .NET Framework 4 only for Beta.
With support for .NET Framework 4 and improved integration with Visual Studio 2010, developers can now take advantage of BizTalk artifact property pages being integrated into Project Designer tabs, as well as migration with the Visual Studio Project Update Wizard.

Migrates the Existing Projects to BizTalk Server 2010

If you launch an existing BizTalk project in BizTalk Server 2010 , it automatically gets migrated, changing the .NET Framework version to 4.0. You cannot modify the .NET version number later in the Propertiesdialog box of the BizTalk project.
When you attempt to open any of the existing BizTalk Server 2006 R2 or BizTalk Server 2009 projects in BizTalk Server 2010 , the following warning message is displayed. Click OK to proceed with migration.
Warning message for migration
Also, you can silently migrate the existing BizTalk Server 2006 R2 or BizTalk Server 2009 projects to BizTalk Server 2010 using the Visual Studio 2010 command prompt.
To migrate the existing projects silently:
  1. Open the Visual Studio command prompt
  2. Type the following command and press ENTER.










    Devenv  /upgrade
    
    The command launches the existing BizTalk project and migrates it to BizTalk Server 2010 .
In .NET Framework 4 , you can reuse the application DLLs which have been built for .NET Framework 3.5 SP2. You need not modify the DLLs and rebuild them for .NET Framework 4 . When you migrate BizTalk applications from BizTalk Server 2006 R2 or BizTalk Server 2009 to BizTalk Server 2010 , the application DLLs, such as schema DLLs and orchestration DLLs, automatically get upgraded for .NET Framework 4 at runtime.

Launches MMC from All Programs Only

In BizTalk Server 2010 , you can launch the BizTalk Server Administration Console only from Start > All Programs > BizTalk Server 2010 > BizTalk Server Administration.
In BizTalk Server 2006 R2 or BizTalk Server 2009, you could launch BizTalk Server Administration Console also from <drive>:\Program Files\BizTalk Server \btsmmc.msc. This is not available in BizTalk Server 2010 any more.

No Access to BAM Interceptors

In BizTalk Server 2010 , the Windows Workflow Foundation (WF) interceptor will not work with the new WF engine in .NET Framework 4 . The WF interceptor will continue to work in .NET Framework 3.5 SP2.
The Windows Communication Foundation (WCF) interceptor works with the new WF engine in .NET Framework 4 .
For conceptual information about BAM WF and WCF, see What Are the BAM WCF and WF Interceptors?


Deprecated Features, Tools, and APIs
The following features are deprecated in BizTalk Server 2010 . Deprecated features should not be used in new applications. For a list of changed features and tools, see Changed Features and Tools.

Features

FeatureComment
EDI PipelineSome EDI pipeline properties are fully supported with no feature enhancements in BizTalk Server 2010 but are planned for removal in future versions. The properties are now available as part of the Trading Partner Management user interface in the BizTalk Server Administration console.
EDI Context PropertiesThe following EDI context properties are deprecated in BizTalk Server 2010 .
  • DestinationPartyID
  • DestinationPartyName
SOAP AdapterThe SOAP adapter is deprecated in BizTalk Server 2010 . You should use the WCF-BasicHttp to communicate with Web services and clients that conform to the WS-I Basic Profile 1.1. To communicate with Web services and clients that conform to WS-*, use the WCF-WSHttp adapter.

Tools

ToolComment
BizTalk Web Services Publishing WizardThe BizTalk Web Services Publishing Wizard, a graphical user interface for communicating with or exposing BizTalk process as Web service, is deprecated. In BizTalk Server 2010 , you should instead use the BizTalk WCF Publishing Wizard with the WCF-BasicHttp and WCF-WSHttp adapters to provide Web Services communications.

Changed Features and Tools
[This is prerelease documentation and is subject to change in future releases. Blank topics are included as placeholders.]
This topic describes features and tools that were available in BizTalk Server 2009, but are replaced by new features in BizTalk Server 2010 .

Features

FeatureComment
BizTalk ExplorerThe BizTalk Explorer view in Visual Studio is removed in BizTalk Server 2010 . You should use the BizTalk Server Administration Console instead.
SQL AdapterThe SQL Adapter is removed in BizTalk Server 2010 . Consider using the Microsoft BizTalk Adapter for SQL Server provided in the Microsoft BizTalk Adapter Pack 2.0.

Tools

ToolComment
Add Web ReferenceThe option to use Add Web Reference to consume a Web service within a BizTalk project is removed. In BizTalk Server 2010 , you should use the Consume WCF Service Wizard to consume a Web service from a BizTalk project.

LinkWithin

Related Posts with Thumbnails