Tuesday, March 26, 2013


REST (Representational State Transfer) and SOAP (Simple Object Access Protocol) represent two different styles for implementing services. Technically, REST is an architectural pattern built with simple verbs that overlay well on HTTP. While REST architectural principles could be applied with protocols other than HTTP, in practice REST implementations are used in conjunction with HTTP. SOAP is an XML-based messaging protocol that can be used with any communication protocol, including HTTP.
The main difference between these two approaches is the way that the service state is maintained. With SOAP, movement through different states can be accomplished through interaction with a single service endpoint, which may encapsulate and provide access to many operations and message types. With REST, a limited set of operations is allowed, and these operations are applied to resources represented and addressable by URIs (HTTP addresses). The messages capture the current or required state of the resource. REST works well with Web applications, so you can take advantage of HTTP support for non-XML MIME types or streaming content from a service request. Service consumers navigating through REST resources interact with URIs in the same way as a human user might navigate through and interact with Web pages.
While both REST and SOAP can be used with most service implementations, the REST approach is often better suited for publicly accessible services or cases where a service can be accessed by unknown consumers. SOAP is much better suited to implementing a range of procedural interactions, such as an interface between layers of an application. With SOAP, you are not restricted to HTTP. The WS-* standards, which can be utilized in SOAP, provide a standard and therefore interoperable method of dealing with common messaging issues such as security, transactions, addressing, and reliability. REST can also provide the same type of functionality, but you must often create a custom mechanism because only a few standards currently exist for these areas.
In general, same principles can be used when designing SOAP based interactions as you do for stateless REST interactions. Both approaches exchange data (the payload) using verbs. In the case of SOAP, the set of verbs is open ended and is defined by the service endpoint. In the case of REST, the set of verbs is constrained to preset verbs that mirror the HTTP protocol. Guidelines when choosing between REST and SOAP:
  • SOAP is a protocol that provides a basic messaging framework upon which abstract layers can be built, and is commonly used as an RPC framework that passes calls and responses over networks using XML-formatted messages. 
  • SOAP handles issues such as security and addressing through its internal protocol implementation, but requires a SOAP stack to be available.
  • REST is a technique that can utilize other protocols, such as JavaScript Object Notation (JSON), the Atom publishing protocol, and custom Plain Old XML (POX) formats.
  • REST exposes an application and data as a state machine, not just a service endpoint. It allows standard HTTP calls such as GET and PUT to be used to query and modify the state of the system. REST is stateless by nature, meaning that each individual request sent from the client to the server must contain all of the information necessary to understand the request since the server does not store the session state data.
Design Considerations for REST
REST represents an architecture style for distributed systems, and is designed to reduce complexity by dividing a system into resources. The resources and the operations supported by a resource are represented and exposed as a set of URIs over the HTTP protocol. Consider the following guidelines when designing REST resources:
  • Identify and categorize resources that will be available to clients.
  • Choose an approach for resource representation. A good practice would be to use meaningful names for REST starting points and unique identifiers for specific resource instances. For example, http://www.contoso.com/employee/ represents an employee starting point. http://www.contoso.com/employee/smithah01 uses an employee ID to indicate a specific employee.
  • Decide if multiple representations should be supported for different resources. For example, you can decide if the resource should support an XML, Atom, or JSON format and make it part of the resource request. A resource could be exposed as both (for example, http://www.contoso.com/example.atom and http://www.contoso.com/example.json).
  • Decide if multiple views should be supported for different resources. For example, decide if the resource should support GET and POST operations, or only GET operations. Avoid overuse of POST operations if possible, and avoid putting actions in the URI.
  • Do not implement the maintenance of user session state within a service, and do not attempt to use hypertext (such as hidden controls in Web pages) to manage state. For example, when users submit requests such as adding an item to a shopping cart, store the data in a persistent state store such as a database.
Design Considerations for SOAP
SOAP is a message-based protocol that is used to implement the message layer of a service. The message is composed of an envelope that contains a header and body. The header can be used to provide information that is external to the operation being performed by the service. For example, a header may contain security, transaction, or routing information. The body contains contracts, in the form of XML schemas, which are used to implement the service. Consider the following guidelines when designing SOAP messages:
  • Determine how you will handle faults and errors, and how you will return appropriate error information to clients.
  • Define the schemas for the operations that can be performed by a service, the data structures passed with a service request, and the errors or faults that can be returned from a service request.
  • Choose the appropriate security model for your services. Avoid using complex types in message schemas. Try to use only simple types to maximize interoperability.

    Tuesday, March 19, 2013

    5 Cloud Computing Email Services for Enterprises

    Cloud services dynamically balance itself to meet the needs of its users, and because of the fact that the service provider supplies the necessary hardware and software, the need for self-deploying a company resource is simply uncalled for.
    Cloud Email Services are pretty different from the normal provisions, as they offer larger storage and better security. Another serious advantage in using a cloud based email service is the option for transferring corporate data from one place to another. These services take the full advantage of cloud computing benefits to maximize capacity utilization, improve IT flexibility and responsiveness, and minimize cost.
    1. Google Apps:
    Google Apps is a service from Google providing independently customizable versions of several Google products under a custom domain name. The service features a number of functionalities for Gmail, Google Groups, Google Calendar, Talk, Docs and other sites.
    Businesses consider Google Apps to be reliable, secure and powerful. Applications like Gmail, Google Calendar and Google Docs, not only reduce the IT costs, but also help employees to work in a more efficient manner.
    Google Apps for business is free for 30 days, $5 per user account and month thereafter or $50 per year. Google Apps for Education is free and offers the same amount of storage as Google Apps for Business accounts. Another notable feature is that the service offers an average 25GB of email storage per employee.
    2. PanTerra Networks:
    PanTerra Networks are one of the major providers in cloud based unified communication services. It has a perfect combination of unified solutions with Software-as-a-Service (SaaS) service, recommended for small and medium sized enterprises. The service provides businesses an option for adding and deleting seats at their will, making a fixed cost of communications for SMBs.
    WorldSmart, PanTerra Networks first product, integrates voice, conferencing video, messaging, email collaboration, fax and call center services into a single solution with a common user and administration portal.
    In 2010, the company introduced a 100 percent browser-based version of WorldSmart (WorldSmart 4.0), eliminating any on-premise hardware or client software requirements and storing all communications in the cloud.
    3. Cisco WebEx Mail:
    Cisco WebEx Mail is recommended for companies who are bearing the extra burden of email management and migration issues. Cisco WebEx Mail helps enterprises to concentrate more on their strategic projects, as the service train employees to adapt to ever changing organizational needs.
    Another important feature of Cisco WebEx Mail is the inclusion of advanced migration tools. The solution also interoperates with email infrastructure as well as archiving and security solutions which obviously minimize disruptions during the transition to a hosted email solution.
    4. VMware Zimbra:
    Zimbra Collaboration Suite (ZCS) is a groupware email server and web client created by Zimbra, located in Palo Alto, California, USA. The service provides better enterprise flexibility and integrates services such as email, contacts, calendar, sharing and document management plus mobility and desktop synchronization to users on any computer.
    The collaboration suite is built upon advanced web applications and the server is built on open standards and superior technologies, so as to provide unrivaled user scalability and lower overall total cost of ownership (TCO).
    The company was purchased by Yahoo! in September 2007, and subsequently acquired by VMware on January 12, 2010.
    5. IBM Lotus iNotes:
    LotusLive is a suite of business networking and collaboration cloud-based services hosted by the IBM Collaboration Solutions division of IBM. The integrated services include social networking for businesses, online meetings, file sharing, instant message, data visualization and e-mail.
    LotusLive iNotes is a web-based e-mail and calendar service. It uses the messaging assets that IBM acquired from Outblaze, a Hong Kong-based online application service provider. The service provides web based email services that equip employees with real time email access from a web browser and internet connection. In addition to a web-based interface, all e-mail accounts are enabled with POP, authenticated SMTP and IMAP capabilities for use with e-mail clients such as Lotus Notes or Microsoft Outlook.