BizTalk Server Goal: Transcend Semantic Boundaries

BizTalk Server Goal: Transcend Semantic Boundaries While the BizTalk Framework links applications or businesses with each other, it doesn't do so directly. Instead, it provides an additional layer of functionality that is responsible for data transformations. A simple scenario is shown in Figure 1.7. The purchasing application in Business A needs to send an order document to a purchase processing application in Business B. Unfortunately, the applications are incompatible. Therefore, if the two businesses attempted to communicate directly, each application would not be able to interpret the other's data. The meaning of the data is clear only within each application. We can say that there is a semantic boundary around each application-outside of the boundary, the meaning of the data cannot be interpreted. The incoming data can't cross the semantic boundary either. Direct communication is therefore impossible. Figure 1.7 A business process using the BizTalk Framework BizTalk Server provides an extra layer that transcends the semantic boundary. In other words, BizTalk server A creates a mapping between the document in the original form and the XML format that it can easily interpret. The document is then sent over the Internet, in XML format, to BizTalk server B. This server in turn provides another mapping, this time between the XML document it just received and the form that represents the semantics understood by Application B. A Practical Example of Business Processing Let's see now how useful transcending the semantic boundaries is. To understand how BizTalk Server overcomes the semantic boundaries between applications and businesses, let's look at a specific example. Imagine you are a customer who wants to buy a computer by using a seller's Web site. You fill out the form specifying your order, type in your credit card number, and click the Order Now button. What happens next? The details are shown in Figure 1.8. Figure 1.8 An example of business processing Your order crosses the first semantic boundary and is received by the Order Management application on the seller's Order Management server. The application immediately sends out the order acknowledgement (across the same semantic boundary), so that you know your order was received correctly. To make sure you are able to pay for the computer you are buying, the Order Management application checks your available credit. Most likely this will involve accessing the financial database on another computer (the Finance server) in the finance department and crossing yet another semantic boundary. This server receives the request for the credit check, verifies that you are in good standing, and returns the confirmation to the Order Management application on the Order computer. Again, another semantic boundary is crossed. Next, the Order Management application needs to arrange for your order to be fulfilled. Toward this end, it sends a request to the Warehousing application, on the Warehousing server, crossing a semantic boundary for the fifth time. The Warehousing server consults the Warehousing database to verify that the computer system you ordered is available and can be shipped to you. It then sends the message back to the Order Management application, across the same semantic boundary. The Order Management application then contacts the Shipping application on the Shipping server to arrange for shipment, which involves yet another boundary. The Shipping application then arranges for the goods to be shipped to you. At the same time, it sends the shipping confirmation across the semantic boundary to the Order Management application on the Order server. This confirmation also contains information about the estimated delivery time for your computer. Of course, you want to know when you can expect your computer to arrive at your doorstep, so the Order Management application sends that information to you across the semantic boundary. After ordering the goods, it is time to arrange to pay for it, so the Order Management application sends the total charge to the Financial application on the Finance server, across another semantic boundary. As described, this process involves at least five different-possibly incompatible-systems and crossing many semantic boundaries. Without BizTalk Server, it would be difficult to perform the business transactions described in this example. Lesson Summary Business integration is a challenge facing many businesses. The two primary issues in integration are the need for cross-platform integration and business-to-business scalability. Older solutions to these problems were resource-consuming, expensive, and did not necessarily perform well. Specifically, they didn't provide a platform for electronic data exchange that would make the business accessible from anywhere at any time, reduce process time, help the consumers make better decisions faster, manage and share knowledge effectively, or manage dynamic business relationships efficiently. BizTalk Framework 2.0 is a business framework that addresses both these integration problems efficiently because it is based on XML and is therefore completely platform-independent. The central idea for this framework is XML-based message transmission. BizTalk Server 2000 is Microsoft's implementation of the BizTalk Framework. BizTalk Server also supports EDI, and there are plans for it to soon support RosettaNet.

Goals of the BizTalk Framework -- part 4

Keep in mind that the underlying standard is XML. The BizTalk Framework itself is a tool that helps you to adopt the XML solution. The idea behind the BizTalk Framework is to facilitate data exchange between applications and businesses using the XML standard, and by mapping one specific XML format into another, as shown in Figure 1.4. Figure 1.4 Integration using XML format The BizTalk Framework doesn't pose any restrictions on the data you can exchange. Instead, it simply assumes that applications are completely independent of one another. Therefore, no common protocol, database system, operating system, programming language, or object model is necessary. The only requirement is that the applications understand standard XML. As long as two applications can send and receive XML messages, they can communicate. For this reason, the idea of XML message transmission is central to the BizTalk Framework. Message transmission is a familiar concept in business settings. Business partners often request services from each other. The requests can be submitted electronically. From there it is only one step to message transmissions. This communications model based on message transmissions is easily extensible precisely because it places so few requirements on participating applications and processes. To make this communications model possible, BizTalk addresses the following technical challenges: Integrates heterogeneous environments across multiple applications and platforms within an organization. (This is called the application-to-application model.) Integrates with business partners using the business-to-business model. Uses existing information technology (IT) investments, including existing systems and mainframes. Reduces development time to allow businesses to compete in the flexible and fast-paced Web environment. Builds open standards, using XML for data exchange. Unfortunately, not all applications today natively support XML. This state of affairs is rapidly changing, but with the existing applications that don't support XML, if you want to adopt the BizTalk Framework, you need a software layer that transforms native documents into the XML format and routes them to the appropriate application or organization. BizTalk Server 2000 automates many aspects of this extra software layer so that you can use the BizTalk Framework with your existing applications, even if they don't natively support XML. This situation is illustrated in Figure 1.5. Figure 1.5 Integrating a non-XML application A simplified example of business-to-business communication using BizTalk Server is shown in Figure 1.6. In this example, two business applications, each belonging to a different organization, communicate over the Internet using XML-based message transmission. Because neither application supports XML, each needs to use the local BizTalk server to handle the message transformations. An application in Business A sends an order to an application in Business B by way of the local BizTalk server. After the transformation is performed on the local BizTalk server, the server passes the message onto the business partner's BizTalk server. The partner's server picks up the message, performs the appropriate transformation so that it is compatible with its local application, and passes the message to that application. A more specific example is considered in detail in Lesson 2 of this chapter. Figure 1.6 Two applications communicating using the BizTalk Framework The BizTalk Framework vs. Other Frameworks The BizTalk Framework is just one of a number of proposed solutions. Two other interesting solutions in use are Electronic Data Interchange (EDI) and RosettaNet. EDI uses a standardized format for the interchanges, and can be used across platforms. It supports two standards, UN/EDIFACT and X12. The UN/EDIFACT and X12 standards are discussed in more detail in Chapter 4, "Creating and Managing Document Specifications." EDI is an alternative to the BizTalk Framework, although BizTalk Server supports EDI. Some of EDI's advantages are the same as those of the BizTalk Framework: it enables business communication by using a unified framework. However, this framework was originally not XML-based, although the methodology for moving it into XML syntax exists. The disadvantages of EDI are that it is not intuitively easy to use; it is not easy to extend and adapt to different trading partners and different document types; and it is an expensive technology. NOTE If you and your trading partners already use EDI, you might want to keep this framework as a means of exchanging documents. BizTalk Server 2000 can handle EDI formats, so you can have the best of both worlds. The other interesting solution, RosettaNet, also offers a common format for document interchange, mainly centered around e-commerce. Although BizTalk Server 2000 doesn't support RosettaNet at the time of this writing, the BizTalk Server Accelerator for RosettaNet is available.

Goals of the BizTalk Framework -- part 3

Third Generation: The BizTalk Framework As seen earlier, being able to cross organizational boundaries is an important business requirement. To achieve this, the BizTalk Initiative, a multibusiness consortium, created the BizTalk Framework. This framework is the third generation solution, as shown in Figure 1.3. The following section examines the nature of the BizTalk Framework as an integration solution. Figure 1.3 The third generation of integration XML and the BizTalk FrameWork Solution By far the most successful integration solution available today is XML-based message passing between different platforms. XML is a platform-independent standard that describes data to be transmitted between computers regardless of the application or operating system. In other words, XML offers a common document representation that everybody can understand. To use the conference analogy again, you don't need interpreters, and you don't need to learn another language (except for some very basic phrases) because XML offers a common metalanguage that you can use to communicate, and in doing so it behaves much like the universal translator that was used in the television series Star Trek. The theory behind XML-based universal representation is that if everyone agrees to share certain basic assumptions about functionality and interface guidelines, everyone can interpret the meaning contained in a document without necessarily understanding the less important details, such as the original structure of the document. Imagine, for example, that Bill and Mary are designing two different applications and want their applications to exchange documents, but the applications each store their data differently. If the application designers agree to mark dates the same way, each doesn't need to know how the data is stored internally in the other's application. If Bill does not know where the date is located in Mary's document, but Mary explains where the date is, Bill knows something useful about Mary's document that he didn't know before. He can now decipher the dates in Mary's documents regardless of where they are placed. If Bill and Mary also agree on the notion of quantity, and Mary tells Bill where the quantity of his order is on the document, Bill knows even more about Mary's document. Now all Mary has to do is mark up the documents she is sending to Bill and describe each agreed-upon element using a tag, and Bill knows exactly what the document contains, even though the form of the document might be something he has never seen before. As long as the tags that are familiar to both users are in the document, and as long as they are used properly, each will have no trouble at all processing the other's documents. The BizTalk Framework supplies the generally agreed-upon set of basic assumptions mentioned previously (functionality and interface guidelines), and it also provides the flexibility of extending them as needed. In terms of the business objectives discussed in the previous section, BizTalk supports the business objectives while attempting to minimize the risk factors by allowing businesses to use the infrastructure they already have. There is no need for costly and error-prone modifications. To use the human language analogy, if you have always used French, you don't have to learn German, but rather you can continue doing business in French just as you always have. And, your German trading partners will happily do business with you-in German, of course. So, if your current applications work, you know that the solution will work as well. The operational requirement is also satisfied, because you can extend your French vocabulary as much as you like, and, as long as your partners understand your tags, they can understand your documents. Also, the cost of implementing this solution is low when compared with the earlier solutions. It is French throughout for you. Similarly, if your partners use German, they don't need to learn French to talk to you. In fact, if you use XML, you don't even need to modify your existing code. All you need to do is rely on the BizTalk Framework to handle the documents for you. Advantages of the BizTalk Framework There are many reasons why the BizTalk Framework promises to be successful. One important factor is that message passing using XML and XML-based schemas meets many requirements for interactions between systems or organizations. These include: A flexible universal language to describe and package information, allowing both rigidly structured and unstructured forms of the information A flexible mechanism for defining transformation rules for converting information from one format to another as needed Platform-independent communication protocols that handle interactions between applications or organizations Platform-independent security mechanisms to protect privacy and integrity of the data exchange Flexibility is an important advantage of using XML for inter-application and inter-business communications. You can easily add applications to your organization without the high cost of integration, and you can upgrade or replace applications without upsetting the overall integration of the organization. In fact, other applications, and even other organizations that do business with yours, need not be aware of the change, as long as the upgraded or replaced application can process XML. NOTE The requirement that applications support XML is a limitation that is already being addressed. More and more applications support XML as a matter of course. The support for Internet-based secure transport protocols makes XML-based business interactions even more attractive. Another important feature of XML-based solutions is that they are relatively easy and inexpensive to implement. This ease of use initially proved to be a bit too much of a good thing, though: it prompted the development of many independent XML-based solutions that extended XML in different, incompatible directions, with an unfortunate but predictable result-they pushed the incompatibility one level up. The developers had to then integrate different, incompatible integration solutions! This is analogous to translating between "universal translators" that claim to be universal only if you commit to never using another translator. So, "universal translators" suddenly turned out to be not that universal at all. It became clear that the time was ripe for a business standard. The BizTalk Framework is such a standard and is an industry-wide answer to the compatibility problem. In other words, it is a true universal translator. It is XML-based and helps you automate business processes and integrate data exchange between applications both within one organization, and between business organizations, using an open set of schemas. Within this framework, you can implement XML schemas and tags targeted specifically for use in messages sent between otherwise incompatible applications. But because you can register and share your schemas, everyone can access them, and there is no danger of incompatibility caused by lack of sufficient implementation information. The success of the first version of the BizTalk Framework was encouraging, but it soon became clear that some revisions were needed. And so, BizTalk Framework 2.0 now includes features that were lacking in version 1.0 of the product. These include transport binding, reliable message delivery, and the use of the Multipurpose Internet Mail Extensions (MIME) and Secure/Multipurpose Internet Mail Extensions (S/MIME) standards for attachments. BizTalk Server 2000 is Microsoft's implementation of BizTalk Framework 2.0. While the BizTalk Framework addresses many compatibility problems, it is not meant to address all business communication needs. Thus it does not deal with possible legal issues involved with business transactions, nor does it handle recovery from catastrophic failures. It also doesn't specify any business processes, such as purchasing or ordering. It simply allows other applications to address those issues within a common framework.

Goals of the BizTalk Framework -- Part 2

Previous Integration Attempts As the need for improving integration has grown more pressing, several solutions to address this need have been developed. These solutions are grouped into three generations, which are discussed below. First Generation: Distributed Objects The earliest integration attempts centered on the idea of distributed objects. Examples of these early solutions include the Distributed Component Object Model (DCOM) and the Common Object Request Broker Architecture (CORBA). In these first-generation solutions, for each pair of applications that needed to communicate, there had to be an interface specific to that pair. That is, they had to be tightly coupled. But the interface between these tightly coupled applications was not flexible. To extend the analogy used earlier, this interface can be compared to translation between human languages at a conference. If there is one person who understands English and another who understands French, the interface would be an interpreter who knows both these languages. Similarly, for two incompatible applications, an interface is needed that can talk to both. This situation is shown in Figure 1.1. Figure 1.1 The first generation of integration These tightly coupled interfaces required extensive programming and were costly to implement. In addition, the interfaces were not reusable-having one pair of applications connected in this way didn't put you even one step closer to solving the integration problem between one element of the pair and some other application. If you wanted to add another application to interconnect with your original pair, you needed to add more interfaces. To compare this again to the communication between the conference participants, if you wanted another person to join the conversation, and that person spoke German, but didn't know English or French, you would need two more interpreters, one between English and German, and another between German and French. If you then invited someone who spoke Italian, you would need four more interpreters. The applications behaved the same way in that you needed as many interfaces as the applications you needed to connect to. As you can see, the number of connections rapidly becomes unmanageable. So, scalability became a big problem in this scheme, which for practical uses limited the number of applications you could connect. Another problem of tight coupling was the reduced availability of each application due to slowness caused by blocked connections. This is analogous to someone needing something to be translated when the interpreter is working on several conversations all at once. As the interpreter's attention is focused on another conversation, all the person can do is wait. For this reason, this solution didn't scale well. An even bigger problem was scaling across a large geographical area; such interfaces were unbearably slow. While the distributed object model was able to address integration between a pair of applications, this first-generation solution wasn't as successful in addressing the business and risk-control requirements discussed earlier in this section: The business requirement of embracing the global marketplace was extremely difficult to meet because interfaces were application-specific. The remaining business requirements could not be met effectively for this same reason. The technical requirement of having a solution work correctly and the operational requirement of meeting the specific needs of an organization were difficult to satisfy. Because the interfaces required extensive programming, it was difficult to avoid bugs. For the same reason, operational flexibility was difficult and costly to achieve. The technical requirement and operational requirement were at odds with the requirement of cost effectiveness. Since each coupling had to be programmed separately, the cost was proportional to the number of couplings. Second Generation: Fire-and-Forget The biggest drawback of first-generation solutions was that they didn't perform well over large, geographically-distributed systems. Because globalization was (and is) a non-negotiable requirement in business integration, a new solution was needed. The second-generation solutions addressed the globalization issue by employing a fire-and-forget strategy. An example of this is the Microsoft Message Queue (MSMQ) technology. The idea was that instead of tight coupling, messages were used for communication. The messages were placed in the queue by using a message broker, and they could be processed at a later time, thus enabling asynchronous communication. With this approach, there still was a need for some mechanism to do the actual processing. Therefore, the solutions such as DCOM weren't replaced by this approach, but rather, they were augmented by it. Using the human languages analogy again, with this type of solution you still need interpreters for every language pair. The difference is that if the interpreter is not available at a particular moment, you can put the text you want translated on his desk to be translated as soon as he becomes available. Since you do not have to wait for the interpreter, you can go and do other things and the interpreter will let you know when he's completed his task. Your translation will be done when the interpreter becomes available. In this way, the waiting is reduced and the system availability is significantly improved. But because the interpreter might have a large stack of papers to translate, he needs to manage those papers in a predetermined way. For integration purposes, a good mechanism for managing the items to be translated is a queue. So, the central idea for the second-generation integration systems was a queuing mechanism. Figure 1.2 The second generation of integration Although the second-generation integration solutions represented significant progress on the road toward system integration, they were far from ideal. Most used proprietary technology and were therefore expensive to buy and maintain. Another problem is that while these systems worked well within an organization, they didn't scale well outside an organization's boundaries. What about risk-management requirements for these second-generation solutions? Again, there was the same problem as encountered with the first-generation solutions: technical and operational criteria were outweighed by the financial costs of the solutions. In addition, by the time these solutions became available, the need for cross-business communication became even more pressing.

Goals of the BizTalk Framework -- Part 1

Difficulties of Business Integration More and more organizations embrace business-to-business and business-to-consumer commerce models using the Internet. Most of those organizations must deal with two difficult and costly issues. The first is application integration within an organization, and the second is business integration across multiple organizations. Many companies still use independent systems for inventory management, sales tracking, employee information, and so on. Each of these systems has its own data representation, which is not interpreted easily by other systems. This makes it difficult for such businesses to exchange data between departments within the organization. In addition, the platforms that these systems run on are not readily compatible with one another, so significant resources in terms of development and hardware are needed to allow these systems and applications to communicate. This situation can be compared to a conference at which every participant speaks a different language. Each participant can talk, and each is intelligent and has a good understanding of his or her particular specialty. But because the delegates don't know one another's languages, they can't communicate. Business applications are like the conference delegates: they contain business logic and are able to communicate with the outside world using their own data formats, but trying to get them to communicate with one another is just about impossible. If you think this situation is difficult to manage, think about what happens when two or more such organizations attempt to do business together-the number of applications and platforms grows exponentially with each added system. To further complicate matters, electronic commerce is growing rapidly and the pace of this growth is accelerating. Therefore, many organizations see the need to integrate not only their own independent systems but also those of trading partners. The use of the Internet to automate supply chains, forecasting systems, and other systems will continue to expand. While creating a Web application and deploying it is relatively easy, integrating such an application company-wide with your existing systems is not. Many companies already find it difficult and costly to integrate systems within their own organizations. The requirements of integration heavily strain the capabilities of companies large and small. Meeting these requirements is the second tough issue many organizations face. Like the conference delegates, all those systems and applications need to exchange data, creating the need for a "universal translator." Attempts at Solving the Integration Problems The integration problems outlined in the previous section are not new. Fortunately, solutions exist to help you address these problems. In fact, the BizTalk Framework represents the third generation of solutions. Later in this chapter, some earlier approaches are examined as to why they were insufficient. But first, the following sections take a closer look at the computing requirements of business organizations. Business Requirements Obviously, different businesses have different specific requirements, but in terms of data and business process integration, their goals are surprisingly similar. The following are the five most common business requirements. Embrace global marketplace. Businesses need to be accessible from anywhere, at any time. This requirement is fairly obvious, considering that customers are spread out in various time zones all over the globe. Many customers also travel, and the goal is to give them the same experience regardless of where they are at the moment. Ideally, this includes having the same interface and, preferably, the same response time. Reduce process time. Time is money, so the faster you can serve one customer, the sooner you can serve the next one. Make better decisions faster. As consumers become more sophisticated and more informed, businesses need to concentrate on presenting the right information to the right people in the right format. This includes having the information available when it is needed and the ability to manipulate this information. Manage and share knowledge effectively. This goal includes developing and deploying solutions more quickly. Manage dynamic business relationships. As the speed and ease of doing business grows, the expectations of customers and partners grow as well. It is therefore essential that businesses adapt quickly to meet those expectations, or risk losing their customers to a competitor. All these requirements are very different, but all have one thing in common: none can be met without dealing with integration issues. Platform Transition Risks With the speed of doing business accelerating, companies must meet the above five requirements quickly and cost-effectively because doing so makes good business sense. But, even more important than improving the bottom line, businesses need to minimize the risks involved in the transition to a new platform. In fact, businesses will pay more for an integration solution if they can minimize the risk involved. Specifically, they must manage the following kinds of risk: Technical. The solution must work correctly. No business manager will consider an integration solution without a high degree of confidence that the solution will do what it promises to do. In other words, businesses want solutions that work. Operational. The solution must fit the business. The solution might work in general, but each business is different. Therefore, businesses demand that the solution be able to meet specific business requirements, including processing the transaction volumes, business characteristics, and transaction loads specific to that particular business. And, of course, the ideal solution will allow the business to grow. As the transaction volumes increase and the number of business partners grows, the solution should accommodate these changes gracefully. Financial. The solution must fit the budget. If the solution meets the two requirements above, but is too expensive for the business to adopt, it will not be adopted. Therefore, the solution must be cost-effective. Political. The solution must be acceptable to the key people in the organization. This is an often-neglected aspect, but it is vital that it be considered. After all, a solution may meet all the previous three requirements, but if you can't sell it to the board of directors, the solution will never be adopted. (Because the political risk is outside the scope of this book, it will not be discussed in more detail.) Any effective integration solution must take into account the above risks. As mentioned earlier, there have been many attempts to resolve the integration issues. The next section describes these attempts in light of the business requirements and risks examined in this section. Labels:asp.net, c#.net, Dot NET, DOT NET NUKE, html, java script, Share Point, SOAP, vb.net

A Beginner's Guide for ASP.NET 3.5,Download Ebook

This beginners guide for ASP .Net will help you to learn how to create database-driven ASP.NET 3.5 websites using C# 3.0. ASP.NET 3.5: A Beginner's Guide shows you just what you need to know to build rich Internet applications quickly and easily. The details on Web controls, CSS, SQL, ADO.NET, data binding, text files, event handlers, validation and security are also added in this book.You can find topics on latest technologies, such as LINQ and Ajax. Key features of ASP .Net ,Beginner's guide Key Skills & Concepts--Lists of specific skills covered in the chapter Ask the Expert--Q&A sections filled with bonus information and helpful tips Try This--Hands-on exercises that show how to apply your skills Notes--Extra information related to the topic being covered Tips--Helpful reminders or alternate ways of doing things Annotated Syntax--Example code with commentary that describes the programming techniques being illustrated

Creating an ASP.NET Web Service

Let's say that an online brokerage firm wants to provide a Web service to its customers. It could accomplish this by writing an ASP.NET Web application. However, the firm wants to extend the reach of its services so that they can be leveraged from other applications. For example, a portal site such as MSN or Yahoo! might want to provide these services but might lack the expertise or the desire to take on the burden of building the services themselves. Instead, the portal site can provide a UI to the customer and use the brokerage firm's Web service as the back end. At worst, the portal will retain the customer within its site and potentially increase its ad revenue. At best, the portal can charge an incremental amount on top of the fees provided by the brokerage firm. Either way, it is potentially a win-win situation for the portal company and the brokerage firm. In this chapter, I build the Securities Web service, which allows the client to perform actions such as obtaining a quote for a particular stock, bond, or mutual fund. The individual methods will contain skeleton implementations that let you focus on the mechanics of building Web services using ASP.NET. The first thing I need to do is define the endpoint for the Securities Web service. A Web service is defined by an .asmx file, which serves as the endpoint for the Web service. Calls made to .asmx files are intercepted and processed by the ASP.NET runtime. The implementation of the Web service is encapsulated within a class. The class definition can either appear inline within the .asmx file or be contained in a separate dynamic link library (DLL). The .asmx page needs to contain information that the runtime can use to locate the class. Each .asmx page contains a directive at the top of the page that specifies where and in what form the implementation of the Web service can be found. This directive is used by the ASP.NET runtime to bind the Web service to a class that contains the implementation. Here is an example in which the implementation of the Web service is contained within the .asmx file: <%@ WebService Language="c#" Class="BrokerageFirm.Securities" %>namespace BrokerageFirm { // Inline definition of the Securities class public class Securities { Implementation... } } The Class attribute contains the fully qualified name of the class that implements the Web service. If the code resides within the .asmx file, you must set the Language attribute, which specifies the language in which the code was written. The first time the Web service is accessed, the ASP.NET runtime will use the Language attribute to compile the code with the appropriate compiler. Thus, even if the code implementing the Web service is contained within the .asmx file, it will always be executed as compiled machine code. Out of the box, ASP.NET is configured to dynamically compile code written in C#, Visual Basic, Visual Basic .NET, and JScript .NET. You can configure additional languages within the web.config file or the machine.config file. The following is the compilation section of the machine.config file found in the C:\WINNT\Microsoft.NET\Framework\version\CONFIG directory: As you can see, the default language is Visual Basic .NET (vb), so my C# example must set the Language attribute to c#, cs, or csharp. The compilation section also includes a list of assemblies that are referenced by code within the .asmx file. If the Securities Web service were to reference entities from an assembly other than those listed in the preceding code, I could add a new machine-wide reference to my machine.config file or an application-wide reference to my web.config file. The last add element specifies a wildcard for the assembly name. If an assembly is referenced within an .asmx file that was not previously listed, the ASP.NET runtime will search for the assembly. (See the product documentation for the exact search order.) The class implementing the Web service can also reside within a compiled assembly. By convention, the assembly is placed in the Web application's bin directory because this directory is always included in the search path of the runtime. This is the default configuration for Web services created using Visual Studio .NET. The following is the WebService directive that Visual Studio .NET creates automatically: <%@ WebService Language="c#" Codebehind="Service1.asmx.cs" Class="BrokerageFirm
.Service1" %>As is typical in the Visual Studio product line, most of the attributes defined in the WebService directive are used by the editor and are ignored by the runtime. As I mentioned, you must specify the Language attribute only if the implementation of the Web service resides within the .asmx file. In addition, the code-behind file is always ignored by the ASP.NET runtime and is used by Visual Studio .NET to bring up the appropriate source code file when you select View Code within the IDE. One other potential gotcha is that Visual Studio .NET will only partially maintain this file. When you rename the .asmx file to something more meaningful, Visual Studio .NET will automatically rename the associated code-behind file and update the WebService directive accordingly. As a common practice, I also rename the class that implements the Web service to match the name of the .asmx file. Unfortunately, Visual Studio .NET will not automatically update the Class attribute. If you rename the class, you have to manually update this attribute yourself. Furthermore, double-clicking the .asmx file to update this attribute will display the design surface, not the file text. Visual Studio .NET does not provide the same buttons shown on an .aspx file's design surface that allow you to switch between the design view and the underlying text of the file. You have to right-click the file, choose Open With, and then select Source Code (Text) Editor. Now that I have discussed the two options—placing the implementation for your Web service within the .asmx file or within its own assembly—I am sure you are wondering which one you should use. Well, as with most design decisions, it depends. Placing the code within the .asmx file provides the simplest means of deployment because ASP.NET will compile the code dynamically for you. However, deploying the implementation within an assembly ensures that your code will not contain compilation errors. Also, if you are deploying the Web service outside the confines of your data center, others will not have access to the source code. Another potential advantage of having the implementation of your Web service reside within an assembly is that it can be directly referenced by other applications hosted on the same machine. For example, suppose I provide an HTML-based UI that allows my customers access to the functionality of the Securities Web service. If the class containing the implementation of the Web service is in its own assembly, the Web application can reference the assembly and directly access the Web service class. This avoids the unnecessary overhead of accessing the functionality remotely. You should take this approach with caution, however. Some Web services rely on services provided by the ASP.NET runtime to function correctly. For example, a Web method might set an attribute stating that the ASP.NET runtime must create a new transaction on its behalf. Because ASP.NET is responsible for ensuring that a transaction is created, no transaction will be created if the class implementing the Web service is accessed directly. Regardless of which option you choose, the code for implementing the Web service will be the same. For starters, I will implement one method within my Securities Web service, InstantQuote. Plenty of services on the Web give quotes on the price of a company's stock. However, these quotes are often time delayed and can be more than 20 minutes old. InstantQuote will use an extremely complex algorithm to obtain the price a security is trading at on the floor. Following is the implementation. using System; using System.Web.Services; namespace BrokerageFirm { public class Securities : WebService { [WebMethod] public double InstantQuote(string symbol) { double price = 0; switch(symbol) { case "MSFT": price = 197.75; break; case "SUNW": price = 2.50; break; case "ORCL": price = 2.25; break; } return price; } } } All right, so the algorithm is not that complex. What do you expect with an example? The important thing to note is that the implementation of the Web service is a standard public class declaration with a WebMethod attribute decorating the InstantQuote method. This class declaration can be either compiled into an assembly or placed as is within the .asmx file, and it is the same whether it is contained within the .asmx file or compiled into a separate DLL. Each method that is intended to be exposed by the Web service must be public and must be decorated with the WebMethod attribute. This tells the ASP.NET runtime to expose the method as publicly accessible. From this point on, I will refer to a method of a class decorated with the WebMethod attribute as a Web method. When you decorate a method with the WebMethod attribute, you can also set various properties that modify the behavior of the ASP.NET runtime. Table 6-1 lists the properties exposed by the WebMethod attribute. Table 6-1 Properties of the WebMethod Attribute Property Description BufferResponse Specifies whether the response to the client should be buffered. CacheDuration Specifies the amount of time, in seconds, that a response will be cached in memory by the Web server for a given response. The default is 0. Description Specifies the value of the description element under each operation element within each type definition within the ASP.NET-generated WSDL document. EnableSession Specifies whether the ASP.NET session state services will be available for the implementation of the method. MessageName Specifies the name of the method exposed by the Web service. Specifically, it sets the name of the element within the body of the SOAP message that contains the parameters as well as the suffix of the SOAP action. It also specifies the prefix of the names of the message, input, and output elements within the ASP.NET-generated WSDL document. TransactionOption Specifies the transactional support that should be provided for the implementation of the method. The method can serve only as the root of a transaction and cannot participate in the caller's transaction. The ASP.NET page framework also provides the WebService attribute. This attribute is set at the class level and is used to modify properties of the Web service as a whole. Changes made via the WebService attribute will be reflected in the Web service's WSDL document. Table 6-2 lists the properties exposed by the WebService attribute. Table 6-2 Properties of the WebService Attribute Property Description Description Specifies the description element under the service element within the ASP.NET-generated WSDL document. Name Specifies the name of the service element within the ASP.NET-generated WSDL document. It also specifies the prefix for the names of the portType, binding, and port elements. Namespace Specifies the target namespace for the WSDL document as well as the schema document that defines the structures for encoding the parameters within the body of a SOAP message. It also specifies the prefix of the namespace for the schema that contains any custom types defined by the Web service and the value of the SOAP action. Now that I have defined the Securities Web service, let's talk about how clients can access it.

SOAP

At the core of Web services is Simple Object Access Protocol (SOAP), which provides a standard way of packaging messages. SOAP has received a lot of attention because it facilitates RPC-style communication between a client and a remote server. But plenty of protocols have been created to facilitate communication between two applications—including Sun's RPC, Microsoft's DCE, JAVA's RMI, and CORBA's ORPC. So why is SOAP getting so much attention? One of the primary reasons is that SOAP has incredible industry support. SOAP is the first protocol of its kind to be accepted by practically every major software company in the world. Companies that rarely cooperate with each other are rallying around this protocol. Some of the major companies that are supporting SOAP include Microsoft, IBM, Sun Microsystems, SAP, and Ariba. Here are some of the advantages of SOAP: It is not tightly coupled to one language. Developers involved with new projects can choose to develop in today's latest and greatest programming language. But developers who are responsible for maintaining legacy applications might not have a choice about the programming language they use. SOAP does not specify an API, so the implementation of the API is left up to the programming language (such as Java) and the platform (such as Microsoft .NET). It is not tightly coupled to a particular transport protocol. The SOAP specification does describe how SOAP messages should be bound to HTTP. But a SOAP message is nothing more than an XML document, so it can be transported over any protocol that is capable of transmitting text. It is not tied to any one distributed object infrastructure. Most distributed object systems can be extended (and some of them are) to support SOAP. It is important to realize that even with SOAP, middleware such as COM+ still plays an important role in the enterprise. Component middleware is still responsible for some of the more advanced object management features such as object lifetime management, transactions, object pooling, and resource pooling. SOAP enables a degree of interoperability between different systems that are running component middleware from competing vendors. It leverages existing industry standards. The primary contributors to the SOAP specification intentionally avoided reinventing anything. They opted to extend existing standards to meet their needs. For example, SOAP leverages XML for encoding messages. Instead of using its own type system, SOAP leverages the type definitions already defined within the XML Schema specification. And as I have mentioned, SOAP does not define a means of transporting the message; SOAP messages can be bound to existing transport protocols such as HTTP and SMTP. It enables interoperability across multiple environments. SOAP was built on top of existing industry standards, so applications running on platforms that support these standards can effectively communicate via SOAP messages with applications running on other platforms. For example, a desktop application running on a PC can effectively communicate with a back-end application running on a mainframe that is capable of sending and receiving XML over HTTP. This chapter covers the following key aspects of the SOAP specification: The SOAP envelope. This is used to encode header information about the message and the body of the message itself. SOAP Encoding. This is a standard way of serializing data into the body of a SOAP message. RPC-style messages. I discuss the protocol you can use to facilitate procedure-oriented communication via request/response message patterns. The HTTP POST protocol binding. This is the standard method of binding SOAP messages to HTTP. Before I go any further, I want to discuss the status of SOAP. This chapter was written against version 1.1 of the SOAP specification (http://www.w3.org/TR/SOAP). The World Wide Web Consortium (W3C) is continuing to develop SOAP. On July 9, 2001, a working draft of SOAP 1.2 was published (http://www.w3.org/TR/2001/WD-soap12-20010709) by the XML Protocol Working Group. As an acknowledgment of the phenomenal industry support that SOAP enjoys, the XML Protocol Working Group is committed to maintaining a smooth migration path from SOAP 1.1 to SOAP 1.2. Many of the proposed modifications are fit-and-finish and do not radically alter the use of SOAP. Much of what you have learned about SOAP 1.1 will directly translate to SOAP 1.2. In addition, the majority of the Microsoft products that incorporate SOAP will likely not adopt SOAP 1.2 until it becomes an official W3C recommendation. Therefore, I recommend that you focus on learning the SOAP 1.1 protocol with an eye on the deltas in version 1.2.

A Simple Commerce Application

You will first create an ASP.NET Web Form that collects and validates credit card information. The Web Form allows users to enter their credit card information, and then it informs users whether the information they entered is valid. You then move the credit card validation logic into a Web service and modify the Web Form so that it calls the Web service to validate the credit card information. Creating a Web Form You can create a Web Form by opening Visual Studio .NET and creating a new Web Application project. Set the project type to your language of choice, and select the Web Application template. Name your project Commerce, and set the location to a URL that points to the targeted Web server, as shown here: Visual Studio .NET creates a project on the specified Web server and places template Web application files into that directory. Included in these files is a Web Form page named WebForm1.aspx. Rename it Order.aspx, and then change the name of the class defined within Order.aspx from WebForm1 to Order by following these steps: Open the Order.aspx code-behind file by right-clicking on the filename in Solution Explorer and selecting View Code. Change the name of the WebForm1 class and its corresponding constructor to Order. In the Properties pane, change the name of the label to Status, the text of the label to Please enter your credit card information, the name of the button to PlaceOrder, and the text of the button to Place Order. After you adjust the layout and add some additional text, the Web Form should look similar to the following: Next you provide the implementation for the Place Order button. To add an event handler for the order button, double-click it and write the following code so that when the user clicks the button, the Validate method is called to determine whether the credit card information the user entered is valid. The code will also adjust the label's text to display appropriate text to inform the user whether the credit card was valid. public void PlaceOrder_Click(object sender. Syste.EventArgs e) { if(Validate(TextBox1.Text, Calendar1.SelectedDate)) { Status.Text = "Thank you for your order."; } else { Status.Text = "Credit card invalid."; } } Next you create the Validate method immediately following the PlaceOrder_Click method. public bool Validate(string cardNumber, DateTime expDate) { if(expDate >= DateTime.Today) { int total = 0; int temp = 0; char [] ccDigits = cardNumber.ToCharArray(); for(int i = 0; i < cardNumber.Length; i++) { if(((i+1)%2) == 0) { total += int.Parse(ccDigits[i].ToString()); } else { temp = int.Parse(ccDigits[i].ToString()) * 2; if(temp > 9) { temp = (int)temp - 9; } total += temp; } } if((total%10) ==0) { return true; } else { return false; } } else { return false; } } The Validate method determines whether the expiration date has passed. If it has not, the Validate method uses a standard mod10 algorithm to validate the credit card number. Now compile and test the Web application to ensure that it works as expected. Creating a Payment Web Service At this point, the validation functionality is embedded in the Web Form. Now I will show you how to leverage the validation functionality within other applications. For example, you might want to develop a WinForm application for running the cash registers. This application would probably need to call the same logic to validate credit cards. If you expose the validation logic as a Web service, any application that can send and receive XML over HTTP will be able to invoke the service to validate credit card information. You have a couple of options for creating the new Web service. You can simply add the Web service to an existing application by choosing Add Web Service from the Project menu. Or you can create a new project to contain the Web service. Recall that your intention is to have the credit card validation logic serve as a shared resource across multiple applications. It might have infrastructure and scalability requirements that differ from those of the commerce application. So, in this case you will create a separate application—a Visual Studio .NET Web service application. First open Visual Studio .NET and select Create New Project. Set the project type to your language of choice, and select the Web Service template. Name the project Payment, and set the location to a URL that points to the targeted Web server, as shown here: Change the name of the Service1.asmx file to CreditCard.asmx. Because it is good practice to have the class name match the name of the .asmx file, change the name of the Service1 class to CreditCard. Visual Studio .NET creates a code-behind file for the .asmx file similar to those it creates for .aspx files, so you must open CreditCard.asmx.cs to modify the class declaration. To view the code-behind file, right-click on CreditCard.asmx and choose View Code. Change the name of the Service1 class and its corresponding constructor to CreditCard. Next cut the Validate method from the Order Web Form and paste it into the CreditCard class. Then decorate the class with the WebMethod attribute and compile the application. The WebMethod attribute is the only code required to expose the Validate method on the Web! [WebMethod] public bool Validate(string cardNumber, DateTime expDate) { } The WebMethod attribute tells the ASP.NET runtime to provide all of the implementation required to expose a method of a class on the Web—including the ability to advertise the Web service's functionality in the form of Web Services Description Language (WSDL). Visual Studio .NET will use the automatically generated WSDL to create a reference to the Web service in your commerce application. Another service that ASP.NET provides the Payment Web service is the automatic generation of documentation for the Web service and a test harness. To invoke this functionality, use a Web browser to navigate to the CreditCard.asmx file, as shown here: Next test the Validate method using the test harness supplied with the documentation. Entering a valid credit card number and a date of 1/1/2052 produces the following results (assuming you are not reading a 50-year-old book): true As expected, the result is true. However, the XML response message is not a valid SOAP message. There are multiple ways in which an ASP.NET-hosted Web service can be called. The Web service will return a well-formed SOAP message only if the request was a SOAP message. I will discuss ASP.NET-hosted Web services in detail in Chapter 6. Updating the Order Web Form The next task is to switch back to the Commerce application and update the Order Web Form so that it calls the CreditCard Web service to validate the user's credit card. You first add a Web reference for the CreditCard Web service to the commerce application by using the Web Reference Wizard. You start the wizard by choosing Add Web Reference from the Project menu. In the Address text box, enter the URL to the server that hosts your targeted Web service. Click on the link to the Payment Web service that is listed in the right pane, as shown here: Click Add Reference. You should see the Web reference listed in Solution Explorer. Visual Studio .NET processes the WSDL metadata associated with the Payment Web service and automatically creates a proxy. You can think of WSDL as the Web services equivalent of a TypeLib. The resulting proxy allows the Web service to be treated like any other .NET class. Next you alter the implementation of the PlaceOrder_Click method to call the Web service instead of the local Validate function. First create an instance of the CreditCard class by using the new keyword as you would with any other .NET type. Notice that the default namespace for the Web service is the name of the server on which it resides. public void PlaceOrder_Click (object sender, System.EventArgs e) { localhost.CreditCard cc = new localhost.CreditCard(); Finally you call the Validate method on the cc object to cause a communication exchange to occur between the client (the Order Web Form) and the CreditCard Web service. if(cc.Validate(TextBox1.Text, Calendar1.SelectedDate)) { Status.Text = "Thank you for your order."; } else { Status.Text = "Credit card invalid."; } } If you are writing the code as you read this chapter, notice that you have full IntelliSense support for the cc object. After you type cc., the list of methods supported by the object, including the Validate method, will be shown. As soon as you type the opening parenthesis for the method, the parameters for the method will be displayed—including the .NET equivalent of the Web service's parameter types. As you have seen, it is easy to refactor a .NET application to expose its business logic via Web services. You simply copy the local method and place it into the .asmx code-behind file for the Web service. The only code required to expose the method via HTTP is the WebMethod attribute. Once the code is compiled and deployed, any client that supports HTTP and is capable of parsing strings can call the method.

Why Web Services?

Component-based programming has become more popular than ever. Hardly an application is built today that does not involve leveraging components in some form, usually from different vendors. As applications have grown more sophisticated, the need to leverage components distributed on remote machines has also grown. An example of a component-based application is an end-to-end e-commerce solution. An e-commerce application residing on a Web farm needs to submit orders to a back-end Enterprise Resource Planning (ERP) application. In many cases, the ERP application resides on different hardware and might run on a different operating system. The Microsoft Distributed Component Object Model (DCOM), a distributed object infrastructure that allows an application to invoke Component Object Model (COM) components installed on another server, has been ported to a number of non-Windows platforms. But DCOM has never gained wide acceptance on these platforms, so it is rarely used to facilitate communication between Windows and non-Windows computers. ERP software vendors often create components for the Windows platform that communicate with the back-end system via a proprietary protocol. Some services leveraged by an e-commerce application might not reside within the datacenter at all. For example, if the e-commerce application accepts credit card payment for goods purchased by the customer, it must elicit the services of the merchant bank to process the customer's credit card information. But for all practical purposes, DCOM and related technologies such as CORBA and Java RMI are limited to applications and components installed within the corporate datacenter. Two primary reasons for this are that by default these technologies leverage proprietary protocols and these protocols are inherently connection oriented. Clients communicating with the server over the Internet face numerous potential barriers to communicating with the server. Security-conscious network administrators around the world have implemented corporate routers and firewalls to disallow practically every type of communication over the Internet. It often takes an act of God to get a network administrator to open ports beyond the bare minimum. If you're lucky enough to get a network administrator to open up the appropriate ports to support your service, chances are your clients will not be as fortunate. As a result, proprietary protocols such those used by DCOM, CORBA, and Java RMI are not practical for Internet scenarios. The other problem, as I said, with these technologies is that they are inherently connection oriented and therefore cannot handle network interruptions gracefully. Because the Internet is not under your direct control, you cannot make any assumptions about the quality or reliability of the connection. If a network interruption occurs, the next call the client makes to the server might fail. The connection-oriented nature of these technologies also makes it challenging to build the load-balanced infrastructures necessary to achieve high scalability. Once the connection between the client and the server is severed, you cannot simply route the next request to another server. Developers have tried to overcome these limitations by leveraging a model called stateless programming, but they have had limited success because the technologies are fairly heavy and make it expensive to reestablish a connection with a remote object. Because the processing of a customer's credit card is accomplished by a remote server on the Internet, DCOM is not ideal for facilitating communication between the e-commerce client and the credit card processing server. As in an ERP solution, a third-party component is often installed within the client's datacenter (in this case, by the credit card processing solution provider). This component serves as little more than a proxy that facilitates communication between the e-commerce software and the merchant bank via a proprietary protocol. Do you see a pattern here? Because of the limitations of existing technologies in facilitating communication between computer systems, software vendors have often resorted to building their own infrastructure. This means resources that could have been used to add improved functionality to the ERP system or the credit card processing system have instead been devoted to writing proprietary network protocols. In an effort to better support such Internet scenarios, Microsoft initially adopted the strategy of augmenting its existing technologies, including COM Internet Services (CIS), which allows you to establish a DCOM connection between the client and the remote component over port 80. For various reasons, CIS was not widely accepted. It became clear that a new approach was needed. So Microsoft decided to address the problem from the bottom up. Let's look at some of the requirements the solution had to meet in order to succeed. Interoperability The remote service must be able to be consumed by clients on other platforms. Internet friendliness The solution should work well for supporting clients that access the remote service from the Internet. Strongly typed interfaces There should be no ambiguity about the type of data sent to and received from a remote service. Furthermore, datatypes defined by the remote service should map reasonably well to datatypes defined by most procedural programming languages. Ability to leverage existing Internet standards The implementation of the remote service should leverage existing Internet standards as much as possible and avoid reinventing solutions to problems that have already been solved. A solution built on widely adopted Internet standards can leverage existing toolsets and products created for the technology. Support for any language The solution should not be tightly coupled to a particular programming language. Java RMI, for example, is tightly coupled to the Java language. It would be difficult to invoke functionality on a remote Java object from Visual Basic or Perl. A client should be able to implement a new Web service or use an existing Web service regardless of the programming language in which the client was written. Support for any distributed component infrastructure The solution should not be tightly coupled to a particular component infrastructure. In fact, you shouldn't be required to purchase, install, or maintain a distributed object infrastructure just to build a new remote service or consume an existing service. The underlying protocols should facilitate a base level of communication between existing distributed object infrastructures such as DCOM and CORBA. Given the title of this book, it should come as no surprise that the solution Microsoft created is known as Web services. A Web service exposes an interface to invoke a particular activity on behalf of the client. A client can access the Web service through the use of Internet standards.

ASP.NET 2.0 AJAX

Duration: 3 Days (24 Hours)Prerequisite:• Exposure to Web application programming using ASP .NET with C# and connecting to Relational Databases from front end.• Good Knowledge in OOP concepts and java Scripts Course Approach:• Demo will be shown for the understanding of concepts wherever required • Hands on lab will be provided for all applicable topics• 50% Demo and Presentation ( first half of the day’s session ) and 50% of Hands on Lab ( second half of the day’s session ) DAY 1: Introduction to AJAX • Rich Internet Applications• Remote Scripting• AJAX Principles• HTTP Primer HTTP Requests HTTP Responses• AJAX Communication Techniques The Hidden Frame Technique XMLHttpRequests The XmlHttpRequest Object • XMLHttpRequest - Overview• Creating the Object • Asynchronous Data Transfers • The Ready State • HTTP Status Codes and Headers • Asynchronous Resource Retrieval• Retrieving XML Data• HTTP Response and Renderingo XML o JSON o Rendering the Response with CSS AJAX Framework • Sample Ajax and N-Tier Applicationo Presentation Layero Business Layero Data Layero Data Store• .NET Framework and Libraries• Understanding the .NET Libraryo Installing the Libraryo Using and Examining the Library• Ajax and Web Serviceso SOAP• Creating the Web Serviceo Building AJAX Applicationo Accessing with XmlHttpRequest DAY 2: ASP.NET AJAX • Introduction to Atlas• Introduction to ASP.NET AJAX• Dynamic Partial-Page Updates • Client-Side Network Callbacks • ASP.NET AJAX Features to an Existing o Web Applicationo Web Service Server Controls in ASP.NET AJAX • Adding the AJAX Server Controls to Visual Studio 2005 o Creating an AJAX enabled Web Siteo Adding the Server Controls to the Toolbox • Introducing the Script Manager Control o Using the Script Manager Designer Interface o Programming with the Script Manager • Introducing the Script Manager Proxy Control • Introducing the Update Panel Control o Using the Update Panel Designero Programming with the Update Panel• Introducing the Update Progress Control • Introducing the Timer Control The UpdatePanel Control • Introduction to the UpdatePanel Control • Multiple UpdatePanel Controls • Using the UpdatePanel Control with Data-Bound Controls • Using the UpdatePanel Control with Master Pages • Using the UpdatePanel Control with User Controls • Using the UpdatePanel Control with a Web Service • Customizing Error Handling for UpdatePanel Controls • Animating UpdatePanel Controls • Canceling an Asynchronous Postback • Working with PageRequestManager Events DAY 3: Introducing ASP.NET AJAX Extenders • Accordion• AlwaysVisibleControl• AutoComplete• CascadingDropDown• ConfirmButton• NumericUpDown• RoundedCorners• TextBoxWaterMark• Popup Control• Modal Popup• Collapsable • Draggable• FilteredTextBox• PasswordStrength Microsoft AJAX Library Client-side AJAX Programming • Introduction• Global Namespace • Sys • Sys.Net • Sys.Serialization • Sys.Services • Sys.UI • Sys.WebForms ASP.NET AJAX Extensibility • Introduction• Creating Custom ASP.NET AJAX Client Controls

Debugging a DotNetNuke Installation

In this series of tutorials we demonstrate advanced debugging and troubleshooting techniques for DotNetNuke. This is an expert-level series that explores profiling, stack tracing, packet tracing, reverse compiling and more. We will also demonstrate how to troubleshoot performance problems caused by third party modules.

We will cover the following topics and tools:

* Part 1 - Introduction to Profilers
* Part 2 - Using SQL Profiler to Analyze Database Activity
* Part 3 - Using DotTrace to Analyze .NET Activity
* Part 4 - Using Managed Stack Explorer to View Stack Traces
* Part 5 - Using WireShark to wire-tap a Broken Module


Video 1 - Introduction to Profilers

* Introduction
* What are Profilers?
* Two Kinds of Profilers
* How to use Profilers to find Problems
* Two common types of performance problems
* Common Profiler Tools

Time Length: 2min 40secs

You need to Subscribe as a member of DNN Creative Magazine and Login to download this video tutorial.
Video 2 - SQL Profiler

* How to get SQL Profiler
* Running SQL Profiler
* Connecting to a Database Server
* Recreating the Performance Problem
* Understanding SQL Profiler's Data

Time Length: 4min 08secs
Video 3 - DotTrace

* How to get DotTrace
* Running DotTrace
* Profiling IIS
* A word of Warning
* Collecting Performance Data
* Understanding the Thread Tree and Call Tree
* Exploring the Call Tree
* Diagnosing the Performance Issue

Video 4 - Managed Stack Explorer

* Managed Stack Explorer vs DotTrace
* How to get Managed Stack Explorer
* Exploring Processes
* Exploring Threads
* Exploring Stack Traces
* Identifying the Problem

Video 5 - WireShark

* What is WireShark?
* How do you get a copy of it?
* Starting up WireShark
* The problem: A broken flash module
* Our first Wire-Tap
* Converting Packets to Streams
* Exploring the Flash Module's Stream
* Identifying the Flash Module's Problem
SOURCE:http://www.dnncreative.com/Tutorials/DNNTutorialsforAdvancedUsers/DotNetNukeDebugging/tabid/638/Default.aspx

DotNetNuke Portal Starter Kit

Overview

• Fully dynamic web site allows for an unlimited number of Pages
• Pages can contain an unlimited number of Content regions and Content types
• Advanced Content Management enabled via a standard Web Browser
• Build an online Community with robust Membership Management
• Secure your Content using advanced Roles and Permissions
• Multi-tenancy allows for multiple Sites to be hosted from a single installation

License

• Unrestricted Open Source BSD license
• FREE use in non-commercial and commercial environment

Extensibility

• Modular architecture enables hundreds of third party plug-in Modules
• Designer-friendly Skinning engine for total site customization
• Multiple database support through Providers
• More than 70 Language Packs to support International users

Support

• More than 550,000 registered users since Dec 24, 2002
• Maintained and supported by DotNetNuke Corporation

Dot Net Nuke (DNN)

Novel demands of the online global business environment for the last few years have initiated the business industry to adopt new technologies in form new software, open source frameworks, and content management systems to raise the opportunities for online business.

Dot Net Nuke (DNN) is open source content management system; initially developed in year 2002 and fully developed community for the last 6years supports it with strength of more than 575,000 registered users all over the world. Developed on most popular Microsoft ASP.NET technology and uses various databases for the storage of content. It is cheap to use and helps in reduction of total cost on development.
Few technical and non-technical advantages of DNN

* Its perfect content management system
* Free of cost availability and no licensing fees
* Full access to the source code to custom fit DNN to particular organizational needs
* DNN community building continually new features and functions
* Few important contents manageable by DNN are Text, Images, Documents, Links, Events, News, Banner ads, Threaded discussion forums, Email forms, Broadcast email, Site registration, RSS news feeds etc
* Modifications like graphic design and functionality
* Integration
* Able to support multiple websites from a single application installation
* Built in features provides extraordinary functionality
* Easy installation
* Management of site hosting, content management, security, web design and membership options
* Multi-language feature

Our dedicated services for DNN projects

Hiddenbrains.com has performed various offshore projects to prove its progressive approach towards new technologies for online web development. We have worked on several open source projects. Our research & development team always seeks opportunities to innovate and implement new technologies to satisfy our offshore clients. We are having decent presence for providing services in DNN customization, as we are group of experienced professionals. Projects were handling by team of experts to achieve perfect solution for each project. One of our successful projects is as under:
Fanous.com

Fanous.com was a jewelry shop website developed by hiddenbrains.com using DNN technology. Our development team had performed the project by implementation of its total features. Such a wonderful project covered all technical functionality of DNN. This website was able to handle the total functionality of multiple portals with single application.
There were three portals

* Fanous.com (it was front portal for the presentation of products and services for the customers)
* Fanous.biz (it was main administration for the total control of content on the website)
* Precision.net (it was administrative control for the employees of the company and other administrative controls)

Implementation of DNN features under this project according to business requirements of the client were

* Strong admin control over three portals
* Users at front hand able to choose the jewelry and order and can pay
* System settings
* Sub admin facilities and different roles given to other admin users

SOURCE:http://www.hiddenbrains.com/dotnet-nuke-development.html

Hire DotNetNuke Developers / Programmers

Dot Net Nuke (DNN) is open source content management system; initially developed in year 2002 and fully developed community for the last 6years supports it with strength of more than 575,000 registered users all over the world. Developed on most popular Microsoft ASP.NET technology and uses various databases for the storage of content. It is cheap to use and helps in reduction of total cost on development

DotNetNuke Content Management System is extensible and customizable through the use of skins and modules, and it can be used to create, deploy, and manage intranet, extranet, and web sites

DotNetNuke is an open source web application framework written in VB.NET for the ASP.NET framework.. DotNetNuke is designed for use on the Microsoft ASP.NET 2.0, 3.0, and 3.5 platforms using Visual Studio 2005, Visual Studio 2008, or Visual Web Developer.

ExpertsFromIndia can build you a DotNetNuke module customized to fit your business needs. Our developers have the skills to design and build a custom solution that follows your current business logic and integrate it into your DotNetNuke web site.

Our DotNetNuke Module Development services include:

• Custom web application development
• Business logic and data integration
• Business process integration
• 3rd party application integration
• Professional DotNetNuke support

ExpertsFromIndia can provide everything from module planning to deployment, including training and support; our developers deliver solid web solutions on time and on budget

At Experts From India, we believe in great partnerships that delivers great results. Determining your business goals can help us not only in choosing the right application for you but also in delivering effective expertise.

Request a free quote to know more about customization and development of DotNetNuke.

DotNetNuke (DNN) Benefits	Sharepoint 2007 Benefits
Anyone in your company can edit content anywhere anytime	Content Management for Web Content, Records and Documents
Used by 250,000+ organisations worldwide	Powerful Workflow, Security and Content Policies
Easy to Deploy & Customise	Source & Version Control
Built on ASP.NET and SQL Server	Enterprise Search
Large number of 3rd party modules	Built on ASP.NET and SQL Server

Hire DotNetNuke Developers

Experts From India offers you excellent services one of that is hire DotNetNuke developer. Our dedicated DotNetNuke developers are experts to provide you complete solution to your DotNetNuke application related services and needs. They are always at your service ensuring that your job will be done in time with the finest accuracy and available for urgent needs like patching or restoring your system after a crash. We look forward to assist you at anytime.

Cost to Hire Dedicated DotNetNuke developer

Our DotNetNuke developers/programmers are higly skilled with years of hands on experience. Their area of expertise includes ecommerce-shopping cart, dynamic website development, database management, project management, security and more. They are proficient in PHP, MySQL, JavaScript, VBScript, XML. A highly skiiled and experienced DotNetNuke developer cost you Starting From $5.0 Per Hour. For more details on DotNetNuke Dedicated developers pricing, Request a free Quote.

DotNetNuke Programmer Working Time

Experts From India’s Experts DotNetNuke Developers / Programmers works dedicatedly for you, 10 hours a day, 6 days a week. DotNetNuke Dedicated programmers will work under your timeframe and you can contact through MSN/Skype. In urgent case, you can directly call on developers mobile also. Experts From India always give 200% to clients with best solutions.

How DotNetNuke Developers/Programmers Works

After finalizing the DotNetNuke developers and project specification, your assigned DotNetNuke developer(s) can start ready to work within 24 hours.You can contact with your allocated DotNetNuke developer(s) through instant messenger and email.

Monitor Work:

• Monitor project undertaken by your assigned DotNetNuke developer(s).
• Project timetable and the outcome you expect from DotNetNuke programmer(s)
• Follow-ups of development process for confirmation of project staying on right way
• Interact hired DotNetNuke programmer(s) directly.
• Experts From India’s management provides supervision to your developer(s)
• Your offshore dedicated DotNetNuke developer will give services same as an in-house developer.

Payment Terms: The developer is going to work for you, on monthly contract hiring basis. Mode of payment will be Bank Wire Transfer, Credit Card or Paypal.

Get free Quote for detailed proposal for your DotNetNuke Applicationt.

SOURCE:http://www.expertsfromindia.com/dotnet-nuke-development.htm

How to make money from your DotNetNuke website

There are several ways in which you can monetize your DotNetNuke website. In this article we are going to discuss the methods that are available with the default modules in DotNetNuke.
These methods can be used with any type of website from a static to a dynamic website. The advantage of using DNN is the flexibility and ease of use for configuring and tracking.
Advertising
The first and easiest method for a web master to implement on their website is to enable advertising.

There are several advertising methods that you can implement and we will discuss each of them in turn.

Text/HTML
DotNetNuke provides an easy solution for combining all of the various advertising methods through the use of the Banners module. The Banners module allows you to rotate advertisements on each page load, while also allowing you to track the number of click-throughs for each advertisement.

The banners module can display all of the advertising types that are mentioned below; it is not just limited to displaying banner image advertisements.

You can learn how to use and configure the banners module in this tutorial.
Payment Schemes
Before we discuss the various advertising methods, we need to explain the payment schemes that the advertising methods tend to use.
Pay-Per-Impression
Your payments are based on how many impressions you display an advertisers’ banner for. An impression is a page view of the banner by a visitor to your website. Typically payments are calculated on a Cost-Per-Thousand impressions (CPM) basis ie. $5 CPM refers to $5 for 1000 displays of the banner. The higher the traffic on your website the more impressions you can generate and therefore the more advertisers you can display and create more income.

On very high traffic websites some webmasters use a pay per month method where you pay a set amount to advertise on the website for the month with a guaranteed minimum number of impressions.
Pay-Per-Click
You receive a payment each time an advertisement is clicked on. Payments for this can vary from a few cents to several dollars per click. The payment level depends on the niche and the consumer demand for the niche. Other factors that you need to take into consideration are your conversion level ie. How many times is an advertisement displayed before it receives a click? If you can generate a high CTR (Click-Through-Rate) and a high level of traffic you can generate a good source of income even from low paying pay-per-click advertisements.
Pay-Per-Lead
Here you receive a payment for any leads you send to the advertiser. The visitor to the advertisers’ website may have to supply their email address and sign up to an email newsletter before you receive a payment.

You need to bear in mind that this may involve two steps. The first is the conversion of the visitor clicking on the advertisement on your website and the second is the conversion of the visitor on the advertisers’ website signing up to the newsletter.

This type of income may receive fewer conversions than pay per click, but the payments per lead tend to be higher, so you can potentially earn a higher income than Pay-Per-Click.
Pay-Per-Sale
Potentially this method has the lowest conversion rate, but if the advertisers are carefully targeted to the niche topic of your website you could receive a large income. An example of this is the affiliate marketers that earn millions each year from selling other peoples products. In this method you only receive a payment when a visitor to your website purchases a product from your advertiser.
Payments
If you are implementing Pay-Per-Impressions advertising you can request payment for the advertisement up front before you allow the advertisement to be displayed on your website. For all of the other methods, payment tends to be held back until you have accumulated on average $100 in clicks / leads / sales. Also make sure that you double check how soon they make a payment after you reach the minimum payment level. Some programmes may wait 30 days until they pay you. This is important to check for the cashflow of your business.
Tip
If there is one tip I can pass on it is this. Test the advertisement method for a month and if it is not making enough money, analyze why:

* Do you need to increase the conversion rate?
* Do you need to increase the traffic?
* Is the advertisement suitable for your niche market?

Several years ago, I learnt a lesson the hard way. In the first year of creating a website directory, all of the advertising was based on the pay per sale method. The traffic on the website was high, the click through rate on the banner ads was good, but the sale conversion was very low (the products were not close enough to my niche). I made less than $100 in a year which I never received because the minimum payment was $100. I then switched to pay-per-click and pay-per-impression and made several hundred dollars in the first month! I realised I had literally lost thousands of dollars over that year from not testing and analyzing the advertising methods.

The DotNetNuke banners module allows you to rotate between ads that use the various payment methods, so you can easily setup and analyse the conversion rate of several advertising methods at once and avoid the mistakes I made.

As a starting point I would suggest that you try each of the payment methods and analyze which ones provide you with the most income for your website.

Note: I have had successes with Pay-Per-Sale; you just need to ensure that the advertisements are very close to your website market niche and that the visitors to your website are willing to buy products.
Advertisement Methods
You have several options available for advertising within your DotNetNuke portal. They can be split into two groups, image based advertisements and text based advertisements.

The DotNetNuke Banners module advantage
The DotNetNuke banners module can display a combination of these different advertisement methods at the same time and rotate between the various advertisements.

For instance if you have an advertising space available on the right hand column of your pages, you could display within the same column, a text ad, a Google Adsense ad and another text ad. With the next refresh of the page this could switch to a skyscraper ad and two text ads. You can learn these advanced configuration techniques in this tutorial.

This has the advantage that the position of the advertisements and the type of advertisement is always changing, which should help to grab the attention of a visitor and avoid 'ad blindness.'

Email Newsletter advertisements
If you send a regular newsletter, you could include advertisements within the email. But, make sure that your recipients have opted-in to the email as they could become very annoyed if you send emails trying to sell them products. Here you can learn about the Email Newsletters module.
Programmes
We have covered the various payment methods and advertising methods, the next step is to find advertisers for your website and this is actually not as hard as it may sound.
DIY - Do It Yourself
Probably the first advertising method to appear on the internet and the hardest if you are just launching your website. This involves approaching companies that provide products or services that complement the niche of your website. In most cases you will need to provide a PDF document outlining the cost structure for advertising, the niche market, and the number of visitors / page views you receive on average each month for your website.

Make sure you include a ‘Terms of Use’ document in-case any problems occur with the advertiser and also create a page within your website informing visitors that you offer advertising. (You could combine this with a banner advertisement that states ‘Would you like to advertise here?’).

If your website is already established with a high amount of traffic, you may find that advertisers contact you to advertise on your website.

Payment method: Pay-Per-Impression and Pay-Per-Month are typical for this type of advertising.

Advertising method: All banner types, text advertisements and even email newsletter advertisements are suitable for the DIY approach. You can charge varying amounts for the banner types and position of the banner on the page.
Advertisements for content
This is one of the popular and easiest methods for creating an income from your website. It also requires no maintenance as everything is automated.

The most popular programme for this is Google Adsense. All you have to do is sign up to Google Adsense and add the short Javascript code to your DotNetNuke Banners module.

This will display advertisements directly related to the content of your page meaning you have very specific advertisements related to the niche topic of your website.

Payment method: Pay-Per-Click

Advertising method: Text ads are mainly used, but banner image ads can also be displayed. You have the option for configuring the layout of the text ads into various banner sizes.

I would recommend you view An Introduction to Google Adsense followed by this video tutorial, which walks you through how to incorporate Adsense with DotNetNuke. This is recommended over just using the Banners module for displaying Google Ads to increase your click-through-rate and profits.

Here is a selection of programmes that are worth experimenting with:

BidVertiser

Yahoo Network
Affiliate advertising
Here you operate as an affiliate to another company. In most cases you register with the company as an affiliate through their website. Some affiliate programmes require that you have a website and sometimes a minimum amount of traffic. The company will decide whether or not to approve or reject your application as an affiliate; generally this is based on the content of your website. Once approved, you will have access to the affiliates section of their website which will provide you with:

Your affiliate id – Place this id in the advertisement URL link. This id is used to track the click-throughs from your website.

Advertisements – Banner ads, Text ads, Email content etc. If it is a good affiliate programme they should supply you with a large selection of advertising content to choose from. You can place these advertisements in the DotNetNuke Banners module along with your affiliate link.

Tracking Reports and Stats – A good affiliate programme will allow you to view the number of click-throughs / conversions / sales / leads that you have made along with the amount of money you have earned.

Extras – Support, tips, help, forum, pricing structure benefits for users that generate a high number of sales etc. All of these help to provide a good affiliate programme.

Payment method: Usually Cost-Per-Sale and Cost-Per-Lead, some programmes will provide Cost-Per-Click.

Advertising method: All methods can be used, image, text and email advertisements. You can also incorporate links to affiliate programmes directly within the content of your website. For instance, if you are writing a book review, you could include an affiliate link to amazon.com for the visitor of your website to buy the book.