Saturday, August 30, 2008
Friday, May 9, 2008
Increasing Availability for BizTalk Server
I have been asked this question before, first think that comes to my mind is that you can easily redundant the servers which hosts your BizTalk application this was good answer at this time but after that i decide to know more about this i read too many articles concerning this issue plus disaster recovery and it ends up to the following .
there are many strategies you can follow to reach high availability but first lets explain the difference between high availability and disaster recovery.
Disaster recovery allows you to resume operation of a failed system but is typically a manual process and requires more recovery time than a high-availability implementation. Therefore, a disaster recovery implementation provides availability but not high availability. You should employ both high availability through server clusters and load balancing, and availability through disaster recovery, in a production BizTalk Server environment.
Now what are the strategies for high availability of your BizTalk application:
- Providing high availability using Windows Clustering. A server cluster is a group of independent computer systems, known as nodes, working together as a single system to ensure that critical applications and resources remain available to clients. If one of the nodes becomes unavailable as a result of failure or maintenance, another node immediately begins providing service (a process known as failover).
- A server cluster is typically recommended for the computers running SQL Server that house the BizTalk Server databases.
- A server cluster may be required to provide high availability for certain BizTalk adapters.
- A server cluster is typically recommended for the Enterprise Single SignOn master secret server.
- Providing high availability using Network Load Balancing (NLB). NLB delivers high availability by redirecting incoming network traffic to working cluster hosts if a host fails or is offline. Unlike server clusters, NLB does not require special hardware.NLB is provided for BizTalk Hosts by adding multiple servers to a group.Load balancing is provided for SQL Server disks through the use of a SAN or by adding multiple MessageBox databases.
- Increasing availability using BizTalk Server log shipping and disaster recovery.
- Increasing availability through implementation of the appropriate monitoring and maintenance strategies.
BizTalk Server News
I read this great news in Steven Martin's blog, Once SQL Server 2008 becomes generally available, Miscrosoft will follow with an updated version of BizTalk Server designed for the latest versions of Windows Server, the .NET Framework, Visual Studio, and SQL Server. This will mean that BizTalk Server customers will continue to take full advantage of the platform’s latest improvements including: scalability for mission-critical workloads, improved support for next-generation web and service oriented applications, improved virtualization support and better business insight through Office.
Micrososft will also taking the opportunity as part of this BizTalk Server release to deliver additional customer-requested capabilities for our core SOA infrastructure. Microsoft will give more updates on specific features in the coming months, but at a high level they are planning some new investments in the release that includes:
- New web service registry capabilities with support for UDDI (Universal Description Discovery and Integration) version 3.0
- Enhanced service enablement of applications (through new and enhanced adapters for LOB applications, databases, and legacy/host systems)
- Enhanced service enablement of “edge” devices through BizTalk RFID Mobile
- Enhanced interoperability and connectivity support for B2B protocols (like SWIFT, EDI, etc)
- SOA patterns and best practices guidance to assist our customer’s implementations
To ensure existing BTS applications continue to run without changes, Microsoft are taking an incremental approach and limiting the changes to the items listed above. Because this release build on existing bits, the name of this release will be BizTalk Server 2006 R3. Refreshing the bits (instead of applying a large Service Pack) provides for the best update experience. You should expect to see a CTP of BizTalk Server 2006 R3 later this year (with an RTM planned in H1 CY09).
for more details please visite http://blogs.msdn.com/stevemar/archive/2008/04/23/biztalk-server-platform-updates.aspx
Sunday, May 4, 2008
N-Tier Architecture
This refers to the architecture of an application that has 3 to N logical layer each layer is responsible for specific function and interacts with only the layer directly below.
Why N-Tier architecture?
You can easily scale out your application by deploying each layer on separate server. As each layer is totally separate and encpsulated from other layer so you can easily update/modify any layer without affection other layer or need to recompile them all. Here is the power of the n-tier as any additional features or change to a layer can be done without redeploying the whole application. Before we go further let’s have a look on this image
An n-Tier application usually has three tiers, and they are called the presentation tier, the business tier and the data tier. Let's have a look at what each tier is responsible for.
Data Tier: The data layer can usually be split into two separate layers. The first will consist of the set of stored procedures implemented directly within the database. These stored procedures will run on the server and provide basic data only. Not only are they pre-compiled and pre-optimized, but they can also be tested separately, Second layer will consist of set of classes which handle the stored procedure we call it CRUD operation (Create, Read, Update, Delete).
If your database changes for any reason, you can easily modify your data layer to handle them without affecting any other layers. This considerably simplifies maintenance.
Business Layer: this layer will encapsulate your busniss rule and logical validation; here we find classes which implement your business functionality. They neither access data (except through the data layer) nor do they bother with the display or presentation of this data to the user. All we are interested in at this point are the complexities of the business itself. By isolating this functionality, we are able to concentrate on the guts of our system without the worry of design, workflow, or database access and related concurrency problems. If the business changes, only the business layer is affected, again considerably simplifying future maintenance and/or enhancements.
Workflow Layer: This is one of the optional layers and deals with data flow to and from your system. It may or may not interact directly with the user interface, but always deals with external data sources. For instance, if you send or receive messages from a messaging queue, use a web service for extra information, send or receive information to another system, the code to handle this would be in this layer. You may wish to wrap your whole application in XML so that the choice of presentation layer can be expanded. This would also be handled in the Workflow Layer.
Presentation Layer: This layer handles everything to do with the presentation of your system. This does not just include your windows or web forms (or your user interface), but also all the classes which will help you present your data.
I hope this quick preview will help you