How-To Tutorials

Now starting from a working Apache installation, what can Lighttpd offer us? Improved performance for most cases (as in more hits per second) Reduced CPU time and memory usage Improved security Of course, the move to Lighttpd is not a small one, especially if our Apache configuration makes use of its many features. Systems tied into Apache as a module may make the move hard or even impossible without porting the module to a Lighttpd module or moving the functionality into CGI programs, if possible. We can ease the pain by moving in small steps. The following descriptions assume that we have one Apache instance running on one hardware instance. But we can scale the method by repeating it for every hardware instance. When not to migrateBefore we start this journey, we need to know that our hardware and operating systems support Lighttpd, that we have root access (or access to someone who has), and that the system has enough space for another Lighttpd installation (yes, I know, Lighttpd should reduce space concerns, but I have seen Apache installations munching away entire RAID arrays). Probably, this only makes sense if we plan on moving a big percentage of traffic to Lighttpd. We also might make extensive use of Apache module, which means a complete migration would involve finding or writing suitable substitutes for Lighttpd. Adding Lighttpd to the Mix Install Lighttpd on the system that Apache runs on. Find an unused port (refer to a port scanner if needed) to set server.port to. For example, if port 4080 is unused on our system, we would look for server.port in our Lighttpd configuration and change it to: server.port = 4080 If we want to use SSL, we should change all occurrences of the port 443 to another free port, say 4443. We assume our Apache is answering requests on HTTP port 80. Now let's use this Lighttpd instance as a proxy for our Apache by adding the following configuration: server.modules = (#..."mod_proxy",#...)#...proxy.server = ("" => ( # proxy everythinghost => "127.0.0.1" # localhostport => "80")) This tells our Lighttpd to proxy all requests to the server that answers on localhost, port 80, which happens to be our Apache server. Now, when we start our Lighttpd and point our browser to http://localhost:4080/, we should be able to see the same thing that our Apache is returning. What is a proxy?A Proxy stands in front of another object, simulating the object by relaying all requests to it. A proxy can change requests on the fly, filter requests, and so on. In our case, Lighttpd is the web server to the outside, whilst Apache will still get all requests as usual. Excursion: mod_proxy mod_proxy is the module that allows Lighttpd to relay requests to another web server. It is not to be confused with mod_proxy_core (of Lighttpd 1.5.0), which provides a basis for other interfaces such as CGI. Usually, we want to proxy only a specific subset of requests, for example, we might want to proxy requests for Java server pages to a Tomcat server. This could be done with the following proxy directive: proxy.server = (".jsp" => ( host => "127.0.0.1", port => "8080" )# given our tomcat is on port 8080) Thus the tomcat server only serves JSPs, which is what it was built to do, whilst our Lighttpd does the rest. Or we might have another server which we want to include in our Web presence at some given directory: proxy.server = ("/somepath" => ( host => "127.0.0.1", port => "8080" )) Assuming the server is on port 8080, this will do the trick. Now http://localhost/somepath/index.html will be the same as http://localhost:8080/index.html. Reducing Apache Load Note that as most Lighttpd directives, proxy.server can be moved into a selector, thereby reducing its reach. This way, we can reduce the set of files Apache will have to touch in a phased manner. For example, YouTube™ uses Lighttpd to serve the videos. Usually, we want to make Lighttpd serve static files such as images, CSS, and JavaScript, leaving Apache to serve the dynamically generated pages. Now, we have two options: we can either filter the extensions we want Apache to handle, or we can filter the addresses we want Lighttpd to serve without asking Apache. Actually, the first can be done in two ways. Assuming we want to give all addresses ending with .cgi and .php to Apache, we could either use the matching of proxy.server: proxy.server = (".cgi" => ( host = "127.0.0.1", port = "8080" ),".php" => ( host = "127.0.0.1", port = "8080" )) or match by selector: $HTTP['url'] =~ "(.cgi|.php)$" {proxy.server = ( "" => ( host = "127.0.0.1", port = "8080" ) )} The second way also allows negative filtering and filtering by regexp — just use !~ instead of =~. mod_perl, mod_php, and mod_python There are no Lighttpd modules to embed scripting languages into Lighttpd (with the exception of mod_magnet, which embeds Lua) because this is simply not the Lighttpd way of doing things. Instead, we have the CGI, SCGI, and FastCGI interfaces to outsource this work to the respective interpreters. Most mod_perl scripts are easily converted to FastCGI using CGI::Fast. Usually, our mod_perl script will look a lot like the following script: use CGI;my $q = CGI->new;initialize(); # this might need to be done only onceprocess_query($q); # this should be done per requestprint response($q); # this, too Using the easiest way to convert to FastCGI: use CGI:Fast # instead of CGIwhile (my $q = CGI:Fast->new) { # get requests in a while-loopinitialize();process_query($q);print response($q);} If this runs, we may try to put the initialize() call outside of the loop to make our script run even faster than under mod_perl. However, this is just the basic case. There are mod_perl scripts that manipulate the Apache core or use special hooks, so these scripts can get a little more complicated to migrate. Migrating from mod_php to php-fcgi is easier — we do not need to change the scripts, just the configuration. This means that we do not get the benefits of an obvious request loop, but we can work around that by setting some global variables only if they are not already set. The security benefit is obvious. Even for Apache, there are some alternatives to mod_php, which try to provide more security, often with bad performance implications. mod_python can be a little more complicated, because Apache calls out to the python functions directly, converting form fields to function arguments on the fly. If we are lucky, our python scripts could implement the WSGI (Web Server Gateway Interface). In this case, we can just use a WSGI-FastCGI wrapper. Looking on the Web, I already found two: one standalone (http://svn.saddi.com/py-lib/trunk/fcgi.py), and one, a part of the PEAK project (http://peak.telecommunity.com/DevCenter/FrontPage). Otherwise, python usually has excellent support for SCGI. As with mod_perl, there are some internals that have to be moved into the configuration (for example dynamic 404 pages, the directive for this is server.error-handler-405, which can also point to a CGI script). However, for basic scripts, we can use SCGI (either from http://www.mems-exchange.org/software/scgi/ or as a python-only version from http://www.cherokee-project.com/download/pyscgi/). We also need to change import cgi to import scgi and change CGIHandler and CGIServer to SCGIHandler and SCGIServer, respectively.

Nowadays, the most common way to build composite applications based on service-oriented principles is to use the Service-Oriented Architecture, Webservices, and WS-BPEL (Web Services Business Process Execution Language) technologies together. While Web Services is a technology that defines a standard mechanism for exposure and consumption of data and application logic over Internet protocols such as HTTP, WS-BPEL is an orchestration language that is used to define business processes describing Web services' interactions, thus providing a foundation for building SOA solutions based on Web services. So, to build an SOA solution utilizing Web services with WS-BPEL, you have to perform the following steps: Build and then publish Web services to be utilized within an SOA solution Compose the Web services into business flows with WS-BPEL This article gives an overview of the Web services, SOA, and WS-BPEL technologies and how these technologies are interrelated. It also contains references to related documentation and other chapters of the book SOA and WS-BPEL, which discuss the topics touched upon in this introductory article in greater detail. Web Services The Web Services technology provides an efficient way to share application logic across multiple machines running various operating systems and using different development environments. To achieve this, Web Services utilizes the SOAP, WSDL, XML Schema, and some other XML-based technologies, providing a standards-based approach to overcoming the platform and language differences. The following sections give you an overview of these technologies, explaining how they fit into the big picture. Communicating via SOAP In a nutshell, SOAP is a messaging protocol used to transfer application data in XML format over a transport protocol, such as HTTP. Nowadays, Web service applications employ SOAP as a standard protocol for exchanging information in a decentralized, distributed manner. For detailed information about SOAP, you can refer the W3C SOAP Recommendation documents. Links to these documents can be found at http://www.w3.org/TR/soap/. SOAP-based interfaces interact with each other by means of SOAP messages that are specially formatted XML documents used to carry data and metadata. The general structure of a SOAP message is shown below: <SOAP-ENV:Envelope ...> <SOAP_ENV:Header> ... ... </SOAP_ENV:Header> <SOAP_ENV:Body> ... ... </SOAP_ENV:Body> </SOAP-ENV:Envelope ...> As you can see in the previous code snippet, an XML document representing a SOAP message consists of the following elements: An Envelope element wrapping the entire message. A Header element, which is actually optional and may contain subelements carrying metadata associated with the message. A Body element, which contains the payload of the message. This element may contain an optional fault element, which describes an error if it occurs. While SOAP messages may be used in various message exchange scenarios, the most popular one is the request/response pattern, which is normally used when calling a remote function exposed by a Web service. Diagrammatically, the request/response scenario might look like the following figure: As you can see in the above figure, both the service requestor and service provider include the message processing logic required to send/receive and process SOAP messages involved in the request/response scenario used here. If the service requestor is calling a remote function exposed by the service provider, the request message is supposed to carry the values of the parameters passed to the exposed function. After the request message is received, the service provider processes it, extracting the payload (in this case, the parameters passed to the function) from theenvelope. Then, the requested function is invoked, utilizing the parameters specified. Once the function result is ready, the service provider wraps this result in a SOAP envelope and sends it back to the service requestor in the response message. The service requestor in turn extracts the function result from the response message and sends it to the calling code. In Chapter 2 of the book SOA and WS-BPEL, you will learn how to implement service providers andservice requestors with PHP using the PHP SOAP extension. Now that you have a rough idea of how the remote procedure call (RPC) scenario works with SOAP, let's look at an example. Suppose you have a Web service that exposes the getOrderStatus function, taking the number of a purchase order as the parameter and returning the status of that order as the result. It is important to understand that the getOrderStatus function discussed in this example may be implemented in any programming language and run on any platform, provided they allow you to expose this function through SOAP. The fact is that Web services hide the details of underlying logic from their consumers, publicly exposing only their interfaces. In the book SOA and WS-BPEL, you will see a few examples of implementing service underlying logic with PHP. The following figure depicts a scenario where a service requestor invokes the getOrderStatus function exposed as a Web service: The general steps performed at run time are the following: The service requestor sends a SOAP request message containing the number of a purchase order to the service provider. The service provider processes the request message, extracting the PO number from the SOAP envelope. The service provider invokes the getOrderStatus underlying function, passing the extracted PO number as the parameter. The service provider encapsulates the result produced by the getOrderStatus function into a SOAP response message. The service provider sends the SOAP response message back to the requestor. In this example, the SOAP request message sent to the Web service provider might look like the following: <?xml version="1.0" encoding="UTF-8"?> <SOAP-ENV:Envelope > <SOAP-ENV:Body> <SOAP-ENV:getOrderStatus> <body>US-247860</body> </SOAP-ENV:getOrderStatus> </SOAP-ENV:Body> </SOAP-ENV:Envelope> As you can see, the body of the above SOAP message contains the purchase order number passed as the parameter to the getOrderStatus function. The response to this message might look like the following: <?xml version="1.0" encoding="UTF-8"?> <SOAP-ENV:Envelope > <SOAP-ENV:Body> <SOAP-ENV:getOrderStatusResponse> <body>Shipped</body> </SOAP-ENV:getOrderStatusResponse> </SOAP-ENV:Body> </SOAP-ENV:Envelope> The getOrderStatus function may be designed so that it throws a SOAP exception when something goes wrong. For example, an exception may be thrown upon a failure to connect to the database that contains information about the purchase orders placed. A fault message generated by the Web service exposing the getOrderStatus function might look like the following: <?xml version="1.0" encoding="UTF-8"?> <SOAP-ENV:Envelope > <SOAP-ENV:Body> <SOAP-ENV:Fault> <faultcode>SOAP-ENV:Server</faultcode> <faultstring>Failed to determine the order status</faultstring> </SOAP-ENV:Fault> </SOAP-ENV:Body> </SOAP-ENV:Envelope> As you can see, the fault section resides within the body section of the message, and includes two subelements detailing the fault that occurred, namely: faultcode and faultstring. Binding with WSDL Looking through the SOAP request message discussed in the preceding section, you may notice that it carries only the parameter for the getOrderStatus function exposed by the service. The message doesn't actually contain any information about how to get to the service, what remote function is to be invoked, and what that function is to return. Obviously, there must be another document that describes the Web service, providing all this information to consumers of the service. Web Services Description Language (WSDL) provides a mechanism to describe Web services, making them available for external consumption. A WSDL service description is an XML document that defines how to communicate with the Web service, describing the way in which that Web service has to be consumed. For detailed information about WSDL, you can refer to the WebServices Description Language (WSDL) W3C Note available athttp://www.w3.org/TR/wsdl. Actually, a WSDL service description document consists of two parts: logical and physical. The logical part of a WSDL describes the abstract characteristics of a Web service and includes the following sections: types is an optional section in which you can define types for the data being carried, normally using the XSD type system. message contains one or more logical parts representing input and output parameters being used with an operation. operation describes an action performed by the service, specifying input and output messages being used as parameters of the operation. portType establishes an abstract set of operations supported by the service. The physical part of a WSDL describes the concrete characteristics of a Web service and includes the following sections: binding associates a concrete protocol and message format specifications to operations and messages defined within a particular port type established in the logical part of the document. port establishes an endpoint by associating a binding with a concrete network address. service contains one or more port elements representing related endpoints. Turning back to the example discussed in the preceding section, the WSDL description document that describes the Web service exposing the getOrderStatus function might look like the following: <?xml version="1.0" encoding="utf-8"?><definitions name ="poService" targetNamespace="http://localhost/WebServices/ch1/poService"> <message name="getOrderStatusInput"> <part name="body" element="xsd:string"/> </message> <message name="getOrderStatusOutput"> <part name="body" element="xsd:string"/> </message> <portType name="poServicePortType"> <operation name="getOrderStatus"> <input message="tns:getOrderStatusInput"/> <output message="tns:getOrderStatusOutput"/> </operation> </portType> <binding name="poServiceBinding" type="tns:poServicePortType"> <soap:binding style="rpc" transport="http://schemas.xmlsoap.org/soap/http"/> <operation name="getOrderStatus"> <soap:operation soapAction= "http://localhost/WebServices/ch1/getOrderStatus"/> <input> <soap:body use="literal"/> </input> <output> <soap:body use="literal"/> </output> </operation> </binding> <service name="poService"> <port name="poServicePort" binding="tns:poServiceBinding"> <soap:address location= "http://localhost/WebServices/ch1/SOAPserver.php"/> </port> </service></definitions> Let's go through this document in detail to understand the format of a WSDL description document. The definitions element is the root in every WSDL document, wrapping all the WSDL definitions used in the document. Also, it houses the namespaces used within the document: <definitions name ="poService" targetNamespace= "http://localhost/WebServices/ch1/poService"> Next, you define the abstract definitions for the messages to be used for exchanging data. Here is the abstract definition for the message that will be used for carrying the input parameter for the getOrderStatus function: <message name="getOrderStatusInput"> <part name="body" element="xsd:string"/> </message> Here is the abstract definition for the message to be used for sending back the result of the getOrderStatus function: <message name="getOrderStatusOutput"> <part name="body" element="xsd:string"/> </message> Once you have messages defined, you can group them into operations, which in turn are grouped into a service interface. Here is the portType section representing an abstract view of the service interface, which, in this example, supports onlyone operation: <portType name="poServicePortType"> <operation name="getOrderStatus"> <input message="tns:getOrderStatusInput"/> <output message="tns:getOrderStatusOutput"/> </operation> </portType> Now that you have an abstract service interface defined, you can go ahead and specify physical details of the data exchange. In a binding section, you map the abstract service interface defined within a portType section earlier into a concrete format, specifying the concrete protocol for data transmission and message format specifications. In this example, the binding section is used to deploy thegetOrderStatus operation—the only operation supported by the service: <binding name="poServiceBinding" type="tns:poServicePortType"> <soap:binding style="rpc" transport="http://schemas.xmlsoap.org/soap/http"/> <operation name="getOrderStatus"> <soap:operation soapAction= "http://localhost/WebServices/ch1/getOrderStatus"/> <input> <soap:body use="literal"/> </input> <output> <soap:body use="literal"/> </output> </operation> </binding> In the above snippet, you define a SOAP binding of the request-response RPC operation over HTTP and specify the concrete URI indicating the purpose of the SOAP HTTP request. Finally, you use the service element hosting the port element to specify the physical address of the service. <service name="poService"> <port name="poServicePort" binding="tns:poServiceBinding"> <soap:address location= "http://localhost/WebServices/ch1/SOAPServer.php"/> </port> </service> In the above example, the getOrderStatus function exposed as a Web service takes only one input parameter. But what if you need to pass more than one parameter to a Web service? Suppose you modify the getOrderStatus function so that it takes one more parameter, say, poDate specifying the date an order was placed. If so, you have to include a new part element to the message construct describing the logical abstract content of an input message in the WSDL document: <definitions name ="poService" targetNamespace= "http://localhost/WebServices/ch1/poService"> <message name="getOrderStatusInput"> <part name="poNumber" element="xsd:string"/> <part name="poDate" element="xsd:string"/> </message> <message name="getOrderStatusOutput"> <part name="body" element="xsd:string"/> </message> ... </definitions> Now, a SOAP message issued by a service requestor when calling the getOrderStatus remote function would look as follows: <?xml version="1.0" encoding="UTF-8"?> <SOAP-ENV:Envelope > <SOAP-ENV:Body> <SOAP-ENV:getOrderStatus> <poNumber>US-247860</poNumber> <poDate>21-jan-07</poDate> </SOAP-ENV:getOrderStatus> </SOAP-ENV:Body> </SOAP-ENV:Envelope> Using XML Schema Types within WSDL Definitions As you might notice, the WSDL document discussed in the preceding section doesn't contain the types construct. It is OK in this particular example because you don't actually need any custom XML Schema Definition (XSD) types when defining message parts in the WSDL document. Instead, you use the native XSD schema type string. However, in some situations you may find it useful to utilize custom XML Schema types within a WSDL document. You can define custom XSD types within the types construct of a WSDL document and then reference them within message elements. For example, you might define a complex XSD type in the types section of the WSDL document discussed in the previous section and then reference this XSD type when creating the abstract definition of the output message: <?xml version="1.0" encoding="utf-8"?> <definitions name ="poService" targetNamespace= "http://localhost/WebServices/ch1/po.wsdl"> <types> <xsd:schema targetNamespace="http://localhost/WebServices/schema/"> <xsd:element name="poInfo"> <xsd:complexType> <xsd:sequence> <xsd:element name="pono" type="xsd:string" /> <xsd:element name="shippingDate" type="xsd:string" /> <xsd:element name="status" type="xsd:string" /> </xsd:sequence> </xsd:complexType> </xsd:element> </xsd:schema> </types> <message name="getOrderStatusInput"> <part name="poNumber" element="xsd:string"/> <part name="poDate" element="xsd:string"/> </message> <message name="getOrderStatusOutput"> <part name="poStatus" element="xsd1:poInfo"/> </message> ... </definitions> In this example, a response message sent by the service to a service request or mightlook as follows: <SOAP-ENV:Envelope > <SOAP-ENV:Body> <SOAP-ENV:getOrderStatusResponse> <poStatus> <pono>US-247860</pono> <shippingDate>21-jan-07</shippingDate> <status>Shipped</status> </poStatus> </SOAP-ENV:getOrderStatusResponse> </SOAP-ENV:Body> </SOAP-ENV:Envelope> While this example shows how to define custom XML Schema types within the types construct of a WSDL document, you can achieve better reusability by putting XSD type definitions in a single XSD document. Continuing with this example, you might remove the contents of the types construct into a separate file so that it's available, say, at http://localhost/WebServices/schema/po.xsd. The contents of this file should look as follows: <?xml version="1.0"?> <schema targetNamespace="http://localhost/WebServices/schema/" > <element name="poInfo"> <complexType> <sequence> <element name="pono" type="string" /> <element name="shippingDate" type="string" /> <element name="status" type="string" /> </sequence> </complexType> </element> </schema> </schema> With that done, you can make use of the import statement in the WSDL documentin order to associate the namespace representing the custom XSD schema with the location of the above document, thus making the contents of the schema available within the WSDL document: <?xml version="1.0" encoding="utf-8"?> <definitions name ="poService" targetNamespace= "http://localhost/WebServices/ch1/po.wsdl"> <import namespace="http://localhost/WebServices/schema/" location="http://localhost/WebServices/schema/po.xsd"/> <message name="getOrderStatusInput"> <part name="poNumber" element="xsd:string"/> <part name="poDate" element="xsd:string"/> </message> <message name="getOrderStatusOutput"> <part name="poStatus" element="xsd1:poInfo"/> </message> ... </definitions> As you no doubt have realized, having XSD type definitions in separate files allows you to build more flexible, reusable, and modular solutions. In Chapter 3 of the book SOA and WS-BPEL, you will see how the XSD documents referenced in WSDL can be then reused by an Oracle database holding and processing SOAPmessages data.

The following screenshot describes a simple web application, which has a page for the new user registration. The user has to provide the necessary field details. After entering the details, the user will click on the Register button provided in the web page to submit all the details so that it gets registered to the site. To confirm this to the user, the system will send a notification with a welcoming email to the registered user. The mail is sent to the email address provided by the user. In the application shown in the above screenshot, the entire registration process cannot be automated for testing. For example, the email verification and checking the confirmation email sent by the system will not be automated as the user has to go manually and check the email. This part of the manual testing process will be explained in detail in this article. Manual tests Manual testing, as described earlier, is the simplest type of testing carried out by the testers without any automation tool. This test may contain a single or multiple tests inside. Manual test type is the best choice to be selected when the test is too difficult or complex to automate, or if the budget allotted for the application is not sufficient for automation. Visual Studio 2008 supports two types of manual tests file types. One as text file and the other as Microsoft Word. Manual test using text format This format helps us to create the test in the text format within Visual Studio IDE. The predefined template is available in Visual Studio for authoring this test. This template provides the structure for creating the tests. This format has the extension of .mtx. Visual Studio servers act as an editor for this test format. For creating this test in Visual Studio, either create a new test project and then add the test or select the menu option Test | New Test... and then choose the option to add the test to a new project. Now create the test using the menu option and select Manual Test (Text Format) from the available list as shown in the screenshot below. You can see the list Add to Test Project drop–down, which lists the different options to add the test to a test project. If you have not yet created the test project and selected the option to create the test, the drop-down option selected will create a new test project for the test to be added. If you have a test project already created, then we can also see that project in the list to get this new test added to the project. We can choose any option as per our need. For this sample, let us create a new test project in C#. So the first option from the drop-down of Add to Test Project would be selected in this case. After selecting the option, provide the name for the new test project the system will ask for. Let us name it TestingAppTest project. Now you can see the project getting created under the solution and the test template is also added to the test project as shown next. The template contains the detailed information for each section. This will help the tester or whoever is writing the test case to write the steps required for this test. Now update the test case template created above with the test steps required for checking the email confirmation message after the registration process. The test document also contains the title for the test, description, and the revision history for the changes made to the test case. Before executing the test and looking into the details of the run and the properties of the test, we will create the same test using Microsoft Word format as described in the next section. Manual test using Microsoft Word format This is similar to the manual test that was created using text format, except that the file type is Microsoft Word with extension .mht. While creating the manual test choose the template Manual Test (Word format) instead of the Manual Test (Text Format) as explained in the previous section. This option is available only if Microsoft Word is installed in the system. This will launch the Word template using the MS Word installed (version 2003 or later) in the system for writing the test details as shown in the following screenshot. The Word format helps us to have richer formatting capabilities with different fonts, colors, and styles for the text with graphic images and tables embedded for the test. This document not only provides the template but also the help information for each and every section so that the tester can easily understand the sections and write the test cases. This help information is provided in both the Word and Text format of the manual tests. In the test document seen in previous screenshot, we can fill the Test Details, Test Target, Test Steps, and Revision History similar to the one we did for the text format. The completed test case test document will look like this: Save the test details and close the document. Now we have both formats of manual tests in the project. Open the Test View window or the Test List Editor window to see the list of tests we have in the project. It should list two manual tests with their names and the project to which the tests are associated with. The tests shown in the Test View window looks like the one shown here: The same tests list shown by the Test List Editor would look like the one shown below. The additional properties like test list name, the project name the test belongs to, is also shown in the list editor. There are options for each test either to run or get added to any particular list. Manual tests also have other properties, which we can make use of during testing. These properties can be seen in the Properties window, which can be opened by choosing the manual test either in the Test View or in the Test List Editor windows by right-clicking the test and selecting the Properties option. The same window can also be opened by choosing the menu option View | Properties window. Both formats of manual testing have the same set of properties. Some of these properties are editable while some are read-only, which will be set by the application based on the test type. Some properties are directly related to TFS. The VSTFS is the integrated collaboration server, which combines team portal, work item tracking, build management, process guidance, and version control into a unified server.

Confidentiality and integrity are two critical components of web services. While confidentiality can be ensured by means of encryption, the encrypted data can still be overwritten and the integrity of the message can be compromised. So it becomes is equally important to protect the integrity of the message; digital signatures helps us in doing just that. Overview of Digital Signatures In the web services scenario, XML messages are exchanged between the client application and the web services. Certain messages contain critical business information, and therefore the integrity of the message should be ensured. Ensuring the integrity of the message is not a new concept, it has been there for a long time. The concept is to make sure that the data was not tampered while in transit between the sender and the receiver. Consider, for example, that Alice and Bob are exchanging emails that are critical to business. Alice wants to make sure that Bob receives the correct email that she sent and no one else tampered with or modified the email in between. In order to ensure the integrity of the message, Alice digitally signs the message using her private key, and when Bob receives the message, he will check to make sure that the signature is still valid before he can trust or read the email. What is this digital signature? And how does it prove that no one else tampered with the data? When a message is digitally signed, it basically follows these steps: Create a digest value of the message(a unique string value for the message using a SHA1 or MD5 algorithm). Encrypt the digest value using the private key—known only to the sender. Exchange the message along with the encrypted digest value. MD5 and SHA1 are message digest algorithms to calculate the digest value. The digest or hash value is nothing but a non-reversible unique string for any given data, i.e. the digest value will change even if a space is added or removed. SHA1 produces a 160 bit digest value, while MD5 produces a 128 bit value. When Bob receives the message, his first task is to validate the signature. Validation of signature goes through a sequence of steps: Create a digest value of the message again using the same algorithm. Encrypt the digest value using the public key of Alice(obtained out of band or part of message, etc.) Validate to make sure that the digest value encrypted using the public key matches the one that was sent by Alice. Since the public key is known or exchanged along with the message, Bob can check the validity of the certificate itself. Digital certificates are issued by a trusted party such as Verisign. When a certificate is compromised, you can cancel the certificate, which will invalidate the public key. Once the signature is verified, Bob can trust that the message was not tampered with by anyone else. He can also validate the certificate to make sure that it is not expired or revoked, and also to ensure that no one actually tampered with the private key  of Alice. Digital Signatures in Web Services In the last section, we learnt about digital signatures. Since web services are all about interoperability, digital-signature-related information is represented in an industry standard format called XML Signature (standardized by W3C). The following are the key data elements that are represented in an interoperable manner by XML Signature: What data (what part of SOAP message) is digitally signed? What hash algorithm (MD5 or SHA1) is used to create the digest value? What signature algorithm is used? Information about the certificate or key. In the next section, we will describe how the Oracle Web Services Manager can help generate and verify signatures in web services. Signature Generation Using Oracle WSM Oracle Web Services Manager can centrally manage the security policy, including digital signature generation. One of the greatest advantages in using Oracle WSM to digitally sign messages is that the policy information and the digital certificate information are centrally stored and managed. An organization can have many web services, and some of them might exchange certain business critical information and require that the messages be digitally signed. Oracle WSM will play a key role when different web services have different requirements to sign the message, or when it is required to take certain actions before or after signing the message. Oracle WSM can be used to configure the signature at each web service level and that reduces the burden of deploying certificates across multiple systems. In this section, we will discuss more about how to digitally sign the response message of the web service using Oracle WSM. Sign Message Policy Step As a quick refresher, in Oracle WSM, each web service is registered within a gateway or an agent and a policy is attached to each web service. The policy steps are divided mainly into request pipeline template and response pipeline template, where different policies can be applied for request or response message processing. In this section, I will describe how to configure the policy for a response pipeline template to digitally sign the response message. It is assumed that the web service is registered within a gateway and a detailed example will be described later in this article . In the response pipeline, we can add a policy step called Sign Message to digitally sign the message. In order to digitally sign a message, the key components that are required are: Private key store Private key password The part of SOAP message that is being signed The signature algorithm being used The following screenshot describes the Sign Message policy step with certain values populated.   In the previous screenshot, the values that are populated are: Keystore location—The location where the private key file is located. Keystore type—Whether or not it is PKCS12 or JKS. Keystore password—The password to the keystore. Signer's private-key alias—The alias to gain access to the private key from the keystore. Signer's private-key password—The password to access the private key. Signed Content—Whether the BODY or envelope of the SOAP message should be signed. The above information is a part of a policy that is attached to the time service which will sign the response message. As per the information that is shown in the screenshot, the BODY of the SOAP message response will be digitally signed us in the SHA1 as the digest algorithm, and PKCS12 key store. Once the message is signed, the SOAP message will look like: <?xml version="1.0" encoding="UTF-8"?><soap:Envelope soap_encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" > <soap:Header> <wsse:Security soap_mustUnderstand="1"> <wsse:BinarySecurityToken ValueType="http://docs. oasis-open.org/wss/2004/01/oasis-200401-wss- x509-token-profile-1.0#X509v3" EncodingType="http://docs.oasis-open. org/wss/2004/01/oasis-200401-wss-soap-message- security-1.0#Base64Binary" wsu_Id="_ VLL9yEsi09I9f5ihwae2lQ22" >SecurityTOkenoKE2ZA==< /wsse:BinarySecurityToken> <dsig:Signature > <dsig:SignedInfo> <dsig:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/ xml-exc-c14n#"/> <dsig:SignatureMethod Algorithm="http://www.w3.org/2000/09/ xmldsig#rsa-sha1"/> <dsig:Reference URI="#ishUwYWW2AAthrx hlpv1CA22"> <dsig:Transforms> <dsig:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/> </dsig:Transforms> <dsig:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/> <dsig:DigestValue>ynuqANuYM3qzdTnGOLT7SMxWHY=</dsig:DigestValue> </dsig:Reference> <dsig:Reference URI="#UljvWiL8yjedImz 6zy0pHQ22"> <dsig:Transforms> <dsig:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/> </dsig:Transforms> <dsig:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/> <dsig:DigestValue>9ZebvrbVYLiPv1BaVLDaLJVhwo=</dsig:DigestValue> </dsig:Reference> </dsig:SignedInfo> <dsig:SignatureValue>QqmUUZDLNeLpAEFXndiBLk</dsig:SignatureValue> <dsig:KeyInfo> <wsse:SecurityTokenReference wsu_Id="_7vjdWs1ABULkiLeE7Y4lAg22" > <wsse:Reference URI="#_VLL9yEsi09I9f5ihwae2lQ22"/> </wsse:SecurityTokenReference> </dsig:KeyInfo> </dsig:Signature> <wsu:Timestamp wsu_Id="UljvWiL8yjedImz6zy0pHQ22"> <wsu:Created>2007-11-16T15:13:48Z</wsu:Created> </wsu:Timestamp> </wsse:Security> </soap:Header> <soap:Body wsu_Id="ishUwYWW2AAthrxhlpv1CA22" > <n:getTimeResponse > <Result xsi_type="xsd:string">10:13 AM</Result> </n:getTimeResponse> </soap:Body></soap:Envelope>

We'll add a competitive element to the project and—just as we have seen on TV—let the children vote for the winner. The tasks we set will involve the students researching, collaborating, and reflecting. They will be working hard, but we'll have a much easier time now, as all of their responses will be on Moodle for us to view and mark at our convenience—no more carrying heavy books around. Giving our class a chance to vote Moodle has an activity, known as Choice, which allows you to present students with a number of options that they can choose from. We're actually going to use it twice in our project, for two different purposes. Let's us try and set it up. Time for action-giving students a chance to choose a winner The students have posted their suggestions, comments, and views on Moodle. A choice is to be made of the best suggestion. Who better, than the students themselves to choose and vote for the best? With editing turned on, click on Add an Activity and then select Choice. In the Name field, enter an appropriate descriptive text—in our case, this is Vote for the best design here. In the Choice Text field, ask the question based on which you want the students to cast a vote. Leave the Limit field as it is if you don't mind any number of students casting a vote for any option available. Change it to enable, if you only want a certain number of people to vote for a particular choice. We shall leave the Limit block as it is, but we shall inform the students that they can't vote for themselves. In the Choice block, type in the options (a minimum of two) you want the students to be able to cast their vote for. Clicking on Add more fields will provide you with more choice boxes. We will need one field for each member of the class, for this activity. Use the Restrict answering to this time period option to decide when to open and close your Choice—or have it always available. Miscellaneous settings: For our activity, we need to set Display Mode to Vertical set and Publish Results to Do Not Publish. The following table explains what the settings mean, so you can use them on other occasions. Setting What it is Why use it Display Mode Lets you have your buttons go across or down the screen Use Vertically if you have many options to avoid stretching your screen Publish Results Decide if and when you want students to see what others have put Choose Do not publish if you want them to tell you their progress privately; if you're doing a class survey, choose, for example, Always show results Privacy of Results Lets you choose whether to show names or not Are the results more important than who voted for what? Some students might be wary of responding if they think their names will be shown Allow choice to be updated Lets them change their mind-but they can still vote only once. Useful, if you are using this to assess progress over a period of time. Show column for unanswered Sets up a column showing those who haven't yet responded A clear visual way of knowing who hasn't done the task For now, you can ignore the Common Module Settings option, and just click on Save and return to course. What just happened? We've set up an area, on our course page, where the students can choose their favorite designs from a number of options, by clicking on the desired option button. On the screen, you will be able to see an icon (usually, a question mark) and some text next to it. If you click on the text next to the icon, the following information will appear: The students will click on the option button placed next to their choice—in our case, the name of the classmate whose design they prefer. Finding out the students' choice Access the Choice option and click on the words View *** responses on the upper right of the screen. The *** will be the number of students who have voted already. You will get a chart displaying the choices of the students. In my Moodle course, as shown in the following screenshot, nobody has voted yet—so they need a gentle nudge! Remember that we have set up this activity so that our students cannot see the results, in order to avoid peer pressure or bullying. However, we can see the results. Thus, if Mickey votes for himself (even after having been told not to) we will spot it and can reprimand him. Have a go hero-getting the class to give us feedback After we've gone through all of the effort to set up our project on Moodle, it would be nice to know how well it was received. Why not go off now and set up another Choice option, where the question asks how much did you enjoy planning and designing the campsite? You could give them three simple responses (displayed horizontally) as: A lot It was OK Not very much. Or you could be more specific, focusing on the individual activities and asking how much they feel they have benefited from, say, the wiki or the forum. Make sure it is set up, so that the students don't see the results—that way they're more likely to be truthful. Why use Choice? Here are a few other thoughts on Choice, based on my own experiences: It is a fast and simple method of gathering data for a class research project. I used this with a class of 13 year olds who had just returned from the summer break. I asked them to choose where they had been on vacation, giving them choices of our own country, several nearby countries in Europe, the United States of America, and a few more. I set up the choice, so that they could all see the answers when the time was up. I also set it up in such a way that the results were anonymous, to avoid any kind of uneasiness felt by those students who had stayed at home. The class then compared and contrasted the class results with Tourist Office statistics on the most popular tourist destinations. It offers a private way for students to evaluate and inform the teacher about their progress. Students might be too shy to tell you in person if they are struggling; they might be wary of being honest in the open voting methods that some teachers use (such as red, amber, or green traffic lights). However, if the students are aware of the fact that their classmates will not see their response, they are more likely to be honest with you. It acts as a way to involve the class in deciding the path that their learning will take. I first introduced my class of 11 year olds to rivers in Europe, South America, Africa, and Asia. Then, I offered the class, the chance to vote for the river that they wanted study in greater depth as part of their project. The majority opted for the Amazon—so the Amazon it was! Announcing the winner Well, you could give out the results in the classroom, of course! Alternatively, can encourage them to use Moodle by using the Compose a Webpage resource that we met in the previous article on Adding Worksheets and Resources with Moodle, and adding the information there. Writing creatively in Moodle Once a winner has been found, the next task for everyone is to create a cleverly-worded advertisement for this campsite, for which, you could use one of the names suggested in the glossary. This too can be done on Moodle. Why use Moodle and not their exercise books? The first reason is that it will save paper, the second reason is that the students enjoy working on the computer, and the third and final reason is that we can work at our leisure in school, at home, or in any room where there is an Internet connection. We're not tied to carrying around a pile of heavy books. We don't even need to manually hand-write the grades into our grade book. Moodle will put the grades that we give our students, into its grade book automatically and alphabetically. Moodle can also send our pupils an email telling them that we've graded their task, so that they can check their grades. This might be a different way of working from the one that you are used to, but do give it a try. It will take the pressure off your back and shoulders, if nothing else. Time for action-setting up an online creative writing exercise For our advert, we'll use an Online text assignment. With editing turned on, select online text option, within Assignments. In the Assignment name field, enter something descriptive—our students will click here to get to the task. In the Description field, enter the instructions. Our screen will then appear as shown in the following screenshot: If you need more space to type in, click on the icon on the far right of the bottom line of the HTML editor. This will enlarge the text box for you. Click it again when you're done, to return to the editing area. In the Grade field, enter the total marks out of which you will score the students (for now, we're sticking to a maximum of 100, but you can change this). Set a start and end date between which the students can send the work assigned to them, if you want. Leave the Prevent Late Submissions option as it is, unless you need to set a deadline by which the students must submit the assigned work. Set the Allow Resubmitting option to YES, if you want to let students redraft their work. Set the Email Alerts to teachers option to NO (unless you want 30 emails in your inbox!). Change the Comment inline option to YES, so that we can post a comment on the students work. Click on Save and return to course. What just happened? We've just explained to our class what we want them to do, and have also provided them with space in Moodle to do it. We used an Online Text assignment. If we go up to the top of our course, where the editing button is, you'll be able to see a very useful feature called Switch role to…. If we choose the Student option, it will allow us to see the tasks as the pupils will see them: In this case, there's a rather unfriendly command at the bottom of our assignment. Do you think that your students will know that they need to click here to get to their text box? Why not ask your Moodle administrator to look at the Language editing settings and change these words to something more child-friendly—such as Click here to type your answer?

All Dijits can be subclassed to change parts of their behavior, and then used as the original Dijits, or you can create your own Dijits from scratch and include existing Dijits (Forms, buttons, calendars, and so on) in a hierarchical manner. All Dijits can be created in either of the following two ways: Using the dojoType markup property inside selected tags in the HTML page. Programmatic creation inside any JavaScript. For instance, if you want to have a ColorPalette in your page, you can write the following: <div dojoType="dijit.ColorPalette"></div> But you also need to load the required Dojo packages, which consist of the ColorPalette and any other things it needs. This is generally done in a script statement in the <head> part of the HTML page, along with any CSS resources and the djConfig declaration. So a complete example would look like this: <html> <head> <title>ColorPalette</title> <style> @import "dojo-1.1b1/dojo/resources/dojo.css"; @import "dojo-1.1b1/dijit/themes/tundra/tundra.css"; </style> <script type="text/javascript"> djConfig= { parseOnLoad: true } </script> <script type="text/javascript" src="dojo-1.1b1/dojo/dojo.js"></script> <script type="text/javascript"> dojo.require("dojo.parser"); dojo.require("dijit.ColorPalette"); </script> </head> <body class=”tundra”> <div dojoType="dijit.ColorPalette"></div> </body> </html> Obviously, this shows a simple color palette, which can be told to call a function when a choice has been made. But if we start from the top, I've chosen to include two CSS files in the <style> tag. The first one, dojo.css, is a reset.css, which gives lists, table elements, and various other things their defaults. The file itself is quite small and well commented. The second file is called tundra.css and is a wrapper around lots of other stylesheets; some are generic for the theme it represents, but most are specific for widgets or widget families. The two ways to create Dijits So putting a Dojo widget in your page is very simple. If you would want the ColorPalette dynamically in a script instead, remove the highlighted line just before the closing body tag and instead write the following: <script> new dijit.ColorPalette({}, dojo.byId('myPalette')); </script> This seems fairly easy, but what's up with the empty object literal ( {} ) as the first argument? Well, as some Dijits take few arguments and others more, all arguments to a Dijit get stuffed into the first argument and the others, the last argument is (if needed) the DOM node which the Dijit shall replace with its own content somewhere in the page. The default is, for all Dijits, that if we only give one argument to the constructor, this will be taken as the DOM node where the Dijit is to be created. Let's see how to create a more complex Dijit in our page, a NumberSpinner. This will create a NumberSpinner that is set at the value '200' and which has '500' as a maximum, showing no decimals. To create this NumberSpinner dynamically, we would write the following: <input type="text" name="date1" value="2008-12-30" dojoType="dijit.form.DateTextBox"/> One rather peculiar feature of markup-instantiation of Dijits is that you can use almost any kind of tag for the Dijit. The Dijit will replace the element with its own template when it is initialized. Certain Dijits work in a more complicated fashion and do not replace child nodes of the element where they're defined, but wrap them instead. However, each Dijit has support for template HTML which will be inserted, with variable substitutions whenever that Dijit is put in the page. This is a very powerful feature, since when you start creating your own widgets, you will have an excellent system in place already which constrains where things will be put and how they are called. This means that when you finish your super-complicated graph drawing widget and your client or boss wants three more just like it on the same page, you just slap up three more tags which have the dojoType defining your widget. How do I find my widget? You already know that you can use dojo.byId('foo') as a shorter version of document.getElementById('foo'). If you still think that dojo.byId is too long, you can create a shorthand function like this: var $ = dojo.byId; And then use $('foo') instead of dojo.byId for simple DOM node lookup. But Dijits also seem to have an id. Are those the same as the ids of the DOM node they reside in or what? Well, the answer is both yes and no. All created Dijit widgets have a unique id. That id can be the same string as the id that defines the DOM node where they're created, but it doesn't have to be. Suppose that you create a Dijit like this: <div id='foo' dojoType='dijit._Calendar'></div> The created Dijit will have the same Dijit id as the id of the DOM node it was created in, because no others were given. But can you define another id for the widget than for its DOM node? Sure thing. There's a magic attribute called widgetId. So we could do the following: <div id='foo' dojoType='dijit._Calendar' widgetId='bar'></div> This would give the widget the id of 'bar'. But, really, what is the point? Why would we care the widget / Dijit has some kind of obscure id? All we really need is the DOM node, right? Not at all. Sure, you might want to reach out and do bad things to the DOM node of a widget, but that object will not be the widget and have none of its functions. If you want to grab hold of a widget instance after it is created, you need to know its widget id, so you can call the functions defined in the widget. So it's almost its entire reason to exist! So how do I get hold of a widget obejct now that I have its id? By using dijit.byId(). These two functions look pretty similar, so here is a clear and easy to find (when browsing the book) explanation: dojo.byId(): Returns the DOM node for the given id. dijit.byId(): Returns the widget object for the given widget id. Just one more thing. What happens if we create a widget and don't give either a DOM or widget id? Does the created widget still get an id? How do we get at it? Yes, the widget will get a generated id, if we write the following: <div dojoType='dijit._Calendar'></div> The widget will get a widget id like this: dijit__Calendar_0. The id will be the string of the file or namespace path down to the .js file which declares the widget, with / exchanged to _, and with a static widget counter attached to the end.

Setting up Liferay Portal As an administrator at the enterprise, you need to undertake a lot of administration tasks, such as installing Liferay portal, installing and setting up databases, and so on. You can install Liferay Portal through different ways, based on your specific needs. Normally, there are three main installation options: Using an open source bundle—It is the easiest and fastest installation method to install Liferay portal as a bundle. By using a Java SE runtime environment with an embedded database, you simply unzip and run the bundle. Detailed installation procedure—You can install the portal in an existing application server. This option is available for all the supported application servers. Using the extension environment—You can use a full development environment to extend the functionality. We will take up the third installation option "Using the extension environment" in the coming section. Using Liferay Portal Bundled with Tomcat 5.5 in Windows First let's consider one scenario when you, as an administrator, need to install Liferay portal in Windows with MySQL database, and your local Java version is JavaSE 5.0. Let's install Liferay portal bundled with Tomcat 5.5 in Windows as follows: Download Liferay Portal bundled with Tomcat for JDK 5.0 from Liferay official web site. Unzip the bundled file. Set up MySQL database as follows:create database liferay;grant all on liferay.* to 'liferay'@'localhost' identified by'liferay' with grant option;grant all on liferay.* to 'liferay'@'localhost.localdomain'identified by 'liferay' with grant option; Create a database and account in MySQL: Copy the MySQL JDBC driver mysql.jar to $TOMCAT_DIR/lib/ext; Comment the Hypersonic data source (HSQL) configuration and uncomment MySQL configuration ($TOMCAT_DIR/conf/Catalina/localhost/ROOT.xml):<!-- Hypersonic --><!--<Resource name="jdbc/LiferayPool" auth="Container"type="javax.sql.DataSource" driverClassName="org.hsqldb.jdbcDriver"url="jdbc:hsqldb:lportal"username="sa"password=""maxActive="20" /> --><!-- MySQL --><Resource name="jdbc/LiferayPool" auth="Container"type="javax.sql.DataSource" driverClassName="com.mysql.jdbc.Driver"url="jdbc:mysql://localhost/liferay?useUnicode=true&amp;characterEncoding=UTF-8"username="liferay"password="liferay"maxActive="20" /> Run $TOMCAT_DIR /bin/startup.bat. Open your browser and go to http://localhost:8080 (here we assume that it is a local installation, otherwise use the real host name or IP). Login as an administrator—User: test@liferay.com and Password: test. Note that the bundle comes with an embedded HSQL database loaded with sample data from the public website of Liferay. Do not use the Hypersonic in production. Using Liferay Portal Bundled with Tomcat 6.x in Linux Let's consider another scenario when you, as an administrator, need to install Liferay portal in Linux with MySQL database, and your local Java version is Java 6.0. Let's install Liferay portal bundled with Tomcat 6.0 in Linux as follows: Download Liferay Portal bundled with Tomcat 6.0 from Liferay official web site. Unzip the bundled file. Create a database and account in MySQL (as stated before). Run $TOMCAT_DIR/bin/startup.sh. Open your browser and go to http://localhost:8080 (assuming local installation; otherwise use the real host name or IP). Log in as an administrator—User: test@liferay.com and Password: test. Note that, Liferay Portal creates the tables it needs along with example data, the first time it starts. Furthermore, it is necessary to make the script executable by running chmod +x filename.sh. It is often necessary to run the executable from the directory where it resides. Using More Options for Liferay Portal Installation You can use one of the following options for Servlet containers and full Java EE application servers to install Liferay Portal: Geronimo + Tomcat Glassfish for AIX Glassfish for Linux Glassfish for OSX Glassfish for Solaris Glassfish for Solaris (x86) Glassfish for Windows JBoss + Jetty 4.0 JBoss + Tomcat 4.0 JBoss + Tomcat 4.2 Jetty JOnAS + Jetty JOnAS + Tomcat Pramati Resin Tomcat 5.5 for JDK 1.4 Tomcat 5.5 for JDK 5.0 Tomcat 6.0 You can choose a preferred bundle according to your requirements and download it from the official download page directly. Simply go to the website http://www.liferay.com and click on Downloads page. Flexible Deployment Matrix As an administrator, you can install Liferay Portals on all major application servers, databases, and operating systems. There are over 700 ways to deploy Liferay Portal. Thus, you can reuse your existing resources, stick to your budget and get an immediate return on you investment that everyone can be happy with. In general, you can install Liferay portal in Linux, UNIX and Windows with any one of the following application servers (or Servlet containers) and by selecting any one of the following database systems. The applications servers (or Servlet containers) that Liferay Portal can run on, include: Borland ES 6.5 Apache Geronimo 2.x Sun GlassFish 2 UR1 JBoss 4.0.x, 4.2.x JOnAS 4.8.x JRun 4 Updater 3 OracleAS 10.1.3.x Orion 2.0.7 Pramati 5.0 RexIP 2.5 SUN JSAS 9.1 WebLogic 8.1 SP4, 9.2, 10 WebSphere 5.1, 6.0.x, 6.1.x Jetty 5.1.10 Resin 3.0.19 Tomcat 5.0.x/5.5.x/6.0.x Databases that Liferay portal can run on include: Apache Derby IBM DB2 Firebird Hypersonic Informix InterBase JDataStore MySQL Oracle PostgresSQL SAP SQL Server Sybase Operating systems that Liferay portal can run on include: LINUX (Debian, RedHat, SUSE, Ubuntu, and so on.) UNIX (AIX, FreeBSD, HP-UX, OS X, Solaris, and so on.) WINDOWS MAC OS X

Enabling and reviewing My Reports As described in Part 1 the My Reports folder needs to be enabled in order to use the folder or display it in the Open Report dialogue. The RC0 version had a documentation bug which has been rectified (https://connect.microsoft.com/SQLServer/feedback/ViewFeedback.aspx?FeedbackID=366413) Getting ready In order to enable the My Reports folder you need to carry out a few tasks. This will require authentication and working with the SQL Server Management Studio. These tasks are listed here: Make sure the Report Server has started. Make sure you have adequate permissions to access the Servers. Open the Microsoft SQL Server Management Studio as described previously. Connect to the Reporting Services after making sure you have started the Reporting Services. Right-click the Report Server node. General Execution History Logging Security Advanced The Server Properties window is displayed with a navigation list on the left consisting of the following: In the General page the name, version, edition, authentication mode, and URL of Reporting Service is displayed. Download of an ActiveX Client Print control is enabled by default. In order to work with Report Builder effectively and provide a My Reports folder for each user, you need to place a check mark for the check box Enable a My Reports folder for each user. The My Reports feature has been turned on as shown in the next screenshot. In the Execution page there is choice for report timeout execution, with the default set such that the report execution expires after 1800 seconds. In the History page there is choice between keeping an unlimited number of snapshots in the report history (default) or to limit the copies allowing you to specify how many to be kept. In the Logging page, report execution logging is enabled and the log entries older than 60 days are removed by default. This can be changed if desired. In the Security page, both Windows integrated security for report data sources and ad hoc report executions are enabled by default. The Advanced page shows several more items including the ones described thus far as shown in the next figure. In the General page enable the My Reports feature by placing a check mark. Click on the Advanced list item in the left. The Advanced page is displayed as shown: Now expand the Security node of Reporting Services and you will see that the My Reports role is present in the list of roles as shown. This is also added to the ReportServer database. The description of everything that a user with the assignment My Reports role can do is as follows: May publish reports and linked reports, manage folders, reports, and resources in a users My Reports folder. Now bring up Report Builder 2.0 by clicking Start | All Programs | Microsoft SQL Server 2008 Report Builder | Report Builder 2.0. Report Builder 2.0 is displayed. Click on Office Button | Open. The Open Report dialogue appears as shown. When the report Server is offline, the default location is My Documents, like Microsoft products Excel and MS Access. Choose the Recent sites and Servers. The Report server that is active should get displayed here as shown: Highlight the Server URL and click Open. All the folders and files on the server become accessible as shown: Open the Report Manager by providing its URL address. Verify that a My Reports folder is created for the user (current user). There could be slight differences in the look of the interface depending on whether you are using the RTM or the final version of SQL Server 2008 Enterprise edition.

A photoblog is like a regular blog except that the principal content is not text but photographs. The main reason for choosing a photoblog is that the range of features to be implemented is small enough so that we can concentrate on their design and implementation. The goals behind going through this application are as follows: To see how to slice the development of a web application into meaningful layers and therefore show that a web application is not very different from a rich application sitting on your desktop. To show that the separation of concerns can also be applied to the web interface itself by using principles grouped under the name of Ajax. To introduce common Python packages for dealing with common aspects of web development such as database access, HTML templating, JavaScript handling, etc. Photoblog Entities As mentioned earlier, the photoblog will try to stay as simple as possible in order to focus on the other aspects of developing a web application. In this section, we will briefly describe the entities our photoblog will manipulate as well as their attributes and relations with each other. In a nutshell our photoblog application will use the following entities and they will be associated as shown in the following figure: This figure is not what our application will look like but it shows the entities our application will manipulate. One photoblog will contain several albums, which in turn will host as many films as required, which will carry the photographs. In other words, we will design our application with the following entity structure: Entity: Photoblog Role: This entity will be the root of the application. Attributes: name: A unique identifier for the blog title: A public label for the blog Relations: One photoblog will have zero to many albums Entity: Album Role: An album carries a story told by the photographs as an envelope. Attributes: name: A unique identifier for the album title: A public label for the album author: The name of the album's author description: A simple description of the album used in feeds story: A story attached to the album created: A timestamp of when the album is being created modified: A timestamp of when the album is being modified blog_id: A reference to the blog handling the album Relations: One album will reference zero to several films Entity: Film Role: A film gathers a set of photographs. Attributes: name: A unique identifier for the film title: A public label for the film created: A timestamp of when the film is being created modified: A timestamp of when the film is being modified album_id: A reference to the album Relations: A film will reference zero to several photographs Entity: Photo Role: The unit of our application is a photograph. Attributes: name: A unique identifier for the photo legend: A legend associated with the photograph filename: The base name of the photograph on the hard-disk filesize: The size in bytes of the photograph width: Width of the photograph in pixels height: Height of the photograph in pixels created: A timestamp of when the photograph is being created modified: A timestamp of when the photograph is being modified film_id: A reference to the film carrying the photograph Relations: None Functionally, the photoblog application will provide APIs to manipulate those entities via the traditional CRUD interface: Create, Retrieve, Update, and Delete. Vocabulary Here is a list of the terms we will be using: Persistence: Persistence is the concept of data items outliving the execution of programs manipulating them. Simply put, it is the process of storing data in long lasting memory medium such as a disk. Database: A database is a collection of organized data. There are different organization models: hierarchical, network, relational, object-oriented, etc. A database holds the logical representation of its data. Database Management System (DBMS): A DBMS is a group of related software applications to manipulate data in a database. A DBMS platform should offer the following among other features: Persistence of the data A query language to manipulate data Concurrency control Security control Integrity control Transaction capabilities We will use DBMSes as the plural of DBMS. DBMSes Overview In this section, we will quickly review the different kinds of existing DBMSes. The goal is to quickly introduce their main characteristics. Relational Database Management System (RDBMS) Of all DBMSes, the RDBMS is the most common, whether it is in small applications or multi-national infrastructure. An RDBMS comes with a database based on the concepts of the relational model, a mathematical model that permits the logical representation of a collection of data through relations. A relational database should be a concrete implementation of the relational model. However, modern relational databases follow the model only to a certain degree. The following table shows the correlation between the terms of the relational model and the relational database implementation. Relational databases support a set of types to define the domain of scope a column can use. However, there are only a limited number of supported types, which can be an issue with complex data types as allowed in objected-oriented design. Structure Query Language more commonly known as SQL is the language used to define, manipulate, or control data within a relational database. The following table is a quick summary of SQL keywords and their contexts. A construction of these keywords is called an SQL statement. When executed, an SQL statement returns a collection of rows of the data matching the query or nothing. The relational model algebra uses the relation composition to compose operations across different sets; this is translated in the relational database context by joins. Joining tables allows complex queries to be shaped to filter out data. SQL provides the following three kinds of joins:   Union Type Description INNER JOIN Intersection between two tables. LEFT OUTER JOIN Limits the result set by the left table. So all results from the left table will be returned with their matching result in the right table. If no matching result is found, it will return a NULL value. RIGHT OUTER JOIN Same as the LEFT OUTER JOIN except that the tables are reversed.  

(For more resources on .NET, see here.) As of now, the ASP.NET MVC framework is still in CTP (Community Technology Preview, which is similar to an advanced pre-stage), and there is no certain date when it will be released. But even with the CTP 5, we can see how it will help MVC applications follow a stricter architecture. We will quickly see how to use the ASP.NET MVC framework through a small example. Sample Project First, download the ASP.NET MVC framework from the Microsoft website and install it. This installation will create an MVC project template in VS 2008. Start VS 2008, select the File | New Project menu item and then choose theASP.NET MVC Web Application template to create a new web application using this template. There are many free unit testing frameworks available for ASP.NET projects, and NUnit and MBUnit are two of the most popular ones. Here are the links: MBUnit: http://www.mbunit.com/NUnit:; http://www.nunit.org/index.php Select the default option and click OK. You will notice that two projects have been added to the solution that VS has created. The first project is a web project where you'll implement your application. The second is a testing project that you can use to write unit tests against. In our custom MVC code project, we had different projects (class libraries) for the model, the view, and the controllers. The default directory structure of an ASP.NET MVC Application has three top-level directories: /Controllers /Models /Views When the project becomes large, it is recommended that the Model, Views and Controllers are put in separate class library projects of their own so that it's easy to maintain them. But for the purpose of illustrating the ASP.NET MVC framework, this default structure is fine for us. We will create a simple customer management application. For this, we first create some ASPX pages in the Views folder. Note that VS has already created these subfolders for us, under Views: Home: Contains the and Index views Shared: Contains shared views such as master pages Before we go on to adding custom code in this project, let us understand what VS has done for us while creating this MVC project. URL Routing Engine In the standard ASP.NET model (or Postback model), the URLs map directly to the physical files: So when we make a request to a page, say MyPage.aspx, the runtime compiles that page and returns the generated HTML back to IIS to be displayed by the client browser. So we have a one-to-one relationship between the application URLs and the page. But in the MVC framework, the URLs map to the controller classes. Therefore, the URL is sent to IIS and then to ASP.NET runtime, where it initiates a controller class based on the URL, using the URL routes, and the controller class then loads the data from the model, with this data finally being rendered in the view. The controller classes uses URL routing to map the URLs, which in simpler terms means rewriting URL. We can set up the rules for which URL is to be routed to which controller class. The routing will pick up the appropriate controller and pass in the query string variables as necessary. Open the global.asax.cs file and examine the following code: public class GlobalApplication : System.Web.HttpApplication{public static void RegisterRoutes(RouteCollection routes){routes.IgnoreRoute("{resource}.axd/{*pathInfo}");routes.MapRoute("Default", // Route name"{controller}/{action}/{id}", // URL with parametersnew { controller = "Home", action = "Index", id = "" }// Parameter defaults);}protected void Application_Start(){RegisterRoutes(RouteTable.Routes);} The RegisterRoutes() method contains the URL mapping routes. Initially we have only the default rule set: routes.MapRoute("Default", // Route name"{controller}/{action}/{id}", // URL with parametersnew { controller = "Home", action = "Index", id = "" } // Parameter defaults); The RegisterRoutes() method contains the URL mapping routes. Initially we have only the default rule set: The MapRoute() method, which handles URL routing and mapping, takes three arguments: Name of the route (string) URL format (string) Default settings (object type) In our case, we named the first route "Default" (which is the route name) and then set the URL as: Controller/action/id The Controller here is the name of the controller class. action will be the method that needs to be invoked inside that controller class. id would be the parameters that need to be passed, if any. In the default arguments, we create a new object and call it "Home", set the action to Index, and do not pass parameters to it. Note the new anonymous type syntax used to create parameter defaults: new { controller = "Home", action = "Index", id = "" } The var keyword and anonymous types: We normally use classes to wrap behavior and properties, but in C# 3.0, we can create the types anonymously without needing to create classes for them. This can be useful when we need to create light weight classes that have only read-only properties. We can use the anonymous syntax to create those types without the need to create a class for them. We can use the new "var" keyword to hold such anonymous types, for example: var ch = new { readOnlyProperty1 = value1, readOnlyProperty2 = value2 }; It is important that we name and assign a value to each of the properties that we are creating. What will be the type of the properties? They will automatically be cast to the data types of the values of the properties specified. The anonymous types will always be derived from the base object class directly. They can only be used within class members and cannot be passed as method arguments (unless they are boxed), return values, or be specified as class-level variables. Once the type is created, it cannot be changed into another type. So we create a new anonymous type as the last argument of the MapRoute() method, passing in variable defaults with three properties, namely controller, action, and parameter. Now have the Default.aspx page under the root directory, which acts as a redirecting page to the main home page of the site (which is /View/Home/Index.aspx). We cannot directly set that as the "default" page since we are using URL routes to process pages instead of using physical files in the URLs. So in the code-behind of our Default.aspx page, we have a simple redirect: public void Page_Load(object sender, System.EventArgs e){Response.Redirect("~/Home");} So the runtime will first set up routes in the global.asax page, then it will process the Default.aspx page. Here it faces a redirect to this URL: /Home. The Controller The MVC framework maps this URL to the route set in the global route table, which currently has only the default one, in this format: Controller/action/id So /Home corresponds to a controller named Home, and because we have not specified any action or ID, it takes the default values we specified in the RegisterRoutes() method in the globals.asax.cs. So the default action was Index and the default parameter was an empty string. The runtime initializes the HomeController.cs class, and fires the Index action there: public class HomeController : Controller{public ActionResult Index(){ViewData["Title"] = "Home Page";ViewData["Message"] = "Welcome to ASP.NET MVC!";return View();}} In this Index() method, we set the data to be displayed in the View (aspx/ascx pages) by using a dictionary property of the base Controller class named ViewData. ViewData, as the name suggests, is used to set view-specific data in a dictionary object that can hold multiple name/value pairs. When we call the View() method, the ViewData is passed by the Controller to the View and rendered there.

A Very Simple Workflow In our simple workflow we'll assume that each task is carried out by one person at a time, and that all tasks are done sequentially (i.e. none are done in parallel). So, we'll look at the PPI Preliminary Investigation which, as you remember, maps to the standard SugarCRM Opportunity. Also, in this example, we're going to have a different person carrying out each one of the Investigation stages. Setting up the Process Stages If you look at SugarCRM then you'll see that by default none of the stages are related to investigations—they're all named using standard CRM terms: Obviously the first thing to do is to decide what the preliminary investigation stages actually are, and then map these to the SugarCRM stages. You'll realize that you'll need to edit the custom/include/langauge/en_us.lang.php file: $app_list_strings['sales_stage_dom']=array ( 'Prospecting' => 'Fact Gathering', 'Qualification' => 'Witness and Subject Location', 'Needs Analysis' => 'Witness and Subject Interviews', 'Value Proposition' => 'Scene Investigation', 'Id. Decision Makers' => 'Financial and background Investigation', 'Perception Analysis' => 'Document and evidence retrieval', 'Proposal/Price Quote' => 'Covert Camera surveillance', 'Negotiation/Review' => 'Wiretapping', 'Closed Won' => 'Full Investigation required', 'Closed Lost' => 'Insufficient Evidence',); Don't forget that you can also do this via Studio. However, once you've added your mapping into custom/include/langauge/en_us.lang.php file, and refresh your browser, then you'll see the new stages: Now that our stages are set up we need to know who'll be carrying out each one. Deciding Who Does What In our simple workflow there may not be the need to do anything further. Each person just needs to know who does what next: For example, once Kurt finishes the 'Covert Camera surveillance' stage then he just needs to update the Preliminary Investigation so that the stage is set to 'Wiretapping' and the assigned user as 'dobbsm'. However, things are rarely as simple as that. It's much more likely that: Investigations may be based on geographical locations, so that the above table may only apply to investigations based in London. Investigations based in New York follow the same process but with a different set of staff. On Mondays Fran does 'Witness and Subject Location' and William does 'Fact Gathering'. This means, of course, that we need to be using some businesses rules. Introducing Business Rules There are six 'triggers' that will cause the logic hooks to fire: after_retrieve before_save before_delete after_delete before_undelete after_undelete And the logic hooks are stored in custom/modules/<module name>/logic_hook.php, so for 'Preliminary Inquiries' this will be custom/modules/Opportunities/logic_hook.php. You'll also remember, of course, that the logic hook file needs to contain: The priority of the business rule The name of the businesses rule The file containing the business rule The business rule class The business rule function So, custom/modules/Opportunities/logic_hook.php needs to contain something like: <?php#As always ensure that the file can only be accessed through SugarCRMif(!defined('sugarEntry') || !sugarEntry) die( 'Not A Valid Entry Point');$hook_array = Array(); #Create an array$hook_array['before_save'] = Array();$hook_array['before_save'][] = Array(1, 'ppi_workflow', 'custom/include/ppi_workflow.php', 'ppi_workflow', 'ppi_workflow');?> Next we'll need the file that logic hook will be calling, but to start with this can be very basic—so, custom/include/ppi_workflow.php just needs to contain something like: <?php#Define the entry pointif(!defined('sugarEntry') || !sugarEntry) die( 'Not A Valid Entry Point');#Load any required filesrequire_once('data/SugarBean.php');require_once('modules/Opportunities/Opportunity.php');#Define the classclass ppi_workflow{ function ppi_workflow (&$bean, $event, $arguments) { }}?> With those two files set up as above nothing obvious will change in the operation of SugarCRM—the logic hook will fire, but we haven't told it to do anything, and so that what we'll do now. When the logic hook does run (i.e. when any Primary Investigation is saved) we would want it to: Check to see what stage we're now at Define the assigned user accordingly  

EAI - The Broader Perspective No one should have (or will) ever dared to build a 'Single System' which will take care of the entire business requirements of an enterprise. Instead, we build few (or many) systems,and each of them takes care of a set of functionalities in a single Line of Business (LOB). There is absolutely nothing wrong here, but the need of the hour is that these systems have to exchange information and interoperate in many new ways which have not been foreseen earlier. Business grows, enterprise boundaries expands and mergers and acquisition are all norms of the day. If IT cannot scale up with these volatile environments, the failure is not far. Let me take a single, but not simple problem that today's Businesses and IT face - Duplicate Data. By Duplicate Data we mean data related to a single entity stored in multiple systems and storage mechanisms, that too in multiple formats and multiple content. I will take the 'Customer' entity as an example so that I can borrow the 'Single Customer View' (SCV) jargon to explain the problem. We gather customer information while he makes a web order entry or when he raises a complaint against the product or service purchased or when we raise a marketing campaign for a new product to be introduced or ... The list continues, and in each of these scenarios we make use of different systems to collect and store the same customer information. 'Same Customer' - is it same? Who can answer this question? Is there a Data Steward who can provide you with the SCV from amongst the many information silos existing in your Organization? To rephrase the question, does your organization at least have a 'Single View of Truth', if it doesn't have a 'Single Source of Truth'? Information locked away inside disparate, monolithic application silos has proven a stubborn obstacle in answering the queries business requires, impeding the opportunities of selling, not to mention cross-selling and up-selling. Yeah, it's time to cleanse and distill each customer's data into a single best-record view that can be used to improve source system data quality. For that, first we need to integrate the many source systems available. Today, companies are even acquiring just to get access to it's invaluable Customer information! This is just one of the highlights of the importance of integration to control Information Entropy in the otherwise complicated IT landscape. Figure 1. The 'Single Customer View' Dilemma So Integration is not an end, but a means to end a full list of problems faced by enterprises today. We have been doing integration for many years. There exist many platforms, technologies and frameworks doing the same thing. Built around that, we have multiple Integration Architectures too, amongst which, the Point to Pont, Hub and Spoke, and the Message Bus are common. Figure 2 represents these integration topologies. Figure 2. EAI Topologies Let us now look at the salient features of these topologies to see if we are self-sufficient or need something more. Point to Point In Point to Point, we define integration solutions for a pair of applications. Thus, we have two end points to be integrated. We can build protocol and/or format adaptors/transformers at one or either end. This is the easiest way to integrate, as long as the volume of integration is low. We normally use technology specific APIs like FTP, IIOP, Remoting or batch interfaces to realize integration. The advantage is that between these two points, we have tight coupling, since both ends have knowledge about their peers. The downside is that if there are 6 nodes (systems) to be interconnected, we need at least 30 separate channels for both forward and reverse transport. So think of a mid-sized Enterprise with some 1000 systems to integrate! Hub & Spoke Hub And Spoke Architecture is also called as the Message Broker. It provides a centralized hub (Broker) to which all applications are connected. Each application connects with the central hub through lightweight connectors. The lightweight connectors facilitate application integration with minimum or no changes to the existing applications. Message Transformation and Routing takes place within the Hub. The major drawback of the Hub and Spoke Architecture is that if the Hub fails, the entire Integration topology fails. Enterprise Message Bus An Enterprise Message Bus provides a common communication infrastructure which acts as a platform-neutral and language-neutral adaptor between applications. This communication infrastructure may include a Message Router and/or Publish-Subscribe channels. So applications interact each other through the message bus with the help of Request-Response queues. Sometimes the applications have to use adapters that handle scenarios like invoking CICS transactions. Such adapters may provide connectivity between the applications and the message bus using proprietary bus APIs and application APIs. Service Oriented Integration (SOI) Service Oriented Architecture (SOA) provides us with a set of principles, patterns and practices, to provide and consume services which are orchestrated using open standards so as to remove single vendor lock-into provide an agile infrastructure where services range from business definition to technical implementation. In SOA, we no longer deal with single format and single protocol, instead we accept the fact that heterogeneity exists between applications. And our architecture still needs to ensure interoperability and thus information exchange. To help us do integration in the SOA manner, we require a pluggable service infrastructure where providers, consumers, and middleware services can collaborate in the famous 'Publish -- Find -- Bind' triangle. So, similar to the integration topologies described above, we need a backbone upon which we can build SOA that can provide a collection of middleware services that provides integration capabilities. This is what we mean by Service Oriented Integration (SOI). Gartner originally identified Enterprise Service Bus (ESB) Architecture as a core component in the SOA landscape. ESB provides a technical framework to align your SOA based integration needs. In the rest of the article we will concentrate on ESB. Enterprise Service Bus (ESB) Roy Schutle from Gartner defines an ESB as:"A Web-services-capable middleware infrastructure that supports intelligent program-to-program communication and mediates the relationships among loosely-coupled and uncoupled business components." In the ESB Architecture (Refer Figure 2), applications communicate through an SOA middleware backbone. The most distinguishing feature of the ESB Architecture is the distributed nature of the integration topology. This makes the ESB capabilities to spread out across the bus in a distributed fashion, thus avoiding any single point of failure. Scalability is achieved by distributing the capabilities into separately deployable service containers. Smart, intelligent connectors connect the applications to the Bus. Technical services like transformation, routing, security, etc. are provided internally by these connectors. The Bus federates services which are hosted locally or remotely, thus collaborating distributed capabilities. Many ESB solutions are based on Web Services Description Language (WSDL) technologies, and they use Extensible Markup Language (XML) formats for message translation and transformation. The best way to think about an ESB is to imagine the many features which we can provide to the message exchange at a mediation layer (the ESB layer), a few among them is listed below: Addressing & Routing  Synchronous and Asynchronous style invocations  Multiple Transport and protocol bindings  Content transformation and translation  Business Process Orchestration (BPM)  Event processing  Adapters to multiple platforms  etc... Service Aggregation in ESB ESB provides you the best ways of integrating services so that services are not only interoperable but also reusable in the form of aggregating in multiple ways and scenarios. This means, services can be mixed and matched to adapt to multiple protocols and consumer requirements. Let me explain you this concept, as we will explore more into this with the help of sample code too. In code and component reuse, we try to reduce ‘copy and paste’ reuse and encourage inheritance, composition and instance pooling. Similar analogy exists in SOI where services are hosted and pooled for multiple clients through multiple transport channels, and ESB can do this in the best way integration world has ever seen. We call this as the notion of shared services. For example, if a financial organization provides a ‘credit history check service’, an ESB can facilitate reuse of this service by multiple business processes (like a Personal Loan approval process or a Home Mortgage approval process). So, once we create our 'core services', we can then arbitrarily compose these services in a declarative fashion so as to define and publish more and more composite services. Business Process Management (BPM) tools can be integrated over ESB to leverage service aggregation and service collaboration. This facilitates reuse of basic or core (or fine grained) services at Business Process level. So, granularity of services is important which will also decide the level of reusability. Coarse grained or composite services consume fine grained services. Applications that consume  coarse-grained services are not exposed to the fine-grained services they use. Composite services can be assembled from coarse-grained as well as fine-grained services. To make the concept clear, let us take the example of provisioning a new VOIP (Voice Over IP) Service for a new Customer. This is a composite service which in turn calls multiple coarse grained services like 'validateOrder', 'createOrVerifyCustomer', 'checkProductAvailability', etc. Now, the createOrVerifyCustomer coarse grained service in turn call multiple fine grained services like 'validateCustomer', 'createCustomer', 'createBillingAddress', 'createMailingAddress', etc. Figure 3. Service Composition Java Business Integration (JBI) Java Business Integration (JBI) provides a collaboration framework which provides standard interfaces for integration components and protocols to plug into, thus allowing the assembly of Service Oriented Integration (SOI) frameworks. JSR 208 is an extension of Java 2 Enterprise Edition (J2EE), but it is specific for Java Business Integration Service Provider Interfaces (SPI). SOA and SOI are the targets of JBI and hence it is built around Web Services Description Language (WSDL). The nerve of the JBI architecture is the NMR (Normalized Message Router). This is a bus through which messages flow in either directions from a source to a destination. You can listen to Ron Ten-Hove, the Co-spec lead for JSR 208 here and he writes more about JBI components in the PDF download titled JBI Components: Part 1. JBI provides the best available, open foundation for structuring applications by composition of services rather than modularized, structured code that we have been doing in traditional programming paradigms. A JBI compliant ESB implementation must support four different service invocations, leading to four corresponding Message Exchange Patterns (MEP):   One-Way (In-Only MEP): Service Consumer issues a request to Service Provider. No error (fault) path is provided.  Reliable One-Way (Robust In-Only MEP): Service Consumer issues a request to Service Provider. Provider may respond with a fault if it fails to process the request.  Request-Response (In-Out MEP): Service Consumer issues a request to Service Provider, with expectation of response. Provider may respond with a fault if it fails to process request.  Request Optional-Response (In Optional-Out MEP): Service Consumer issues a request to Service Provider, which may result in a response. Both Consumer and provider have the option of generating a fault in response to a message received during the interaction.

Introduction Recording a good podcast is as much about good voice training and delivery, as much as it is about the technology used to record it. As with other things, you only get better with practice. In this article we will use Linux command line tools and optionally Audacity to create a quick, no-frills podcast with a background music track. The only other GUI-based tool we will manipulate, will be the ALSA Mixer. The mixer has a command-line interface too, but the GUI is intuitive and quicker. The emphasis is on quick turnaround. If you are the type that attaches a quick voice message to an e-mail for impact, ("We simply must get this done by Friday!!") then the podcast creation method outlined here should appeal to you. If you are new to podcasting and audio mixer setups, the next few sections might be tedious. But towards the end of this article, we will see how quickly one can run down these steps so that you spend more time recording your message than wrestling with technology or complicated screens. The Recording Setup A stereo headset with a microphone works best for making or listening to podcasts; but do not despair if you have a desktop microphone and a pair of speakers. You can always upgrade your setup later. For now just make sure that the sound from the speakers does not directly reach the microphone and cause feedback. Place the microphone towards the lower right of your mouth as you speak, away from your nose. This avoids breathing sounds getting captured. Minimizing ambient noise by choosing a quieter time of the day is also a good idea. Recording Tips All through the recording and mixing process, there are a couple of things to keep in mind. First, stay above the noise floor. The signal should be recorded high enough to stay above the background noise and hiss. If your audio signals are like little, beautiful flowers growing in a grassy field, make sure their stalks are tall enough to tower over the field. Else you would lose the flowers in the prickly grass just as your audio signal would be lost in the background hiss and noise. Second, stay below the clipping or overload level of the audio channels. If your audio channels were like open water canals, then overloading them past the clipping limit would have a similar undesirable effect on your audio experience as a canal overflowing its banks -- puddles around your feet or a jarring quality to your sound. Since sound level is a dynamic quantity, record your audio at a level of around 80% keeping some margin (or headroom) against clipping. Setting up the Audio Mixer Connections An audio mixer application helps us record our podcast by allowing us to mix various signal sources in the right proportion. You can bring up the sound mixer from the Linux start menu by getting into the Sound and Video category. To those who are new to the red and green lights of the Linux ALSA mixer, let us run a quick intro. There are audio signal sources and there are destinations. An audio mixer allows you to route one or more sources after adjusting their relative levels to one or more destinations and achieve your project goal. The project goal might be listening to music -- the destination in this case being a pair of headphones or speakers; or it might be a recording device, say, to capture a podcast as we will do presently. Once the ALSA mixer or Kmix is up, select the Output tab. Make sure the Master output channel as well as the PCM channel is switched on (click over the green lights so they turn on) and their gains -- the slider positions -- are at the maximum. Briefly, go the Switches tab and click over the LED indicator to switch on the 'Mix Mono'. We will use this mixing switch to mix the microphone (voice) and the CD (background score) signals to both the monitoring and the recording channels. You can optionally select the 'Mic Boost' switch but experiment with your microphone to check if you indeed need it. Now, go to the Input tab. The two input sources that interest us are the 'Mic' or microphone for our voice and the CD for our background music score. We need to mix these two signal sources in the right proportion and deliver them to the Capture device. Turn on the green LEDs for the 'Mic' and 'CD' sources ensuring that their outputs feed into the 'Mono Mix' and also to your monitoring headphones or speakers. That way you get to listen to what is being recorded. All other input sources should be off (their corresponding green LEDs should be off). Lastly, turn on the red LED under the Capture slider on the Input tab ensuring that the 'Mix Mono' output gets connected to the recording channel.

Filtering As mentioned earlier, filtering is one of the very powerful tools within NAV C/AL. Filtering is the application of defined limits on the data to be considered in a process (to learn more about Data types in NAV, visit here). Filter structures can be applied in at least three different ways, depending on the design of the process. The first way is for the developer to fully define the filter structure and the value of the filter. This might be done in a report designed to show only information on a selected group of customers, for example those with an open Balance on Account. The Customer table would be filtered to report only customers who have an Outstanding Balance greater than zero. The second way is for the developer to define the filter structure, but allow the user to fill in the specific value to be applied. This approach would be appropriate in an accounting report that was to be tied to specific accounting periods. The user would be allowed to define what period(s) were to be considered for each report run. The third way is the ad hoc definition of a filter structure and value by the user. This approach is often used for general analysis of ledger data where the developer wants to give the user total flexibility in how they slice and dice the available data. It is quite common within the standard NAV applications and in the course of enhancements to use a combination of the different filtering types. For example, the report just mentioned that lists only customers with an open Balance on Account (via a developer-defined filter) could also allow the user to define additional filter criteria. Perhaps, the user wants to see only Euro currency-based customers, so they would filter on the Customer Currency Code field. Filters are an integral part of FlowFields and FlowFilters, two of the three Field Classes. These are very flexible and powerful tools, which allow the NAV designer to create forms, reports, and other processes that can be used by the user under a wide variety of circumstances for various purposes. In most systems, user inquiries (forms and reports) and processes need to be quite specific to different data types and ranges. The NAV C/AL toolset allows you to create relatively generic user inquiries and processes and then allow the user to apply filtering to fit their specific needs. Defining Filter Syntax and Values Let us go over some common ways in which we can define filter values and syntax. Remember, when you apply a filter, you will only view or process records where the filtered data field satisfies the limits defined by the filter. Equality and inequalityeither an equal (=) sign or no sign filters for data "equal to" the filter value. Data Type - description Example Filters Integer =200 Integer 200 Text Chicago Text " (two single quote marks)         a greater than (>) sign filters for data greater than the filter value Data Type - description Example Filters Integer >200 Date >10/06/07 Decimal >450.50         a less than (<) sign filters for data less than the filter value Data Type - description Example Filters Integer <150 Date <10/07/07

As you know, design of an application starts with the data. The data design depends on the types of data that your development tool set allows you to use. Since NAV is designed specifically to develop financially oriented business applications, the NAV data types are financially and business oriented, and also have some special features that make it easier to design and develop typical business applications. Furthermore, these same special features can make your applications run faster. In this article, we will cover the data types that you are most likely to use. We will also take an overview of the others. In addition, we will also cover field classes, which are where the special features are enabled. Fields A field is the basic element of data definition in NAV—the "atom" in the structure of a system. The mechanical definition of a field consists of its number, its description (name), and its data type (and, of course, any parameters required for its particular data type). From a logical point of view, a field is also defined by its Properties and the C/AL code contained in its Triggers. Field Properties The specific properties that can be defined for a field partially depend on the data type. First we will review the universal field properties. Then we will review the properties that are data-type dependent plus some other field properties. You can check out the remaining properties by using Help within the Table Designer.Fields You can access the properties of a field while viewing the table in Design mode, by highlighting the field line whose properties you wish to examine and clicking on the Properties icon or pressing Shift + F4. All the property screenshots in this section are obtained in this way for fields within the standard Customer table. As we review various field properties, you will learn more if, using the Object Designer, you follow along in your NAV system. Poke around and explore different properties and the values they can have. Use the Field Help function liberally and read the help for various properties. The property value enclosed in < > (less than sign, greater than sign), is the default value for that property. When you set a property to any other value, < and > should not be present unless they are supposed to be the part of the property value (e.g. part of a Text string value).All data types have the following properties: Property Property Description Field No. Identifier for the field within the table object Name Label by which code references the field. The name can be changed at any time and NAV will automatically ripple that change throughout the code Caption and Caption ML Work similarly as named table properties Description Used for internal documentation only Data Type Identifies what kind of data format applies to this field (e.g. Integer, Date, Code, Text, etc.) Enabled Determines if the field is activated for data handling or not. This property defaults to yes and is rarely changed   The following screenshot shows the BLOB properties for the Picture Field in the Customer table: This set of properties, for fields of the BLOB data type, is the simplest set of field properties. After the properties that are shared by all data types, appear the BLOB-specific properties—SubType and Owner:    SubType: This defines the type of data stored in the BLOB. The three  sub-type choices are Bitmap (for bitmap graphics), Memo (for text data), and  User-Defined (for anything else). User-Defined is the default value.    Owner: The usage is not defined.   The available properties of Code and Text fields are quite similar to one another. The following are some common properties between the two as shown in the screenshot overleaf:   DataLength: This specifies how many characters long the data field is. InitValue: This is the value that the system should supply as a default when  the system actively initializes the field. AltSearchField: This allows definition of an alternative field in the same  table to be searched for a match if no match is found on a lookup on this datastyle="width: 761px; height: 446px;"  item. For example, you might want to allow customers to be looked up eitherstyle="width: 761px; height: 446px;"  by their Customer No. or by their Phone No. In that case, in the No. field  properties you would supply the Phone No. field name in the AltSearchField  field. Then, when a user searches in the No. field, NAV will first look for  a match in the No. field and, if it is not found there, it will then search  the Phone No. field for a match. Use of this property can save you a lot of  coding, but make sure both fields have high placement in a key so the lookup  will be speedy. Editable: This is set to No when you don't want to allow a field to ever be  edited for example, if this is a computed or assigned value field that the user  should not change. NotBlank, Numeric, CharAllowed, DateFormula, and ValuesAllowed: All  these support placing constraints on the specific data that can be entered into  this field. TableRelation and ValidateTableRelation: These are used to  control referencing and validation of entries against another table.  (TestTableRelation is an infrequently used property, which controls whether  or not this relationship should be tested during a database validation test.) Let us take a look at the properties of couple more Data types, Integer and Decimal. You may find it useful to explore them on your own as well. Specific properties related to the basic numeric content of these data types are as follows and are also shown in the following screenshot: DecimalPlaces: This sets the number of decimal places in a Decimal  data item. BlankNumbers, BlankZero, and SignDisplacement: All these can be used to  influence the formatting and display of the data in the field. MinValue and MaxValue: These can constrain the range of data values allowed. AutoIncrement: This allows setting up of one field in a table to automatically  increment for each record entered. This is almost always used to support  automatic updating of a field used as the last field in a primary key, enabling  creation of a unique key. The field properties for an Integer field with a FieldClass property of FlowField are similar to those of a field with a FieldClass property of Normal. The differencesstyle="width: 761px; height: 446px;"relate to the fact that the field does not actually contain data but holds the formula by which the displayed value is calculated, as shown in the following screenshot overleaf. Note the presence of the CalcFormula property and the absence of the AltSearchField, AutoIncrement, and TestTableRelation properties. Similar differences exist for FlowFields of other data types. The properties for an Option data type, whose properties are shown in the following screenshot, are essentially like those of the other numeric data types, but with a datatype-specific set of properties as described below: OptionString: This spells out the text interpretations for the stored integer  values contained in Option data type fields. OptionCaption and OptionCaptionML: These serve the same captioning  and multi-language purposes as other caption properties. The properties defined for FlowFilter fields, such as Date Filter in the following screenshot overleaf, are similar to those of Normal data fields. Take a look at the Date Filter field (a Date FlowFilter field) and the Global Dimension 1 Filter field (a Code FlowFilter field) in the Customer table. The Date Filter field property looks similar to a Normal FieldClass field.