Search

Monday, December 31, 2007

Service Oriented Architecture

 

The goal for a SOA is a world wide mesh of collaborating services, which are published and available for invocation on the Service Bus. Adopting SOA is essential to deliver the business agility and IT flexibility promised by Web Services. These benefits are delivered not by just viewing service architecture from a technology perspective and the adoption of Web Service protocols, but require the creation of a Service Oriented Environment that is based on the following key principals:

  • Service is the important concept. Web Services are the set of protocols by which Services can be published, discovered and used in a technology neutral, standard form.
  • SOA is not just an architecture of services seen from a technology perspective, but the policies, practices, and frameworks by which we ensure the right services are provided and consumed.
  • With SOA it is critical to implement processes that ensure that there are at least two different and separate processes—for provider and consumer.
  • Rather than leaving developers to discover individual services and put them into context, the Business Service Bus is instead their starting point that guides them to a coherent set that has been assembled for their domain.

A service-oriented architecture is essentially a collection of services. These services communicate with each other. The communication can involve either simple data passing or it could involve two or more services coordinating some activity. Some means of connecting services to each other is needed.

Service-oriented architectures are not a new thing. The first service-oriented architecture for many people in the past was with the use DCOM or Object Request Brokers (ORBs) based on the CORBA specification. For more on DCOM and CORBA.
 
DCOM

DCOM is the acronym for the Distributed Component Object Model, an extension of the Component Object Model (COM). DCOM was introduced in 1996 and is designed for use across multiple network transports, including Internet protocols such as HTTP. DCOM is based on the Open Software Foundation's DCE-RPC spec and will work with both Java applets and ActiveX components through its use of the Component Object Model (COM). It works primarily with Microsoft Windows.

CORBA

CORBA is the acronym for Common Object Request Broker Architecture. It was developed under the auspices of the Object Management Group (OMG). It is middleware. A CORBA-based program from any vendor, on almost any computer, operating system, programming language, and network, can interoperate with a CORBA-based program from the same or another vendor, on almost any other computer, operating system, programming language, and network.

The first service-oriented architecture for many people in the past was with the use of Object Request Brokers (ORBs) based on the CORBA specification. The CORBA specification is responsible for really increasing the awareness of service-oriented architectures. 

Services

If a service-oriented architecture is to be effective, we need a clear understanding of the term service. A service is a function that is well-defined, self-contained, and does not depend on the context or state of other services.

Connections

The technology of WebService is the most likely connection technology of service-oriented architectures. Web services essentially use XML to create a robust connection.

The following figure illustrates a basic service-oriented architecture. It shows a service consumer at the right sending a service request message to a service provider at the left. The service provider returns a response message to the service consumer. The request and subsequent response connections are defined in some way that is understandable to both the service consumer and service provider. A service provider can also be a service consumer. 

Service-oriented architecture

IT departments are managing increasingly complex IT portfolios. Yet as business needs change, these departments must still ensure that their technologies remain aligned with business goals. Failure to do so compromises organizational agility.

The problem for IT departments is typically not insufficient functionality; rather, it is that critical business systems such as customer relationship management (CRM) and enterprise resource planning (ERP) operate in isolation from other critical business systems—despite the fact that business processes often span multiple applications. To obtain an end-to-end view of a complex business process necessitates integration of information and process silos. In the past, this has been accomplished either though time-consuming manual interventions, or through hard-coded solutions that are difficult to maintain.

Service orientation is an approach to organizing distributed IT resources into an integrated solution that breaks down information silos and maximizes business agility. Service orientation modularizes IT resources, creating loosely coupled business processes that integrate information across business systems. Critical to a well-designed service-oriented architecture is producing business process solutions that are relatively free from the constraints of the underlying IT infrastructure, because this enables the greater agility that businesses are seeking.

Service Oriented Architecture (SOA) ultimately enables the delivery of a new generation of dynamic applications (sometimes called composite applications). These applications provide end users with more accurate and comprehensive information and insight into processes, as well as the flexibility to access it in the most suitable form and presentation factor, whether through the Web or through a rich client or mobile device. Dynamic applications are what enable businesses to improve and automate manual tasks, to realize a consistent view of customers and partner relations, and to orchestrate business processes that comply with internal mandates and external regulations. The net result is that these businesses are able to gain the agility necessary for superior marketplace performance.

SOA defined

Service orientation is a means for integrating across diverse systems. Each IT resource, whether an application, system, or trading partner, can be accessed as a service. These capabilities are available through interfaces; complexity arises when service providers differ in their operating system or communication protocols, resulting in inoperability.

Service orientation uses standard protocols and conventional interfaces—usually Web services—to facilitate access to business logic and information among diverse services. Specifically, SOA allows the underlying service capabilities and interfaces to be composed into processes. Each process is itself a service, one that now offers up a new, aggregated capability. Because each new process is exposed through a standardized interface, the underlying implementation of the individual service providers is free to change without impacting how the service is consumed.

Why SOA?

Complex, distributed IT resources are a concern for businesses. Too frequently, the existing IT portfolio does not adequately meet specific business needs, is costly to manage and maintain, and is inflexible in the face of business growth and change. The solution, however, is not to rip and replace systems or applications, nor to completely renovate them, but rather to find a way to leverage existing IT investments so that overall organizational goals are effectively supported.

Service orientation helps to accomplish these goals by making systems more responsive to business needs, simpler to develop, and easier to maintain and manage. Implementing a solution architecture based upon service orientation helps organizations plan ahead for change, rather than responding reactively.

Who does SOA?

Strictly speaking, SOA is done by developers and solution architects. However, stakeholders in a service-oriented solution span a range of roles, and it is critical that their interests not only be taken into account but that they actively drive the design of the SOA solution.

Starting with those interests, the business analyst is concerned with bringing IT investments more in line with the business strategy. For the developer, this means that the SOA solution must map the sources of business information—systems, staff, trading partners—into a unified and comprehensive view such that the business analyst has greater insight into the costs and benefits of various investments.

The chief technology officer (CTO) of the organization will work with developers to ensure that when designing a solution to meet the needs of the business analyst, the integrity of existing IT systems and applications resources are preserved, even as new capabilities are developed.

And the IT manager, concerned with effectively integrating distributed systems such that management is simplified, will work with the developer to ensure that these goals are also met.

Ultimately, the developers and solution architects are concerned with creating dynamic collaborative applications that meet the goals of the various stakeholders. The service orientation approach enables them to do so in a way that meets the needs of the organization as a whole.

What SOA isn't

There are numerous misconceptions about what SOA is—that it is a product that can be purchased (it is not; it is a design philosophy that informs how the solution should be built); that the goal is to build a SOA (it is not; SOA is a means to an end); or that SOA requires a complete technological and business process overhaul (it doesn't; SOA solutions should be incremental and built on current investments).

SOA is also often equated with Web services, and the terms used interchangeably. While it is true that SOA is made easier and more pervasive through the broad adoption of Web services–based standards and protocols, the two are distinct. SOA is an approach to designing systems—in effect the architectural drawings or blueprint—that directs how IT resources will be integrated and which services will be exposed for use. In contrast, Web services is an implementation methodology that uses specific standards and language protocols to execute on a SOA solution.

Before starting a SOA

Before a developer writes a single line of code, it is critical to identify both specific business drivers of the SOA endeavor and the dependencies between the business and the underlying technologies. Neglecting the business context can result in a project in which SOA infrastructure is pursued for its own sake, or where investments are made that do not line up well with the needs and priorities of the business.

Two approaches are commonly pursued for implementing SOA: top-down and bottom-up. Both approaches have possible pitfalls that can prevent success. Many organizations that have attempted to roll out SOA infrastructure through a top-down approach have discovered that when the infrastructure is finally delivered it is out of sync with the needs of the business. Likewise, a bottom-up approach can fail as well, because it can lead to a chaotic implementation of services created without regard to organizational goals.

The "middle-out" approach is a successful hybrid of the two other approaches. Business drivers and strategic vision are first employed to set clear direction and priorities. Based on these, the organization takes multiple iterative steps to build out slices of end-to-end capabilities, with each iteration delivering a new, dynamic application back to the business that is used to create business return. Microsoft has long advocated this "real-world" approach to leveraging service-oriented architectures: The approach is focused on rapid time-to-value, and it delivers business results through iterative, incremental steps that facilitate close alignment of IT resources with changing business conditions.

What is the SOA life cycle?

The core IT assets of any organization include its data, legacy systems, line-of-business applications, packaged applications, and trading partners. Each of these resources is a service provider responsible for producing numerous highly specific outputs, such as inventories and customer data.

Service orientation ties together these disparate and autonomous sources of information, bridging a wide range of operating systems, technologies, and communication protocols. The process by which it does this is an iterative one of creating ("exposing") new services, aggregating ("composing") these services into larger composite applications, and making the outputs available for consumption by the business user.

SOA cycle

Expose

The expose phase of the SOA approach focuses on which services to create from the underlying applications and data. Service creation can be fine-grained (a single service that maps to a single business process) or coarse-grained (multiple services come together to perform a related set of business functions).

The expose phase is also concerned with how the services are implemented. The functionality of underlying IT resources can be made available natively if they already speak Web services, or can be made available as Web services though the use of an adapter.

Compose

Once services are created, they can be combined into more complex services, applications, or cross-functional business processes. Because services exist independently of one another as well as of the underlying IT infrastructure, they can be combined and reused with maximum flexibility. And as business processes evolve, business rules and practices can be adjusted without constraint from the limitations of the underlying applications.

Consume

Once a new application or business process has been created, that functionality must be made available for access (consumption) by either other IT systems or by end users. The goal of the consumption process is to deliver new, dynamic applications that enable increased productivity and enhanced insight into business performance. Users can consume the composed service through a number of avenues, including Web portals, rich clients, Office business applications, and mobile devices.

What are the benefits of SOA?

Service-oriented architecture is, first and foremost, a means of attaining greater business agility from existing IT investments. SOA-based solutions connect systems and thereby automate previously manual information-transfer processes whether the goal is to develop new applications; to connect systems, workgroups, or geographically distributed subsidiaries; or to collaborate with trading partners. At the same time, SOA solutions build in the essential services required to ensure that the appropriate resources are accessed by the appropriate users.

SOA benefits accrue for the organization at two different levels, that of the IT organization and that of the business user; in the end, all benefits add up to a dramatic increase in agility and productivity.

From the IT department's point of view, SOA-based integration simplifies management of distributed resources across multiple platforms, requires less hardware, is more reliable, is standards-based, and is less costly.

From the business point of view, SOA enables development of a new generation of dynamic applications addressing a number of top-level business concerns that are central to growth and competitiveness. SOA solutions promote:

Stronger connections with customers and suppliers. By making dynamic applications and business services available to external customers and suppliers, not only is richer collaboration possible, but also customer/partner satisfaction is increased. SOA unlocks critical supply and demand chain processes—such as outsourcing of specific business tasks—from the constraints of underlying IT architectures, thereby enabling better alignment of processes with organizational strategy.

Enhanced business decision making. By aggregating access to business services and information into a set of dynamic, composite business applications, decision makers gain more accurate and more comprehensive information. They also gain the flexibility to access that information in the form and presentation factor (Web, rich client, mobile device) that meets their needs.

Greater employee productivity. By providing streamlined access to systems and information and enabling business process improvement, businesses can drive greater employee productivity. Employees can focus their energies on addressing the important, value-added processes and on collaborative, semi-structured activities, rather than having to conform to the limitations and restrictions of the underlying IT systems.

 

What are the challenges associated with SOA?

SOA confers obvious business benefits associated with integration and the creation of new services. However, insufficient attention to governance—the management and monitoring of services, their performance and reliability, and especially their security—can cause inefficiencies and disrupt business processes and the end users they support.

As business needs evolve, it is critical to have policies in place that help determine how to prioritize new business processes and services under consideration for implementation, who will be responsible for designing those processes, how they should be implemented, and how the success of the new implementations will be measured. This is especially important given the inherent cross-functional nature of SOA solutions.

Reuse of services, once touted as a primary SOA advantage, is really a byproduct of the approach rather than the goal itself. Reuse is also proving to be more challenging than expected. An existing service may not provide exactly what a different business process requires and so may call for additional work. And designing a service so that it can be reused in the future requires accurately predicting what future needs will be, something notoriously difficult to do.

How can your organization get started with SOA?

1.
Make sure that you have sound business drivers. When an organization struggles to justify their SOA projects, it is almost always because they are trying to "do SOA" rather than address a business need.
2.
Top-down approaches do not work in the real world. Bottom-up approaches are not manageable either. In contrast, organizations that are successful with SOA often adopt a middle-out approach. These organizations all have something in common—they start with clear business challenges and focus on creating business value.
3.
Try to avoid subscribing to the "build it and they will come" approach. Some organizations spend 18 to 30 months building a services infrastructure. When they finally reach the service consumption or user-experience layer, they find that the business needs have changed, rendering the investments a waste of time and money. It is often more practical to partition your usage scenarios into small sets and build out the entire scenario top to bottom, from the data through to the application consuming the services. Partitioning functionality in this manner can help you track changing business needs much more effectively.
4.
Demonstrate value in rapid iterations. Time-to-value is a critical, healthy metric. The "trust-me" approach is not a healthy model for successfully leveraging SOA.
5.
Last, but not least, organizations that have successfully adopted a SOA solution often use a "snowball" approach. How do you build a big snowball? You start with a small snowball. This is probably the most important take-away with respect to leveraging SOA to drive business value.

 

 
Refrences :
 

Saturday, December 29, 2007

SVG & Mobile

mapIt has always surprised me that the mobile industry has not made better use of SVG. On the face of it, SVG is perfectly suited to publishing rich content on mobile devices for a number of reasons:

  • It is a compact way of representing vector graphics
  • SVG graphics (in keeping with the name) can be scaled to arbitrary sizes, removing some of issues with screen dimension proliferation on mobile devices
  • It is an open standard
  • Device support is better than you might think (more on this later)
  • Because SVG is based on XML, many existing XML tools can be used to generate content

This article summarises the capabilities of SVG and how best to take advantage of it for mobile applications. I will not attempt to describe how to build SVG content since there are plenty of good tutorials elsewhere (see References & Links section below).

Description of SVG

First a quick recap on what exactly SVG is all about. From the Wikipedia:

Scalable Vector Graphics (SVG) is an XML specification and file format for describing two-dimensional vector graphics, both static and animated. SVG can be purely declarative or may include scripting. It is an open standard created by the World Wide Web Consortium's SVG Working Group.

So, SVG is essentially an open standard for an XML-based representation of vector graphics. It is the scalable aspect of SVG in particular that makes it so exciting since it means that the same graphic can look equally well on a large PC screen as it does on a small mobile screen, with no modifications whatsoever. The following image from WikiMedia demonstrates the principle perfectly. Bitmap graphics with inherently fixed resolutions don't scale up well; scalable graphics (which have no inherent pixel size) scale up very well indeed.

 

 

Vector graphics (though not SVG in particular) are already used extensively in computing. As an example, most operating system fonts are defined in a vector format so that they can be represented well at widely varying sizes. Flash objects often contain vector images too, since it means that same Flash object can work equally well regardless of browser size or screen resolution.

SVG has all of the advantages of other vector graphic formats with one key difference: it is based on a set of open standards from the W3C.

SVG Versions

SVG currently exists in a couple of different formats.

  • SVG 1.1 became a W3C Recommendation (meaning essentially that it is finalised) in 2001
  • SVG Tiny and SVG Basic (the Mobile SVG Profiles) became W3C Recommendations in 2003
SVG Tiny and Basic are the versions of most interest for mobile, since they have been specifically designed to work well on small devices and devices with limited resources. Of the two, SVG Tiny 1.1 is the version of SVG that is most widely adopted on mobile phones today. The main difference between SVG Tiny and SVG Basic is the lack of scripting and styling support in Tiny (to save memory overhead of maintaining a DOM tree).

Device Support for SVG

The best image format in the world is of no use if no device supports it, however, so it makes sense to survey how well current mobile devices support the standard. The situation is actually better than you might think. The following devices are known to support some variants of SVG:

  • Nokia WebKit browser - included with all recent S60 (Symbian) handsets
  • Most recent SonyEricsson handsets. According to SonyEricsson themselves, the following handsets have some form of support for SVG: F500, K300, K500, K700, S700, Z500, V800, Z800, K510, K530, 550, K600, K610, K750, K770, K790, K800, K810, S500, T650, V600, W200, W300, W550, W580, W600, W610, W660, W700, W710, W800, W810, W830, W850, W880, W900, Z520, Z525, Z530, Z550, Z558, Z610, Z710, K630, K660, K850, V640, W890, W910, Z750
  • Adobe's Flashlite 1.1 and later
  • ... and many others. There is a fairly comprehensive list here: http://svg.org/special/svg_phones


Interestingly, on the desktop browser side, only Firefox 2.x and Opera support SVG natively -- Internet Explorer does not, nor does Safari. Note that Internet Explorer users are not entirely stuck - Adobe have a plug-in viewer available here. If you can see the following image your browser has SVG support.

This leads to a rather interesting situation where handset support for this standard is arguably broader than desktop support (because Internet Explorer still has a huge market share). Furthermore, in my experience, not only is the support on mobile more widespread, it is better also: the mobile browsers all allow the user to zoom & pan the SVG image, where the desktop browsers do not, or at least not as well. The iPhone does not currentlly support SVG, which is a real shame.

SVG Capabilities

The capabilities available with SVG vary quite widely according to which version of the standard you work to. For the purposes of mobile, sticking with SVG Tiny is by far the safest option. Luckily, this version of the standard offers pleny of useful functionality and certainly more than enough for most purposes. The SVG specification divides the relevant functionality into some groups, called modules. 

  • Shape Module - this is the workhorse module of SVG and covers all of the basic drawing primitives that you would expect: circle, ellipse, line, path, polygon, polyline, rect
  • Basic Text Module - this covers just one tag: text. The text attribute allows you to place text chunks in your diagram.
  • Style Module - this allows you to syle SVG elements in much the same way that you style HTML using CSS

In addition to these basic drawing primitives, SVG-T also supports a number of other useful modules that allow you to add interactivity to your diagram. These include the Hyperlinking Module which allows you to add <a> hyperlinks and the Animation Module which allows you to make simple animations.

Rather than trying to cover the process of creating an SVG document from scratch I've linked to some good tutorials below.

Serving SVG to Mobile

Device Recognition

In order to decide whether or not it is appropriate to send SVG content to a phone that is accessing your site, you need some way to check the capabilities of the device. This leeds to the thorny problem of device detection and content adaptation. In my experience, the current de-facto device detection database WURFL has no useful data about devices support for SVG. In fact, many devices that I know to definately support SVG are listed in the WURFL database as not supporting it. The dotMobi Device Atlas product will try to solve this problem but in the meantime this needs to be treated as a special case. In my tjamm.mobi example site, I simply look for User Agent strings that correspond to the Nokia WebKit browser, and certain SonyEricsson phones; otherwise I fall back to a PNG representation of the same image.

Compression

One of the few drawbacks with SVG is that, as with many XML formats, it is very verbose and hence the file sizes tend to be large for even moderately complex images. Given the issues with data charges and slow wireless networks, to use SVG successfully with mobile devices, you really need to use GZIP compression. Thanks to XML's repeated tags, GZIP compression is very successful in reducing the size of SVG documents to an acceptable level. In practice, I found that documents will typically reduce to about 10% of their original size after being GZIPed, though your mileage may very depending on how repetitive your document are. Now that ZLIB compression is part of the HTTP 1.1 standard (Content-Encoding: gzip) most mobile browsers seem to support GZIP encoding. More to the point, the browsers that are advanced enought to support SVG also seem to support GZIP encoding with any trouble.

Most web servers can be configured to automatically compress certain document types on the fly but how to do so is outside the scope of this article. 

Deciding when to use SVG

SVG is not the solution to all problems. There are many cases where an SVG representation is not the best way to serve an image. SVG makes most sense if you want to convey a lot of information in a single image, where you would otherwise have had to use multiple thumbnails linking to different sections of a larger bitmap. SVG also does not make much sense for photo-like images, but makes excellent sense for line-art such as maps, where zooming and panning are especially useful. Also, bear in mind that a GIF or PNG representation of an image will often be much more compact from a byte size point of view than the same thing represented in SVG.

Image Size

While SVG documents are scalable, they are normally served with a starting resolution in mind, to help the renderer decide how big to render them. The dotMobi logo above includes the following line:

  <svg  xmlns="http://www.w3.org/2000/svg" xmlns:xlink=" http://www.w3.org/1999/xlink" 
width
="167pt" height="85pt" viewBox="0 0 167 85" version="1.1">

This controls both the viewing box and the initial rendered size of the diagram.

Embedding SVG in XHTML

SVG documents should be embedded in XHTML/HTML using the <object> tag as follows:

  <object data="img.svg" width="240"  height="250" >explanatory text</object>  

This way, if  the browser does not support the SVG the user will see the "explantory text".

MIME Type

SVG should be served as MIME type 

   image/svg+xml 

Your web server may need to be configured to add this MIME type. 

A Practical Example

In order to test SVG on real devices I created the testbed site tjamm.mobi. This site aggregates some useful information for commuters in Dublin. The main information source on this site is an SVG road map of central Dublin that shows live traffic information for most major routes (the source of this data is a public XML data feed that is derived from about several thousand under-road sensors around the city, updated every minute). The roads are coloured red / orange / green depending on the current flow of traffic, with unknown roads left as grey. 

 

tjamm

 

This application lends itself particularly well to SVG because the information is inherently more useful if it can be zoomed, panned and rotated. This is the same image zoomed in a little (traffic is looking pretty good near dotMobi HQ):

 

zoomed map

 

.. and rotated:

 

map rotated

 

To represent this same information using PNG or JPEG images would have required a number of thumbnails and clicks, each adding a barrier to usability from both a time and data cost point of view. As it stands, the SVG image on this page is about 8Kb (compressed) and represents a very efficient use of mobile bandwidth. The raw SVG image can be viewed at this URL (use View Source in your browser to see the actual SVG source): http://tjamm.mobi/img/traffic.svg

Summary

SVG-T is a very useful tool in the mobile web designers toolbox. Device support is already quite widespread and getting better.  While many older devices don't currently support SVG, the types of device that deliver a good enough mobile web experience that people actually use them are the very devices that do support SVG. So, with some exceptions (Opera Mini and the iPhone) the pioneers, taste-makers and early adopters are reasonably well covered. So go forth and experiment. 

Reference and Links

Monday, December 17, 2007

The problem with InnerHTML

 

Published by Julien Lecomte at 6:24 pm under Web Development

The innerHTML property is extremely popular because it provides a simple way to completely replace the contents of an HTML element. Another way to do that is to use the DOM Level 2 API (removeChild , createElement, appendChild) but using innerHTML is by far the easiest and most efficient way to modify the DOM tree. However, innerHTML has few problems of its own that you need to be aware of:

  • Improper handling of the innerHTML property can enable script-injection attacks on Internet Explorer when the HTML string contains a script tag marked as deffered: <script defer>...<script>
  • Setting innerHTML will destroy existing HTML elements that have event handlers attached to them, potentially creating a memory leak on some browsers.

There are a few other minor drawbacks worth mentioning:

  • You don't get back a reference to the element(s) you just created, forcing you to add code to retrieve those references manually (using the DOM APIs…)
  • You can't set the innerHTML property on all HTML elements on all browsers (for instance, Internet Explorer won't let you set the innerHTML property of a table row element)

I am more concerned with the security and memory issues associated with using the innerHTML property. Obviously, this problem is nothing new, and very bright people have already figured out ways to work around some of these problems.

Douglas Crockford wrote a purge function that takes care of breaking some circular references caused by attaching event handlers to HTML elements, allowing the garbage collector to release all the memory associated with these HTML elements.

Removing the script tags from the HTML string is not as easy as it seems. A regular expression should do the trick, although it's hard to know whether it covers all possible cases. Here is the one I came up with:

/<script[^>]*>((.|[\r\n])*?)<\\?\/script>/ig

Now, let's put these two techniques together in a single setInnerHTML function (Update: Thanks to those who commented on this article. I fixed the errors/holes you mentioned, and also decided to bind the setInnerHTML function to YAHOO.util.Dom)

YAHOO.util.Dom.setInnerHTML  = function (el, html ) {
    el
= YAHOO.util .Dom.get(el);
   
if (!el || typeof html !== 'string') {
       
return null;
   
}

   
// Break circular references.
   
(function (o) {

       
var a = o. attributes, i, l, n, c ;
       
if (a) {
            l
= a.length;
           
for (i = 0 ; i < l; i += 1 ) {
                n
= a[ i].name;
               
if ( typeof o[n] === 'function' ) {
                    o
[n] = null;
               
}
           
}
       
}

        a
= o. childNodes;

       
if (a) {
            l
= a.length;
           
for (i = 0 ; i < l; i += 1 ) {
                c
= o. childNodes[i];

               
// Purge child nodes.
                arguments
.callee(c);

               
// Removes all listeners attached to the element via YUI's addListener.
                YAHOO
.util.Event.purgeElement (c);
           
}
       
}

   
})(el);

   
// Remove scripts from HTML string, and set innerHTML property
    el
.innerHTML = html.replace (/<script[^>]*>((.|[\r\n])*?)<\\?\/ script>/ig, "");

   
// Return a reference to the first child
   
return el.firstChild ;
};

Voila! Let me know if there is anything else that should be part of this function, or if I missed anything obvious in the regular expression.

Update: There are obviously many more ways to inject malicious code in a web page. The setInnerHTML function barely normalizes the <script> tag execution behavior across all A-grade browsers. If you are going to inject HTML code that cannot be trusted, make sure you sanitize it first on the server side. There are many libraries available for this.


Ref: http://www.julienlecomte.net/blog/2007/12/38/

Friday, December 7, 2007

How to Share Session State Between Classic ASP and ASP.NET

How to Share Session State Between Classic ASP and ASP.NET

Billy Yuen
Microsoft Corporation

Summary: Discusses how to share session state between classic ASP and Microsoft ASP.NET using Microsoft .NET Framework classes and the serialization feature of the .NET Framework. Sharing session state allows converting existing ASP applications to ASP.NET applications in stages while running the applications side by side. (12 printed pages)

Download the source code for this article.

Contents

Introduction
Conceptual Overview
ASP.NET Implementation
ASP Implementation
Demo Program
Incorporating the COM Object in an Existing ASP Application
Limitation/Improvement
Conclusion

Introduction

Microsoft® ASP.NET is the latest Microsoft technology for developing Web-based applications. It offers a number of advantages over the classic ASP script technology, including: 1) a better development structure by separating the UI presentation from business logic; 2) its code is fully compiled instead of interpreted as in classic ASP; and 3) its compile feature in conjunction with its caching support means significantly better performance for sites written in ASP.NET over equivalent sites written in classic ASP.

Despite the potential benefit of converting existing ASP applications to ASP.NET, many existing ASP applications are mission critical and complex. The conversion process could be resource intensive and induce additional risk to the existing application. One approach to address these issues is to run the ASP and ASP.NET side by side, and convert one section of the application at a time to ASP.NET. In order to run the new and old application side by side, a mechanism is needed to share the session state between classic ASP and ASP.NET. In this article, I'll discuss how the session state can be shared by using several classes and the serialization feature of the Microsoft® .NET Framework.

Conceptual Overview

Cookies are the most common way for Web applications to identify the user session, and can be used to identify session state for both classic ASP and ASP.NET. Session state information is stored in memory in ASP script and can't be shared with other applications, such as ASP.NET. If the session state is stored in a common format in Microsoft® SQL Server, the session state can be accessible by both classic ASP and ASP.NET.

In this example, a cookie named mySession is used to identify the user session. When a user makes a request to the Web application, the user will be issued a unique cookie to identify the session. On subsequent request, the browser will send the unique cookie back to the server to identify the session. Before the requested Web page is loaded, a custom object will reload the user session data from SQL Server using the unique cookie. The session state is accessible in the Web page through the custom object. After the Web request is finished, the session data will be persisted back to the SQL Server as the request terminates (see Figure 1).

Figure 1. Sample data flow

ASP.NET implementation

In ASP.NET, every Web page derives from the System.Web.UI.Page class. The Page class aggregates an instance of the HttpSession object for session data. In this example, a custom Page class called SessionPage is derived from the System.Web.UI.Page to offer all the same features as the Page class. The only difference with the derived page is that the default HttpSession is overridden with a custom session object. (Using the new modifier for the instance variable, C# allows the derived class to hide members of the base class.)

public class SessionPage : System।Web।UI।Page
{
... public new mySession Session = null; ...
}

The custom session class is responsible for storing the session state in memory using the HybridDictionary object. (HybridDictionary can efficiently handle any number of session elements.) The custom session class will limit the session data type to be string only for interoperability with the classic ASP. (The default HttpSession allows any type of data to be stored in the session, which will not interoperate with the classic ASP.)

[Serializable]
public class mySession
{
private HybridDictionary dic = new HybridDictionary();
public mySession()
{
}
public string this [string name]
{
get
{
return (string)dic[name।ToLower()];
}
set
{
dic[name।ToLower()] = value;
}
}
}

The Page class exposes different events and methods for customization. In particular, the OnInit method is used to set the initialize state of the Page object. If the request does not have the mySession cookie, a new mySession cookie will be issued to the requester. Otherwise, the session data will be retrieved from SQL Server using a custom data access object, SessionPersistence. The dsn and SessionExpiration values are retrieved from the web.config.

override protected void OnInit(EventArgs e)
{
InitializeComponent();
base.OnInit(e);
}
private void InitializeComponent()
{
cookie = this.Request.Cookies[sessionPersistence.SessionID];
if (cookie == null)
{
Session = new mySession();
CreateNewSessionCookie();
IsNewSession = true;
}
else
Session = sessionPersistence.LoadSession( Server.UrlDecode(cookie.Value).ToLower().Trim(), dsn, SessionExpiration );
this.Unload += new EventHandler(this.PersistSession);
}
private void CreateNewSessionCookie()
{
cookie = new HttpCookie(sessionPersistence.SessionID, sessionPersistence.GenerateKey()); this.Response.Cookies.Add(cookie);
}

The SessionPersistence class uses the BinaryFormatter of the Microsoft .NET Framework to serialize and deserialize the session state in binary format for optimal performance. The resulting binary session state data can then be stored in the SQL Server as an image field type.

public mySession LoadSession(string key, string dsn, int SessionExpiration)
{
SqlConnection conn = new SqlConnection(dsn);
SqlCommand LoadCmd = new SqlCommand();
LoadCmd.CommandText = command;
LoadCmd.Connection = conn;
SqlDataReader reader = null;
mySession Session = null;
try
{
LoadCmd.Parameters.Add("@ID", new Guid(key));
conn.Open();
reader = LoadCmd.ExecuteReader();
if (reader.Read())
{
DateTime LastAccessed = reader.GetDateTime(1).AddMinutes(SessionExpiration);
if (LastAccessed >= DateTime.Now)
Session = Deserialize((Byte[])reader["Data"]);
}
}
finally
{
if (reader != null)
reader.Close();
if (conn != null)
conn.Close();
}
return Session;
}
private mySession Deserialize(Byte[] state)
{
if (state == null)
return null;
mySession Session = null;
Stream stream = null;
try
{
stream = new MemoryStream();
stream.Write(state, 0, state.Length);
stream.Position = 0;
IFormatter formatter = new BinaryFormatter();
Session = (mySession)formatter.Deserialize(stream);
}
finally
{
if (stream != null)
stream.Close();
}
return Session;
}

At the end of the request, the Page class Unload event is fired, and an event handler registered with the Unload event will serialize the session data into binary format and save the resulting binary data into SQL Server.

private void PersistSession(Object obj, System.EventArgs arg)
{
sessionPersistence.SaveSession( Server.UrlDecode(cookie.Value).ToLower().Trim(), dsn, Session, IsNewSession);
}
public void SaveSession(string key, string dsn, mySession Session, bool IsNewSession)
{
SqlConnection conn = new SqlConnection(dsn);
SqlCommand SaveCmd = new SqlCommand();
SaveCmd.Connection = conn;
try
{
if (IsNewSession)
SaveCmd.CommandText = InsertStatement;
else SaveCmd.CommandText = UpdateStatement;
SaveCmd.Parameters.Add("@ID", new Guid(key));
SaveCmd.Parameters.Add("@Data", Serialize(Session));
SaveCmd.Parameters.Add("@LastAccessed", DateTime.Now.ToString());
conn.Open();
SaveCmd.ExecuteNonQuery();
}
finally
{
if (conn != null)
conn.Close();
}
}
private Byte[] Serialize(mySession Session)
{
if (Session == null)
return null;
Stream stream = null;
Byte[] state = null;
try
{
IFormatter formatter = new BinaryFormatter();
stream = new MemoryStream();
formatter.Serialize(stream, Session);
state = new Byte[stream.Length];
stream.Position = 0;
stream.Read(state, 0, (int)stream.Length);
stream.Close();
}
finally
{
if (stream != null)
stream.Close();
}
return state;
}

The SessionPage class and its associated classes are packaged in the SessionUtility assembly. In a new ASP.NET project, a reference will be made to the SessionUtility assembly, and every page will derive from the SessionPage instead of from the Page class in order to share session with classic ASP codes. Once the porting is completed, the new application can switch back to use the native HttpSession object by commenting out the Session variable declaration in the SessionPage class to unhide the base HttpSession.

ASP Implementation

The native ASP session can only store session data in memory. In order to store the session data to SQL Server, a custom Microsoft® Visual Basic® 6.0 COM object is written to manage the session state instead of using the native session object. This COM object will be instantiated in the beginning of each Web request and reload the session data from SQL Server. When the ASP script is finished, this object will be terminated and the session state will be persisted back to SQL Server.

The primary purpose of the Visual Basic 6 COM Session object is to provide access to the Microsoft® Internet Information Server intrinsic objects. The Visual Basic 6.0 COM Session object uses the mySession class of SessionUtility assembly to hold the session state, and the SessionPersistence class of SessionUtility to load and save session data with SQL Server. The mySession and SessionPersistence classes are exposed as COM objects using the regasm.exe utility. The regasm.exe utility can register and create a type library for the COM client to consume Framework classes.

The session state information is reloaded during the construction of the object. The constructor (class_initialize) will first retrieve the session cookie, session timeout (SessionTimeOut), and database connection string (SessionDSN) from the Application object, and create an instance of the class mySession to hold the session data. Then the constructor will try to reload the session data from SQL Server with the given cookie. If the SQL Server does not have the session information, or the session has been expired, a new cookie will be issued. If the SQL Sever does return with the session state data, the session state will be stored in the mySession object.

Private Sub Class_Initialize() On Error GoTo ErrHandler:
Const METHOD_NAME As String = "Class_Initialize"
Set mySessionPersistence = New SessionPersistence
Set myObjectContext = GetObjectContext()
mySessionID = ReadSessionID()
myDSNString = GetConnectionDSN()
myTimeOut = GetSessionTimeOut()
myIsNewSession = False
Call
InitContents
Exit
Sub ErrHandler: Err.Raise Err.Number, METHOD_NAME & ":" & Err.Source, Err.Description End Sub Private Sub InitContents() On Error GoTo ErrHandler: Const METHOD_NAME As String = "InitContents" If mySessionID = "" Then Set myContentsEntity = New mySession mySessionID = mySessionPersistence.GenerateKey myIsNewSession = True Else Set myContentsEntity = mySessionPersistence.LoadSession(mySessionID, myDSNString, myTimeOut) End If Exit Sub ErrHandler: Err.Raise Err.Number, METHOD_NAME & ":" & Err.Source, Err.Description End Sub

When the object instance goes out of scope in the script, the destructor (class_terminate) will execute. The destructor will persist the session data using the SessionPersistence.SaveSession() method. If this is a new session, the destructor will also send the new cookie back to the browser.

Private Sub Class_Terminate() On Error GoTo ErrHandler: Const METHOD_NAME As String = "Class_Terminate" Call SetDataForSessionID Exit Sub ErrHandler: Err.Raise Err.Number, METHOD_NAME & ":" & Err.Source, Err.Description End Sub Private Sub SetDataForSessionID() On Error GoTo ErrHandler: Const METHOD_NAME As String = "SetDataForSessionID" Call mySessionPersistence.SaveSession(mySessionID, myDSNString, myContentsEntity, myIsNewSession) If myIsNewSession Then Call WriteSessionID(mySessionID) Set myContentsEntity = Nothing Set myObjectContext = Nothing Set mySessionPersistence = Nothing Exit Sub ErrHandler: Err.Raise Err.Number, METHOD_NAME & ":" & Err.Source, Err.Description End Sub

You can download the source code of ASP.NET SessionUtility project, the COM Session Manager, and the Demo code by clicking the link at the top of the article.

Demo Program

The demo program is designed to increment and display a number. Regardless of which page is loaded, the number will keep incrementing because the number value is stored in SQL Server and is shared between classic ASP and ASP.NET.

Steps to Set Up the Demo Program

  1. Create a new database called SessionDemoDb.
  2. Create the SessState table (osql.exe –E –d SessionDemoDb –i Session.sql).
  3. Create a new virtual directory called Demo.
  4. Turn off ASP Session under the ASP configuration tab.
  5. Copy the web.config, testPage.aspx, Global.asa, testPage.asp, and GlobalInclude.asp to the virtual directory.
  6. Update the DSN string setting in the Global.asa and web.config. The session timeout setting is optional. The default is 20 minutes.
  7. Install the SessionUtility.dll into the Global Assembly Cache (gacutil /i SessionUtility.dll).
  8. Expose the SessionUtility.dll as a COM object using the regasm.exe (regasm.exe SessionUtility.dll /tlb:SessionUtility.tlb).
  9. Copy the SessionManager.dll to a local directory and use regsvr32.exe to register it (regsvr32 SessionManager.dll).
  10. Grant the IUSR_<machine_name> account to have read and execute access to the SessionMgr.dll.

Steps to Run the Demo Program

  1. Start Microsoft® Internet Explorer.
  2. Load the testPage.asp for classic ASP. The number "1" should appear in the Web page.
  3. Click refresh on Internet Explorer to reload the page. The number should be incremented.
  4. Change the URL to testPage.aspx for ASP.NET. The number should keep incrementing.
  5. The same process can be repeated by starting the testPage.aspx page first.

Incorporating the COM Object in an Existing ASP Application

A common practice in developing ASP applications is to include a file in the beginning of each script to share common codes and constants. The best way to incorporate the custom session object is to add the instantiation code in the common include file. The last step is simply to replace all reference to the session object with the custom session variable name.

Limitation/Improvement

This solution will not support an existing ASP application that stores a COM object in the Session object. In this case, a custom marshaler is needed to serialize/deserialize the states in order to use the custom session object. In addition, this solution does not support storing type arrays of the string. With some additional effort, this feature can be implemented by using the Microsoft® Visual Basic® 6.0 Join function to combine all of the array elements into a single string before storing it into session object. The reverse can be done using the Visual Basic 6.0 Split function to split the string back to individual array elements. On the .NET Framework side, the Join and Split methods are members of the String class.

Conclusion

ASP.NET represents a new programming paradigm and architecture, and offers many advantages over classic ASP. Although porting from ASP to ASP.NET is not a simple process, the better programming model and improved performance of ASP.NET will make the conversion process worthwhile. With the exception of storing a COM object in the Session object, the approach described in this article offers a solution that will make the migration process simpler.

Thursday, December 6, 2007

Prototype Developer Notes

Developer Notes for prototype.js

covers version 1.5.0

Table of Contents