Ashok's profileAshok's Blog SpacePhotosBlogListsMore  |  Tools Help |
Ashok's Blog SpaceAshok's Blog Space |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Saw them and Liked
Things I'm doing / working now
Reading through
Interest / Preferences
I read them
|
October 28 Some FAQs Collected On Smart Documents (Microsoft) Technology
October 05 The Role of Architecture in Business AnalysisMichael Rosen May 2007 Summary: Understand the architecturally significant aspects of business analysis on which a project architect should focus. (6 printed pages) ContentsIntroduction IntroductionImagine yourself on an assignment at Northwinds, an options-trading company. They have brought in your team to help upgrade the critical applications used day in and day out by the traders. As new kinds of options and other financial instruments are created, the old, inflexible applications are breaking under the pressure for change and integration. Today is an important day, and your trepidation peaks as you pull into an empty spot in the parking lot. As you look around, you notice that your car is the cheapest vehicle in the lot, which is dominated by BMWs, Porches, Jaguars, and the occasional Bentley. These guys make a lot of money, and they don't have a lot of time or patience for "theory," "architecture," or excuses. Still, you know that, to meet the new regulatory and conformance requirements, and to achieve the goals of common processing and reporting, you will need to have both a business model and a technical architecture. The business model defines the processes and entities of the business, and identifies what must be common to meet the new system requirements. The technical architecture will define patterns for implementing the business on a common technology platform. It will have to support the business architecture; but, on the Northwind project, the business model—not technology—is your focus and responsibility. Northwinds Trading Gets a Business ModelToday is the day of the first "business-modeling" session. It will be attended by the IT group's business analysts, as well as by a few senior traders forced to attend. You kick off the meeting with an overview of the goals and a brief introduction to what a business model will look like. A prepared poster on the wall acts as a key to three concepts that will be used in the exercise; and, quickly—before any eyes can glaze over—you jump right into creating the first model on the whiteboard. At first, the model seems to be obvious and simple, as you illustrate the basic modeling concepts. But, based on upfront preparation, you start to dig into the details with some careful prodding and questioning. Pretty soon, you hit pay dirt. Two of the senior traders are arguing over what something means or the way it works. As you facilitate a discussion to get to a common understanding, you model the solution on the whiteboard—essentially, documenting the agreement. When the main details are worked out, it's time for a coffee break and to reiterate what has been accomplished over some casual conversation. After the session, you transcribe the whiteboard contents into formal models in an appropriate tool. So, what has been accomplished? It's much more important than the simple start of a business model. You have demonstrated two critical values of the business models themselves. First, you have exposed the fact that, although the experienced and senior people might have thought they knew how things worked, at best, they discovered that they had differing conceptions. Secondly, you have shown how a simple and easy-to-understand—but formal—model can document the business unambiguously. Over the next few weeks, the modeling sessions increase to two mornings a week, in order to meet the deadline and expanded scope. Before each meeting, you publish the models from the previous meeting. Over time, you introduce two or three more important model concepts (with updated posters). Another interesting thing happens. More senior traders begin to participate—both to learn and to make sure that their understanding of the business gets represented in the model. People who make $500,000+ per year and have no patience for technology are willingly attending your business analysis and modeling sessions! Fantasy? Other than the fictitious name, this is exactly what happened on my project with an options-trading company. The activity not only produced definitive models of their business, but it also provided the project team with the information and process models they needed to understand the requirements for this and future projects and optimize their implementations. How did we make that happen?
What Is Business Analysis?So, what is business analysis (BA), and how does it relate to the job of an architect? According to the International Institute of Business Analysis [IIBA 2006]: "A business analyst works as a liaison among stakeholders in order to elicit, analyze, communicate, and validate requirements for changes to business processes, policies, and information systems. The business analyst understands business problems and opportunities in the context of the requirements and recommends solutions that enable the organization to achieve its goals." In other words, the business analyst acts as a bridge to convey requirements between the business customers and the project-development team. However, the architect is not the same as the business analyst. The architect has a different set of goals and responsibilities. Architecture is not about building a single application, but instead about establishing commonality, such as technology platforms, business entities (like customer), and business processes (like compliance) across multiple applications that are part of a bigger picture. Like the business analyst, the architect acts as a bridge to the individual projects. Those who are tasked with an individual project cannot be expected to know or care about the bigger picture. Instead, the architect has to help the project team and business analyst incorporate the big picture into the current project-analysis activities. Wikipedia [WIKI 2006] has this to say: "Business analysis, as a discipline, has a heavy overlap with requirements analysis, but focuses on identifying requirements in the context of helping organizations to achieve strategic goals...". While both BA and architecture are about achieving strategic goals, BA is more focused on the identification and specification of requirements within that strategic context, while architecture is more focused on identifying and specifying those things that must be common across applications to achieve the business and enterprise goals. Obviously, there is overlap, and architecture must work closely with BA in integrating the enterprise requirements into its understanding of the business as a whole. This will call on the architect's ability to talk about technology concerns in a business context. The business analyst and architect also intersect in the areas of analysis, documentation, and communication of the requirements. Here, architects can bring their analytical skills to bear in applying separation of concerns, abstraction, and identification of roles and responsibilities to create formal, unambiguous, and implementable models of the requirements. A business analyst is responsible for creating a business model that conveys the business requirements. Unfortunately, there is not really a universal definition of what a business model is. Some business models include goals, organization, key performance indicators, and other high-level concepts. Other models include value chains and business-context diagrams. Yet others contain use-case, business-process, and business-entity or information models. The higher-level models are important for setting the overall enterprise context and are often created by business architects, while business analysis is more project-focused and often produces the last set of models mentioned earlier. We sometimes call this set of artifacts a domain model. For example, the Rational Unified Process [RUP 2001] states: "A domain model provides 'the big picture' of a complex organization. It shows the major business entities, their functional responsibilities, and the relationships among the entities." The architect has two important contributions to the business or domain model. First, the architect acts as a bridge between the enterprise requirements and the project-specific business requirements. Secondly, they formalize requirements into business models. The exact format of the business model is less important than what it achieves: the specification of business and enterprise requirements, independent of implementation technologies. The attributes that make for good requirements [McEwan 2004] apply also to good business models. Some important attributes of a good business model are that they are:
The models that we created at Northwinds provided an unambiguous definition of the options-trading business at that company. They were complete in specifying all of the information that needed to be identified and shared to meet the business and enterprise requirements, but they were not overly detailed. We assured consistency and traceability through our analysis process that produced the models and kept them free of implementation detail. Then, we worked with the development team to help them use the models in their development activities. Although the underlying technologies and applications have changed several times since the original project six years ago, the business models are still in use today and are still providing value. Our team of architects and business analysts worked together with the customer's subject-matter experts to produce the models. The business analysts provided the business knowledge and primary interface with the customer, and the architects provided the critical-thinking and formal-modeling skills necessary to produce the models and to interpret them for implementation across multiple projects. Never forget that an architect's job is not to create architecture, but instead to help development use the architecture to create better applications that fit within a larger context. ReviewBusiness analysis is the elicitation, collection, and specification of requirements. It is a critical component of the success of any project. Although the business analysts should be putting those requirements into a strategic context, their primary responsibility is for the project. The architect, on the other hand, is responsible for thinking across projects and interjecting enterprise requirements into the business-analysis activities—that is, acting as a bridge between enterprise and project concerns. In addition, an architect can help to better express requirements, in terms of formal models that can be unambiguously implemented by the project-development team. Critical-Thinking QuestionsWhen involved in business analysis and development of a business model, the architect should keep a few critical questions in mind.
Sources
GlossaryAbstraction—Generalization of content and/or suppression of unrelated detail to allow for a broader view, reduce complexity, or focus on a specific viewpoint. Business analysis—Elicitation, collection, and specification of requirements to meet business, project, and strategic goals. Business model—Defines the processes and entities of the business, and identifies what must be common to meet the new system requirements. Domain model—Provides "the big picture" of a complex organization. Shows the major business entities, their functional responsibilities, and the relationships among the entities. Separation of concerns—One of the most fundamental principles of architecture. Identifying and keeping independent things uncoupled and independent, so that changes in one do not affect the other adversely. About the author Mike Rosen has 25 years of software experience as a developer, product architect, application architect, and enterprise architect. He is a practicing architecture consultant, speaker, and author, as well as Director of Enterprise Architecture for the Cutter Consortium and Co-chair and Editorial Director of SOA Institute. This article was published in Skyscrapr, an online resource provided by Microsoft. To learn more about architecture and the architectural perspective, please visit skyscrapr.net. Source: http://msdn2.microsoft.com/en-us/architecture/bb508953.aspx September 20 Impressing OthersIs it a biological or psycho behavior of human being? How much of it is required in our life? Does it have any moral value? How much of importance this carries in ones life? Especially, do I need to convince a foreigner who might be related officially or personally or as a senior or that said in any other way? Many queries like this disturb me sometime. This I have felt after coming across few good people like this since past and no doubt in the recent past. Hence, thought of dropping two lines of my conflict thought about it.
I have seen few persons trying their level best to impress somebody (again it could be a senior or friend or a girl friend or a foreigner or somebody like this…). I just do not understand why it is required to impress somebody and how much of it is required and up to what extent we need to go ahead just to get some benefits like some appreciation / compliments / promotion or some best recognition. If there is something which need to be noticed by somebody (whom we think to impress) then it needs to have that much of value and importance by itself. So that the opponents can recognize it and give you what you want. We need not to impress somebody intentionally. Intentionally impressing somebody sounds like asking/expecting your own respect from others forcefully. This is not the way to get a good return for some well doings. If we have really done something great or good then it needs to be recognized by others in its own course of time span. May be you could demand the return for your own good doing (which again is only good as per yourself) forcefully but it really does not have that much of importance or great feeling for yourself. Getting your own choice delicious food without asking has a different taste then getting it prepared by yourself or asking for it. So the moral of the story is I’ve seen few people showing off what they have done irrespective of anybody asking for it. They just want to show it intentionally and expect an appreciation for it which really does not make them happy in real life. Always their hunger increases for the real appreciation which they do not allow to come to them. It’s like we teaching or ordering our younger to respect us.
There is another incident in our real life. When a discussion happens or something is expected by our own family members from us, and assume we are against of it or may not like then the approach we do with our family members. In many of the cases we just either sought or show anger to the beloved one in some the other way that is we tell them that we are against for it in anger mood. But if we see it in places like our office colleagues or friend circle or this could be with our girl friend then we approach it in different way. Either politely or a friendlier way or in a sweeter way. But we do not do the same thing with our regular family members or who are always there for our life. So is this not a show off? Is this not like impressing somebody artificially? If yes, then why do we do this? Is this a psycho behavior of human being or the selfish nature which is blossoming? Or could we consider this to be a biological behavior of human being?
If there is something good we are doing then it need to be and will be recognized by some people if not by all people and again in a time of span. If this is not getting recognized then somewhere, something could be wrong. We might need to be patient for this to happen and do some course correction. Always and everywhere selling ourselves may not be the right approach. Doing a good job itself should be enough to satisfy own, it could be then in any way like my own profession job or some social work or some stuff. This by itself is good moral and a good job which gives more satisfaction then getting from anybody else. But expecting always a better return for something good endeavor is not the good way of doing. Again expecting a good return for our investment may not be a bad thing. I do not understand how to judge on this. So both has got own pros and cons. If this is to be a psycho behavior then we might need to change it or if it’s a biological behavior then god knows what to do with it?
At the end but not the last, I’m not expecting any comments for it or against it. I’m sure different people will have different thoughts about it. This is just to put my thoughts in terms of some words so that I can understand myself better. July 31 Asset Under Management And Hedge FundWhat is Asset Under Management (AUM)?
What is a Hedge Fund?
What is Stock Split?
May 07 .NET Remoting Vs Web Services.NET Remoting versus Web Services With the advent of .NET and the .NET Framework, Microsoft introduced a set of new technologies in the form of Web services and .NET remoting. .NET remoting and ASP.NET Web services are powerful technologies that provide a suitable framework for developing distributed applications. It is important to understand how both technologies work and then choose the one that is right for your application. The Web services technology enables cross-platform integration by using HTTP, XML and SOAP for communication thereby enabling true business-to-business application integrations across firewalls. Because Web services rely on industry standards to expose application functionality on the Internet, they are independent of programming language, platform and device. Remoting is .a technology that allows programs and software components to interact across application domains, processes, and machine boundaries. This enables your applications to take advantage of remote resources in a networked environment. Both Web services and remoting support developing distributed applications and application integration, but you need to consider how they differ before choosing one implementation over the other. In this article, I will show the differences between these two technologies. I will present samples for each type of implementation and identify when to use which technology.
A Look at .NET Remoting.NET Remoting uses a flexible and extremely extensible architecture. Remoting uses the .NET concept of an Application Domain (AppDomain) to determine its activity. An AppDomain is an abstract construct for ensuring isolation of data and code, but not having to rely on operating system specific concepts such as processes or threads. A process can contain multiple AppDomains but one AppDomain can only exist in exactly one process. If a call from program logic crosses an AppDomain boundary then .NET Remoting will come into place. An object is considered local if it resides in the same AppDomain as the caller. If the object is not in the same AppDomain as the caller, then it is considered remote. In .NET remoting, the remote object is implemented in a class that derives from System.MarshalByRefObject. The MarshalByRefObject class provides the core foundation for enabling remote access of objects across application domains. A remote object is confined to the application domain where it is created. In .NET remoting, a client doesn't call the methods directly; instead a proxy object is used to invoke methods on the remote object. Every public method that we define in the remote object class is available to be called from clients. When a client calls the remote method, the proxy receives the call, encodes the message using an appropriate formatter, then sends the call over the channel to the server process. A listening channel on the server AppDomain picks up the request and forwards it to the server remoting system, which locates and invokes the methods on the requested object. Once the execution is completed, the process is reversed and the results are returned back to the client. Out of the box, the remoting framework comes with two formatters: the binary and SOAP formatters. The binary formatter is extremely fast, and encodes method calls in a proprietary, binary format. The SOAP formatter is slower, but it allows developers to encode the remote messages in a SOAP format. If neither formatter fits your needs, developers are free to write their own and plug it in as a replacement. Different Types of Remote ObjectsThe remoting infrastructure allows you to create two distinct types of remote objects.
A Look at ASP.NET Web ServicesWith the arrival of .NET, creating an ASP.NET Web service is a breezy experience with the .NET framework taking away all the complexities in creating and consuming Web services. To create a Web service, all you need to do is create a Web service class that derives from the System.Web.Services.WebService class and decorate the methods (that you want to expose as Web services) with the WebMethod attribute. Once this is done, these methods can be invoked by sending HTTP requests using SOAP. Consuming a Web service is very straightforward too. You can very easily create a proxy class for your Web service using either wsdl.exe utility or the Add Web Reference option in VS.NET. The Web service proxy hides all the network and marshaling plumbing from the application code, so using the Web service looks just like using any other local object. As you can see from the above diagram, the client proxy receives the request from the client, serializes the request into a SOAP request which is then forwarded to the remote Web service. The remote Web service receives the SOAP request, executes the method, and sends the results in the form of a SOAP response to the client proxy, which deserializes the message and forwards the actual results to the client.
ASP.NET Web Services Vs .NET RemotingNow that we have understood the basic concepts of .NET remoting and Web services, let us identify the differences between these two technologies. For this, I present different factors such as performance, state management, etc and then identify which technology to use in what situations. PerformanceIn terms of performance, the .NET remoting plumbing provides the fastest communication when you use the TCP channel and the binary formatter. In the case of Web services, the primary issue is performance. The verbosity of XML can cause SOAP serialization to be many times slower than a binary formatter. Additionally, string manipulation is very slow when compared to processing the individual bits of a binary stream. All data transported across the wire is formatted into a SOAP packet. However if your Web service performs computation intensive operations, you might want to consider using caching to increase the performance of your Web service on the server side. This will increase the scalability of the Web service, which in turn can contribute to the increase in performance of the Web service consumers. A remoting component, using the TCP channel and the binary formatter, provides the greatest performance of any remoting scenario, primarily because the binary formatter is able to serialize and deserialize data much faster. If you use .NET remoting with a SOAP formatter, you will find that the performance provided by ASP.NET Web services is better than the performance provided by NET remoting endpoints that used the SOAP formatter with either the HTTP or the TCP channel. However the .NET remoting provides clear performance advantages over ASP.NET Web services only when you use TCP channels with binary communication. State ManagementWeb services are a stateless programming model, which means each incoming request is handled independently. In addition, each time a client invokes an ASP.NET Web service, a new object is created to service the request. The object is destroyed after the method call completes. To maintain state between requests, you can either use the same techniques used by ASP.NET pages, i.e., the Session and Application objects, or you can implement your own custom solution. However it is important to remember that maintaining state can be costly with Web services as they use extensive memory resources. .NET remoting supports a range of state management options that you can choose from. As mentioned before, SingleCall objects are stateless, Singleton objects can share state for all clients, and client-activated objects maintain state on a per-client basis. Having three types of remote objects (as opposed to one with Web services) during the design phase helps us create more efficient, scalable applications. If you don't need to maintain state, use single-call objects; if you need to maintain state in a small section of code, use single call and singletons together. The ability to mix and match the various object types facilitates creation of solid architectural designs. Security.NET remoting plumbing does not provide out of the box support for securing cross-process invocations. However a .NET remoting object hosted in IIS, can leverage all the same security features provided by IIS. If you are using the TCP channel or the HTTP channel hosted in a container other than IIS, you have to implement authentication, authorization and privacy mechanisms yourself. Since ASP.NET Web services are hosted, by default, in IIS, they benefit from all the security features of IIS such as support for secure communication over the wire using SSL, authentication and authorization services. Reliability.NET remoting gives you the flexibility to host remote objects in any type of application including a Windows Form, a managed Windows Service, a console application or the ASP.NET worker process. If you host your remote objects in a windows service, or a console application, you need to make sure that you provide features such as fault tolerance within your hosting application so that the reliability of the remote object is not compromised. However if you do host remote objects in IIS, then you can take advantage of the fact that the ASP.NET worker process is both auto-starting and thread-safe. In the case of ASP.NET Web services, reliability is not a consideration as they are always hosted in IIS, making it easy for them to take advantage of the capabilities provided by IIS. ExtensibilityBoth the ASP.NET Web services and the .NET remoting infrastructures are extensible. You can filter inbound and outbound messages, control aspects of type marshaling and metadata generation. .NET remoting takes extensibility to the next level allowing you to implement your own formatters and channels. Since ASP.NET Web services rely on the System.Xml.Serialization.XmlSerializer class to marshal data to and from SOAP messages at runtime, we can very easily customize the marshaling by adding a set of custom attributes that can be used to control the serialization process. As a result, you have very fine-grained control over the shape of the XML being generated when an object is serialized. Ease of programming and deploymentIn this section, we will consider a simple remoting object and an ASP.NET Web service to understand the complexities involved in creating and consuming them. We will start off by creating a simple remote object. Creating a remote objectCreating a remoting object is a simple process. To create a remote object, you need to inherit from MarshalByRefObject class. The following code shows a remotable class. using System; namespace RemoteClassLib { public class MyRemoteObject : System.MarshalByRefObject { public MyRemoteObject() { Console.WriteLine("Constructor called"); } public string Hello(string name) { Console.WriteLine("Hello Called"); return "Hello " + name; } }} The above code is very simple and straightforward. We start off by defining a class that inherits from MarshalByRefObject. After that we add code to the constructor of the class to write out a message to the console. Then we have a method named Hello that basically takes a string argument and appends that with the string and returns the concatenated value back to the caller. Once the remote object is created, the next step is to create a host application that hosts the remote object. For the purposes of this article, we will create a console application that reads the details of the remote object from its configuration file. using System; using System.Runtime.Remoting; namespace RemoteClassLibServer { class RemoteServer { [STAThread] static void Main(string[] args) { RemotingConfiguration.Configure( "RemoteClassLibServer.exe.config"); Console.WriteLine("Press return to Exit"); Console.ReadLine(); } }} In the main method, we just read the configuration settings from the configuration file using the RemotingConfiguration.Configure method and wait for the client applications to connect to it. The configuration file used by the above hosting application looks like the following. In the configuration file, we specify that we want to expose the remote object using the TCP channel by using the channel element. <?xml version="1.0" encoding="utf-8" ?><configuration> Once the hosting application is started, then client applications can start creating instances of the remote object and invoke its methods. In the next section, we will understand the processes involved in creating an ASP.NET Web service. Creating an ASP.NET Web ServiceAs mentioned before, creating an ASP.NET Web service is pretty easy in VS.NET. Select the ASP.NET Web Service template using Visual Studio.NET New Project dialog box. Enter the name of the project and click OK to create the project. Once the project is created, modify the default service1.asmx file to look like the following. using System; using System.Collections; using System.ComponentModel; using System.Data; using System.Diagnostics; using System.Web; using System.Web.Services; namespace XmlWebServicesExample { public class Service1 : System.Web.Services.WebService { public Service1() {} [WebMethod (EnableSession=true)] public string HelloWorld() { return "Hello World"; } }} As you can see from the above, the Web service class named Service1 is derived from System.Web.Services.WebService. Inheriting from the WebService class is optional and it is used to gain access to common ASP.NET objects like Application, Session, User, and Context. Then we also add a method named HelloWorld that basically returns a simple string back to the callers of the Web service. In the WebMethod attribute of the HelloWorld method, we also specify that we want to enable session state for our ASP.NET Web service by setting the EnableSession attribute to true. Creating the consumer for the ASP.NET Web ServiceYou can consume the Web service by using the Add Web Reference option in VS.NET to create a proxy for the Web service. When you create a Web reference, the VS.NET IDE creates a proxy for you based on the WSDL file published by the Web service. Once the proxy is generated, you can treat the proxy class methods as if they are the actual Web service methods. At runtime, when the proxy class methods are invoked, they will connect to the actual Web service, invoke the Web service method, retrieve the results returned by the Web service and hand it back to the consumers. The following screenshot shows how to use the Add Web Reference option to create a proxy for the Web service. So far, we have seen the steps involved in creating a .NET remoting object and an ASP.NET Web service. As can be seen from the above code, ASP.NET Web services are very easy-to-create. Consuming ASP.NET Web service is also a very simple process due to the excellent Web service support provided by Visual Studio.NET. With .NET remoting, you need to create the remote object first and then write a hosting application (assuming that you are not using IIS) to expose that remote object. You also need to make sure that the information about the remote object is retrieved from the configuration file to allow for extensibility in the future. If you all these factors into consideration, you will agree that .NET remoting objects are complex to develop and deploy. Type FidelityASP.NET Web services favor the XML schema type system, and provide a simple programming model with broad cross-platform reach. .NET remoting favors the runtime type system, and provides a more complex programming model with much more limited reach. This essential difference is the primary factor in determining which technology to use. Putting it all togetherSo far, we have looked at the differences between these two technologies. Let us summarize the difference in a table.
Though both the .NET Remoting infrastructure and ASP.NET Web services can enable cross-process communication, each is designed to benefit a different target audience. ASP.NET Web services provide a simple programming model and a wide reach. .NET Remoting provides a more complex programming model and has a much narrower reach. As explained before, the clear performance advantage provided by TCPChannel-remoting should make you think about using this channel whenever you can afford to do so. If you can create direct TCP connections from your clients to your server and if you need to support only the .NET platform, you should go for this channel. If you are going to go cross-platform or you have the requirement of supporting SOAP via HTTP, you should definitely go for ASP.NET Web services. Combination of .NET Remoting and ASP.NET Web Services in ActionSo far, we have understood how the .NET remoting and ASP.NET Web services technologies differ in implementation. We have also had a detailed look at different factors to understand what technology to choose in what situation. Even though these two technologies are meant for different purposes, there are times where you will be able to use the combination of these technologies in your application. For example, in an application scenario where you are trying to address the needs of both internet and intranet clients, you might consider using both .NET remoting and Web services as shown in the above diagram. For the intranet .NET clients, you can use .NET remoting to enable cross appdomain communication. For the internet clients, you can expose the same functionality as Web services, allowing client applications running in different platforms to take advantage of the Web service. ConclusionBoth the .NET remoting and ASP.NET Web services are powerful technologies that provide a suitable framework for developing distributed applications. It is important to understand how both technologies work and then choose the one that is right for your application. For applications that require interoperability and must function over public networks, Web services are probably the best bet. For those that require communications with other .NET components and where performance is a key priority, .NET Remoting is the best choice. In short, use Web services when you need to send and receive data from different computing platforms, use .NET Remoting when sending and receiving data between .NET applications. In some architectural scenarios, you might also be able to use.NET Remoting in conjunction with ASP.NET Web services and take advantage of the best of both worlds. Download the code from: http://www.developer.com/img/articles/2003/05/06/Thiru/RemoteWeb.zip
About the AuthorThiru Thangarathinam has six years of experience in architecting, designing, developing and implementing applications using Object Oriented Application development methodologies. He also possesses a thorough understanding of software life cycle (design, development and testing). He holds several certifications including MCAD for .NET, MCSD and MCP. Thiru is an expert with ASP.NET, .NET Framework, Visual C# .NET, Visual Basic .NET, ADO.NET, XML Web Services, and .NET Remoting and holds. Thiru has authored numerous books and articles. He can be reached at thiruthangarathinam@yahoo.com. Article Collected from: http://www.developer.com/net/net/article.php/11087_2201701_1
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Send a private message
Tell a friend
Add to My MSN
Add to your network
Sign up for alerts
|
|
