Page 1 of 9 Codeproject: Efficiently Exposing Your Data with Minimal
Total Page:16
File Type:pdf, Size:1020Kb
CodeProject: Efficiently exposing your data with minimal effort. Free source code and pr ... Page 1 of 9 6,623,518 members and growing! (20,991 online) Email Password Sign in Join Remember me? Lost your password? Home Articles Quick Answers Message Boards Job Board Catalog Help! Soapbox Web Development » ASP.NET » Samples License: The Code Project Open License (CPOL) C#, XML.NET 3.5, WCF, LINQ, Architect, Dev Efficiently exposing your data with minimal effort Posted: 16 Nov 2009 By V.GNANASEKARAN Views: 1,238 An article on how we can expose our data efficiently with minimal effort by leveraging Microsoft ADO.NET Data Services. Bookmarked: 7 times Advanced Search Articles / Quick Answers Go! Announcements Search Add to IE Search Windows 7 Comp Print Share Discuss Report 11 votes for this article. Win a laptop! Popularity: 4.62 Rating: 4.44 out of 5 1 2 3 4 5 Monthly Competition Download source code - 101 KB ARTICLES Desktop Development Web Development Introduction Ajax and Atlas Applications & Tools For enterprises which have been in business for decades, problems due to silos of applications and data that ASP evolved over the years is a common issue. These issues sometimes become show stoppers when an enterprise is ASP.NET starting a new strategic initiative to revamp its IT portfolio, to float new business models and explore new ASP.NET Controls business opportunities. ATL Server Caching This article is going to discuss possible options available for unification of data silos, and how efficiently an Charts, Graphs and Images enterprise can expose its data with minimal effort by leveraging the recent advancements in technology. Client side scripting Custom Controls Scenarios in age old enterprises HTML / CSS ISAPI Site & Server Management Common key scenarios in enterprises that are in business for decades are: Session State Silverlight Data in silos spread across multiple, intermediate RDBMS systems and legacy data sources like Mainframes, Trace and Logs AS400 etc. User Controls Data duplicated across multiple applications / data sources, and hence lot of synchronization batch jobs. Validation Business exceptions in applications because of non-availability of real time data. View State Different applications adopting different paths to access the same data and hence embedded with the same WAP / WML validation logics / business rules in multiple places - business rules duplicated. Web Security Data in proprietary databases / directories aroused as a result of M&A events. Web Services Applications on heterogeneous platforms consuming data from different types of data sources through Enterprise Systems proprietary protocols. Multimedia Database The scenarios listed are not complete, just cursors. These scenarios become constraints for any new initiative Platforms, Frameworks & that an enterprise wants to start, to remain competitive in business. Libraries Languages Possible solutions usually adopted are unification of data silos, and dismantling the monolithic applications into General Programming services to eliminate duplicated business rules and logics. In some cases, enterprises will take an iterative Graphics / Design journey where they will allow applications that are resulting out of new initiatives to rest aside the existing Development Lifecycle applications with some stop gap arrangements. Even then, unless data silos are unified and made available for General Reading consumption by the applications, problems due to duplicated data will affect the benefits from new applications. Third Party Products Mentor Resources Unification can happen under different levels: at the data source level, or at consumption level. When it happens at data source level, applications can still adopt their own style to consume the data, but all the applications SERVICES should talk to the same source. This style of unification could be more time consuming, and involves effort Product Catalog related to testing, data migration, etc. But it will eliminate synchronization batch routines. This should be the Code-signing Certificates long term goal of any enterprise. Job Board CodeProject VS2008 Addin In case of unification at consumption level, all the applications have to be made to adopt the same style of data FEATURE ZONES consumption. Here, there will not be any effort related to data migration. But all the applications have to be Product Showcase revamped to adopt the one common style/pattern of consumption. Code Signing Resources WhitePapers / Webcasts Unification at consumption level can be a good option based on a good school of thought: "Abstraction". It could ASP.NET Web Hosting be a starting point for a strategic initiative with a goal to achieve unification both at source level and consumption level. The amount of effort involved in this style depends on the number of applications. But the good thing is, it will not encourage applications to adopt different styles of data access mechanisms. This style of unification results in façades over data, which are called "Data Services". Data Services Data Services can be considered in one of the categories in the service taxonomy of an enterprise. They are also called "Entity Services". The dynamics of these services will change based on the context under which they are used. In the scenarios where they are used for Insert / Delete / Update operations, it is the responsibility of the http://www.codeproject.com/KB/aspnet/EfficientlyExposingData.aspx 11/19/2009 CodeProject: Efficiently exposing your data with minimal effort. Free source code and pr ... Page 2 of 9 data service facades to perform any validations / business rules execution. In the context where consumers use them only for "lookup" data or under read-only mode, they have no other responsibility apart from performing initial security checks (authentication alone). Data services can be made available in different formats / modes: SOAP services (Operations), RESTful services (Resources). Here, I used the word "Modes" to mean Operations and Resources. The factors that could decide the format and mode are contexts [read-only data access, data access for IDU (Insert, Delete, and Update operations)], and the type of the customers (which we will see in detail in the coming section). In the scenarios where it involves lots of IDU (Insert, Delete, and Update) operations, since the validation logic will be part of data services, there will not be any duplication as in the case of "unification at data source" level. Hence, maintenance will be comparatively easier. When unification is carried out at data source level, especially in scenarios where data sources are available in both RDBMs like MS SQL Server, Oracle etc., and legacy systems like Mainframes, the application will hold the responsibility of data / rule validation. The more the number of applications, the more duplications and maintenance will become a headache. In case of "Read-only data access", exposing data as RESTful services could be the best option because of the following key benefits: Light weight - RESTful services generate simple, plain old XML output which is lighter than the XML output from SOAP based Web Services. In the case of Web Services, the XML output generated is heavy because of lots of metadata information. Flexibility - It provides flexibility to generate output in different data formats: XML and JSON. JSON is even lighter than plain old XML. In addition, REST has a lot of other benefits. Detailing them here is out of the scope of this article. In the case of the "data access for IDU operations" context, SOAP Web Services will be the best option. If we go for adopting REST style here, we cannot leverage the benefits of advanced Web Service standards (WS-*, i.e., WS-Security, WS-ReliableMessaging, WS- addressing, WS-Coordination etc.) like enlist in transactions, reliable messaging, message level encryption, etc. Data Services Consumers Consumers of data services can be broadly classified as: Consumers that can consume SOAP /RPC Web Services (typical .NET client applications) These includes typical web applications, desktop applications, and Enterprise applications (ERP, CRM etc). Consumers that need to rely on AJAX for responsiveness (AJAX applications) Applications under this category make requests using XMLHTTP and rely completely on the browser's capabilities to execute logic in JavaScript (like ASP.NET AJAX). RIA consumers These are browser plug-in based applications that provide a rich user experience. They can consume SOAP Web Services as well as REST style services, but mostly restricted to asynchronous mode. Silverlight is one such browser plug-in that helps in building RIAs. Based on the type of the client, data services need to be made available in a particular format. For the clients that can consume XML and SOAP, it can be made available as Web Services. In this case, client applications communicate with the Web Services through proxy objects generated in the respective platform based on the Web Services metadata. This is what is generally adopted in many of the enterprises. But for those clients that need to have a responsive UI, they have to rely on AJAX. In such cases, Web Services will not be an appropriate solution. For AJAX clients, the appropriate solution will be consuming the data from RESTful URLs through JavaScript proxy objects. Even in the case of RIAs, especially for data consumption, REST style services are preferred over SOAP Web Services. Nowadays, even applications that are capable of consuming Web Services are switched to consume RESTful URLs because of their advantages over SOAP-RPC. Data on REST The fundamental difference between SOAP /RPC and RESTful is that in SOAP based Web Services, data is exposed as "operations", while in the case of REST, it is exposed as "resources". When data entities are exposed as resources, consumers have the freedom to query it in a way they want, instead of confining to operation signatures. In the communication between the web client and server side service endpoints, a serialization format is required to convert platform specific types to HTTP network packets. In the case of RESTful services, the formats available are XML and JSON.