Service Orientation Architecture (SOA)

Service orientation is a business-driven “modeling strategy” that defines the business functionality in terms of loosely coupled autonomous business systems (or services) that exchange information based on messages. The term services is used in many contexts, but in the context of service orientation, a service is based on four fundamental tenets. We’ll discuss these four tenets, originally proposed by the WCF team at Microsoft, in the following sections.

Tenet 1: Boundaries Are Explicit:

Crossing boundaries is an expensive operation because it can constitute various elements such as data marshaling, security, physical location, and so on. Some of the design principles to keep in mind vis-à-vis the first tenet are as follows:

• Know your boundaries: A well-defined and published public interface is the main entry point into the service, and all interactions occur using that. Services should be easy to consume: It should be easy for other developers to consume the service. Also, the service interface should allow the ability to evolve over time without breaking existing consumers of the service.
• Avoid RPC interfaces: Instead, use explicit messages.
• Keep the service surface area small: Provide fewer public interfaces that accept a well-defined message, and respond likewise with a well-defined message. As the number of public interfaces grows, it becomes increasingly difficult to consume and maintain the service.
• Don’t expose implementation details: These should be kept internal; otherwise, it will lead to tight coupling between the consumer and the service.

Tenet 2: Services Are Autonomous:

Services are self-contained and act independently in all aspects such as deploying, versioning, and so on. Any assumptions made to the contrary about the service boundaries will most likely cause the boundaries to change themselves. Services need to be isolated and decoupled to accomplish the goal of making them autonomous.

Tenet 3: Services Share the Schema and Contract, Not the Class:

Services interaction should be using policies, schemas, and behaviors instead of classes, which have traditionally provided most of this functionality. The service contract should contain the message formats (defined using an XML schema), message exchange patterns (MEPs, which are defined in WSDL), any WS-Policy requirements, and any BPEL that may be required. The biggest challenge you face is the stability of the service, once it has been published. It gets difficult to change it then without impacting any of the consumers.
The design principles to keep in mind for the third tenet are as follows:

• Service contracts constituting data, WSDL, and the policy do not change and remain stable.
• Contracts should be as explicit as possible; this will ensure there is no confusion over the intent and use of the service. Additional contracts should be defined for newer versions of the server in the future.
• If breaking service contracts is inescapable, then version the services because this minimizes the ripple to existing consumers of the service.
• Do not expose internal data representation publicly; the public data scheme should be absolute.

Tenet 4: Service Compatibility Is Based on Policy:

At times you will not be able to express all the requirements of service interaction via WSDL alone, which is when you can use policies. Policy expressions essentially separate the structural and semantic compatibility. In other words, they separate “what is communicated” and “how/whom a message is communicated.” A policy assertion identifies a behavior of a policy entity and provides domain-specific semantics. When designing a service, you need to ensure that policy assertions are as explicit as possible regarding service expectations and semantic compatibilities.

Windows Communication Foundation Predefined Bindings

• BasicHttpBinding Maximum interoperability through conformity to the WSBasicProfile 1.1
  
• WSHttpBinding HTTP communication in conformity with WS-* protocols
  
• WSDualHttpBinding Duplex HTTP communication, by which the receiver of an initial message will not reply directly to the initial sender,but may transmit any number of responses over a period
  
• WSFederationBinding HTTP communication, in which access to the resources of a service can be controlled based on credentials issued by an explicitly identified credential provider
  
• NetTcpBinding Secure, reliable, high-performance communication between Windows Communication Foundation software entities across a network
  
• NetNamedPipeBinding Secure, reliable, high-performance communication between Windows Communication Foundation software entities on the same machine
  
• NetMsmqBinding Communication between Windows Communication Foundation software entities via Microsoft Message Queuing (MSMQ)
  
• MsmqIntegrationBinding Communication between a Windows Communication Foundation software entity and another software entity via MSMQ
  
• NetPeerTcpBinding Communication between Windows Communication Foundation software entities via Windows Peer-to-Peer Networking

Professional Web 2.0 Programming Part (3)

Design Principles

Navigation

Another feature of the browsers that most people have become used to is the ability to return to a previously
viewed page. This is no problem in a traditional web site, especially if the site in question is merely a brochure for an organization and there is no information that needs to be retained and transferred
between pages.

Now what should happen when the user clicks Back in an AJAX website?

If you choose to use Ajax techniques, then don’t switch unnecessarily between updating parts of a page with new content this will lead to inconsistencies in how the browser’s navigation buttons behave and the user will become wary.

An example would be a menu page that uses standard links to lead to sub-pages, each of which use Ajax to
implement their own functionality. Within these sub-pages, after partial updates have been used, the only reason to leave the page would be to return to the menu so keep a link to the menu from the current page so the user won't have to press back.

Minimizing Traffic

if you want your application to have maximum reach you need to minimize network traffic.
For applications using Ajax and other Web 2.0 techniques this can be achieved in a number of ways:

- Making requests and responses as terse as possible
- Combining multiple requests into one
- Processing on the server when possible
- Not overusing Ajax and related technique

Keeping Communication Concise

Making requests and responses as terse as possible obviously cuts down on network traffic and there
are a few ways to do this.

XML is not known for its conciseness and can lead to bloated messages.
Three things that influence the size of your messages are choice of names, whether to use elements or
attributes, and indentation

The following code shows a real-life example for XML message meant to represent a user’s shopping basket.
<shoppingBasket>
<userId>1234567890</userId>
<items>
<item>
<sku>abc123</sku>
<quantity>1</quantity>
</item>
<item>
<sku>def456</sku>
<quantity>2</quantity>
</item>
<item>
<sku>ghi789</sku>
<quantity>3</quantity>
</item>
</items>
</shoppingBasket>

The big advantage of this format is that it’s easy for a developer to see what everything means
The downside is the size of the message

so it can be more economical to shorten the names of the elements to something like the following.
<b>
<u>1234567890</u>
<i>
<s>abc123</s>
<q>1</q>
</i>
<i>
<s>def456</s>
<q>2</q>
</i>
<i>
<s>ghi789</s>
<q>3</q>
</i>
</b>

Further savings can be made by using an attribute-centric format such as the following one:
<b u=”1234567890”>
<i s=”abc123” q=”1”/>
<i s=”def456” q=”2”/>
<i s=”ghi789” q=”3”/>
</b>

Many XML developers would argue that reducing the size of documents by using very short names is
poor practice and if size is such a worry then other technologies should be used, either a non-XML format
or some sort of compression

Combining Multiple Requests

Combining multiple requests can also cut down on network traffic. There is an overhead on each request to the server, including details such as content type, the length of the message, and the eventual destination.
By stuffing multiple requests into one request, these header details are only sent once.

A simple example would be a spell-checking service. As a user types into an HTML text area each word could be sent back to the server and checked for the correct spelling, much the same as most modern word processors carry out this task. An alternative would be to wait until the user leaves the text area or, as a
compromise, one sentence at a time could be checked. This sacrifices some user functionality but greatly
reduces the data passed over the network.

Processing on the Server When Possible

Processing on the server is a traditional technique, originally used because clients didn’t have sufficient
processing power, RAM, or large enough local storage. Nowadays a traditional computing device such
as a desktop will have all these essentials, but network issues can still remain.

One common task is that of transforming XML through the use of an XSL transformation. On modern
traditional browsers this can be accomplished client side, but this would involve both the source XML
and the transformation being sent across the network. Transformation server side can eliminate much of
the traffic as well as allowing for clients that don’t have the requisite functionality. The downside of this
is that usability will almost always decrease in the sense that if the user wants a different view of the data, perhaps sorted in a different order, a second trip to the server is needed.

If all the data and the XSLT had been sent to the client originally then subsequent manipulation would have been much quicker. This is the sort of decision that needs to be taken when designing an application; if the user is going to want to see different views of the information it may be better to provide the raw data and the
means to manipulate it despite the fact that the initial download will probably take longer.

A further consideration is that XSLT processing server side is not necessarily going to save bandwidth,
as there is not a direct correlation between the size of the output document and that of the XML input
and its transformation.

Limiting Use of Callbacks
Avoiding excessive use of callbacks is also recommended.
The following list highlights reasons why this is a bad idea:

- Excessive network traffic : not all clients have the luxury of a permanent high-bandwidth connection.
- Too much feedback and information slows down the user
- Removing the ability to correct error
- Spying on the user

 

Prepared by Mai Fouad and Mahmoud Ali

Professional Web 2.0 Programming Part(2)

This part  assumes that you have some familiarity with JavaScript.
In this part  you learn about some crucial features of the language that are often not fully understood
by JavaScript developers, even seasoned ones. Here you will learn what undefined is, when it comes into the picture, and how to test in your program on undefined. You will learn about the differences between the == and === operators, the benefits and limitations of the for-in construct to iterate over objects and arrays, and more

JavaScript 

In addition to string and number, the typeof operator can return boolean, object, function, and undefined

var name = “Homer Simpson”; //string
var age = 39;            // number
alert(typeof name);
alert(typeof age);

 

There is an important difference in JavaScript between a declared variable that has been assigned no
value and a variable that has not been declared. Consider this program:

var answerLifeUniverseEverything; alert(answerLifeUniverseEverything == undefined); // true alert(destiny == undefined); // Error “can’t find variable: destiny”

 

Even though there is a difference between uninitialized and undeclared variables in JavaScript, the
typeof operator will return the same value for both: undefined. For example, the following code will
not produce any error and will output undefined twice:

var answerLifeUniverseEverything; // var destiny; alert(typeof answerLifeUniverseEverything); // “undefined” alert(typeof destiny); // “undefined” alert(typeof window.destiny) alert(window.destiny == undefined)

 

Unsurprisingly, typeof(window.destiny) returns undefined. But will window.destiny ==
undefined return true or generate an error? Considering what you saw earlier, since nobody ever
declared the property destiny, you might think that this will generate an error. It doesn’t: window
.destiny == undefined returns true. This behavior makes sense, however, if you consider that objects
are similar to maps.Looking at objects as maps, it makes sense for window[“destiny”] to return the value undefined; so

window[“destiny”] == undefined simply returns true.

 The === Operator
1) The == operator performs a type conversion if the two operands are not of the same type
2) The === operator always returns false if the two operands are of a different types, and returns
that same boolean value as == if they are of the same type.

var a = 42; var b = “42”; alert(a == b); // true alert(a === b); // false alert(null == undefined); // true alert(null === undefined); // false

 

Iterating with for-in

JavaScript provides a for iterator similar to the one found in the many programming languages with a
syntax inspired from C.

var simpsons = [“Homer”, “Marge”, “Bart”, “Lisa”, “Maggie”]; for (var i = 0; i < simpsons.length; i++) alert(simpsons[i]);

 

You can also use for-in syntax to iterate over arrays. For example, instead of the somewhat cumbersome
for (var i = 0; i < simpsons.length; i++), you can write for (var i in simpsons):

var simpsons = [“Homer”, “Marge”, “Bart”, “Lisa”, “Maggie”]; for (var i in simpsons) alert(simpsons[i]);

 

Function Arguments
Functions cannot be overloaded in JavaScript, which means that the JavaScript engine will never pick a different
version of a function based on the arguments in your function call. It doesn’t even matter whether
the number of arguments declared by the function matches the number of arguments you are passing to
the function. Consider this program, where by mistake a function add is called with three arguments:

function add(a, b) { return a + b; } alert(add(1, 2, 3));

 

The code runs with no error, and the value 3 is displayed The third argument is simply ignored. Now
assume you make another mistake and instead of passing an additional argument, only pass one argument
instead of two:

alert(add(1));

This also runs with no error. The result in this case is NaN (which stands for Not a Number), since you
didn’t provide a second argument, the value of b in the function body is undefined, and adding 1 to
undefined returns NaN.

For example, in the following code, the function add has been rewritten to accept 1, 2, or
3 arguments. Whatever the number of arguments is (1, 2, or 3), it returns the sum of those arguments.

function add(a, b, c) { return a + (b == undefined ? 0 : b) + (c == undefined ? 0 : c); } alert(add(1)); // Result: 1 alert(add(1, 2)); // Result: 3 alert(add(1, 2, 3)); // Result: 6

 

OR for any number of arguments

function add() { var result = 0; for (var i in arguments) result += arguments[i]; return result; } alert(add(1)); // Result: 1 alert(add(1, 2, 3, 4, 5)); // Result: 15 alert(add()); // Result: 0

 

JavaScript Optimizations :
Performance is an issue with any programming language, or system in general. But maybe even more so with JavaScript:

1) JavaScript code is sent as-is from the server to the client: the larger the code, the more time and
bandwidth will be used to download it.

2) JavaScript is interpreted in the browser, not compiled.

3)JavaScript code interacts with the user by modifying the HTML page through the DOM API.
This is a high-level and powerful model for you, the JavaScript developer. But sometimes
behind a simple change you do to the DOM, the page-rendering engine in the browser has to do
a number of complex operations. What can seem like a trivial change to the DOM is often much
more CPU-intensive than you might expect.

Reducing JavaScript Download Time
1) Unless you have different JavaScript for every page, do not put JavaScript directly into the
HTML, but instead link from the HTML to JavaScript files. If you have any JavaScript directly in
your pages, it should not be more than a few lines long.

2) Reduce the number of JavaScript files you include in one page Most likely you are okay if you have 5 included
files or less, and you might want to think about it twice if you have more than, say, 20 included files.

3) Reduce the number of libraries you use. If you use a number of libraries from different sources,
they will tend to duplicate some code

4) A number of libraries distribute two versions of their code: a full and a compact version.

    A) The full version is preferred to read and change the code of the library. It is indented
       and commented to make the code more readable for the developer.

    B) The compact version is preferred for deployment. This version is automatically created
       based on the full version: comments and indentations are removed; often all the code is
       on one line; and sometimes variables that are not exposed outside of the library are
           renamed into very short (and very cryptic) names.

When you deploy your site, make sure you are using the compact version

 

Prepared by:  Mai Fouad  and Mahmoud Ali

Professional Web 2.0 Programming Part (1)

The common trend behind the most successful recent Web applications is an innovative usage and integration
of many different mature technologies. This trend is known under the oft-hyped and controversial term
Web 2.0. Whatever your feelings regarding this term.

This post will give hints about Web 2.0 Programming and will be followed by more posts about the same topic.

--------------------------------------------------------------------------------------------------------------------

XSLT (Extensible Stylesheet Language  Transformation): Used to transform data.

XML (Extensible Markup Language) or XPath  (XML Path Language) : to validate data.

XQuery (XML Query) : To extract data from documents.

XHTML 1.0
While new versions of HTML were adding new features to previous versions, XHTML 1.0 has not been
designed to add features to HTML 4.01 but to reformulate it as an XML application. This makes every
XHTML file an XML document. Contrast this with HTML 4.01, which is an SGML (Standard Generalized Markup Language) application.

You signal that a document is using XHTML 1.1 with the following document type:
<!DOCTYPE
html PUBLIC “-//W3C//DTD XHTML 1.1//EN”
“http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd”>

You signal that a document is using XHTML 1.0 with the following document type:
<!DOCTYPE html
PUBLIC “-//W3C//DTD XHTML 1.0 Transitional//EN”
“http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd”>

Why Use XHTML?
1) XHTML is Easier to Manipulate
XHTML becomes incredibly convenient when you want to
use tools to manipulate the page. As we have seen, HTML is an SGML application whereas XHTML is an
XML application. Because XML is simpler then SGML, it’s easier to write tools that work on XML documents,
rather than SGML documents.

2) XHTML Encourages the Use of CSS
XHTML strongly encourages the separation of style and content.

3) XHTML Works Better on Mobile Devices
XHTML-only browsers to be much simpler, since they don’t have to implement this
complex parsing and error handling logic that is required for HTML.
By authoring your pages with XHTML, you make
them more accessible to mobile devices

Differences from HTML
1)XHTML Is an XML Application
XHTML is an XML application. This means that closing tags can’t be skipped, special
characters need to be escaped, attributes must have values, and those values must be appropriately
quoted

2)Empty Elements
When using empty elements in HTML, you can sometimes just have an opening tag, as in:
<br>
<img src=”/images/logo.png”>

In XML, when an opening tag is present, you also always need a matching tag
<br />
<img src=”/images/logo.png” />

3)IDs and Names
HTML 4 has introduced the id attribute in addition to the name attribute on the elements a, applet,
form, frame, iframe, img, and map. XHTML 1.0 deprecates the name attribute on those elements, and
XHTML 1.1 completely removes the name attribute on those elements.

The Document Object Model

The Document Object Model (DOM) is an object-oriented representation of an HTML or XML document.
The structure of an HTML and XML document is hierarchical
The DOM API is specified in a language-independent manner by the W3C, and mappings are available for most programming languages.

DOM portions of the APIs that are used in most cases.
1) The entry point to the DOM is the document object, available to the JavaScript code as a global
variable. The document object is of type Document and corresponds to the document node

2)From the document object you can recursively navigate through the DOM using attributes
available on all the nodes: firstChild, lastChild, nextSibling, previousSibling,
childNodes, and parentNode. The semantic of those attributes is easily derived from their
name. They all return a node, except childNodes, which returns a node list.

3)getElementById()
and getElementByTagName(). If you have an id attribute on an element in your HTML, you will be able to access that element with getElementById() with that ID as a parameter. The
method getElementByTagName() returns a node list that contains all the nodes with the given
element name.

Note that the element name you pass to the getElementByTagName() method should always be in
lowercase. The method will not work as you might expect in all cases if the name is in uppercase.

4)Element nodes have a tagName property, which returns the element name. Text nodes have a
nodeValue property, which returns the string value of the node.
// This might return “p” or “P”:
document.getElementsByTagName(“p”)[0].tagName
// But this expression will be true on any browser:
document.getElementsByTagName(“p”)[0].tagName.toLowerCase() == “p”

5)A number of methods are available on the document object to create new nodes, in particular
createElement() and createTextNode(). Newly created nodes can be inserted in the DOM
with appendChild(), insertBefore(), and replaceChild(). Existing nodes can be removed
with removeChild(). For example, add a new paragraph with:

unimportantText = document.getElementsByTagName(“p”)[0];
pleaseNote = document.createElement(“p”);
pleaseNote.appendChild(document.createTextNode(“Please note:”));
unimportantText.parentNode.insertBefore(pleaseNote, unimportantText);

 

 

 

Prepared by: Mai Fouad and Mahmoud Ali Ibrahim

Microsoft Expression Web - How to

 

Open an existing website from remote server

To Import an existing website from your web server follow these steps:

1. Run the import wizard from “File-->Import-->Import Site Wizard”
   
2. The following Wizard dialog will appear.
   
   
             Figure 1: Import site Wizard
   
3. Chose your web server type (in our case will be FTP, FTP for both staging server and production servers’ credentials are provided in section four, servers credentials)
   
4. Write the desired website’s FTP (Staging or Production), then enter the username and password.
   
    
       Figure 2: Login into your FTP server
   
5. Set your destination location for the website
    
      Figure 3: Set the destination location
   
6. Click Finish
   
        Figure 4: Finish importing website
   
7. In the right panel the source (FTP server) and the destination (Local) locations will be opened and showing the difference between the two locations, to add all files from the remote server to local click on the “Publish Website” button in the lower panel and select the direction to be “Remote to local”.
   
    
   Figure 5: The source and destination locations
   
8. After the publishing process is over both locations (Server and local) will have the same files with the version
   
           Figure 6: Published Website
   

Open and existing website from local

To start using the Expression Web on your website open the Microsoft Expression Web from “Start --> Microsoft Expression --> Microsoft Expression Web”

From the Expression IDE open your website from “File --> Open Website”

   Figure 7: Open website

When your site is opened the left tree will show the folder structure for the website and the right panel will show the design for the selected file.

                                               Figure 8: Expression IDE

Publishing Changes

The next step after working on the pages is to publish the pages to the staging server / production server; in order to do that follow these steps

1. From the File menu select Publish Site.
   
2. The following dialog will appear.
   
   Figure 8: Remote website properties.
   
3. From the shown tab select the appropriate remote server for you, in our case will be FTP Server.
   
4. Set your ftp website location and directory in the following fields.
   
                           Figure 9: FTP server location
   
5. Select the next tab “Optimize HTML”.
   
          Figure 10: Optimize HTML page.
   
6. From this tab you can set that when publish HTML pages remove all comments, white spaces and the Generated HTML.
   
7. In the last tab you can set what to publish.
   
                  Figure 11: Publishing tab
   
8. You can publish (only changed pages, all pages) also you can set how Expression find the changes.
   
9. After setting the publish settings click the Ok button.
   
10. The right panel will be view the source and destination locations showing the different pages.
    
                                               Figure 12: Publishing website
    
11. You can either publish from local to remote or the reverse, if the publish will be from local to remote select the folder/file from the local tree (the one on the left) then the arrows in the middle will be enabled in the direction from local to remote and from both directions, if the direction from remote server to local the arrow enabled will be in the direction from remote to local and from both sides.
    
                    Figure 13: Publish selected folder/file from local to remote server
    
12. To publish the website (all files and folders) from the bottom panel (Status Panel) set the publishing direction and click in the publish website button.
    
    
                 Figure 14: Publish website.
    

ODBC Error in IIS 7

In ASP classic application that runs on IIS 7 you might face that ODBC error "[Microsoft][ODBC Microsoft Access Driver] Your network access was interrupted. To continue, close the database, and then open it again."

to resolve this error, open the "applicationHost.config" file in "<Windows Folder>\System32\InetSrv\config" and update this key :

<applicationPoolDefaults>
    <processModel identityType="NetworkService" />
</applicationPoolDefaults>

to

<applicationPoolDefaults>
                <processModel identityType="NetworkService" loadUserProfile="false" />
            </applicationPoolDefaults>

 

and this should fix your problem.