Tuesday, September 21, 2010

Good One by SP

Seth Priebatsch
“I had friends at Princeton; I’m sure it’d be fun to see them,” he says. “But I know that what I’m going after is huge and others are going after it, and if they’re not, they’re making a mistake. But other people will figure it out, and every minute that I’m not working on it is a minute when they’re making progress and I’m not. And that is just not O.K.”

Link to this Article

Transformational and Transactional Leaders

Scholars in organizational studies tend to divide the world into “transformational leaders” (the group that hypomanics are bunched into, of course) and “transactional leaders,” who are essentially even-keeled managers, grown-ups who know how to delegate, listen and set achievable goals.

Both types of leaders need to rally employees to their cause, but entrepreneurs must recruit and galvanize when a company is little more than a whisper of a big idea. Shouting “To the ramparts!” with no ramparts in sight takes a kind of irrational self-confidence, which is perfectly acceptable, though it can also tilt into egomania, which is usually not.

Friday, September 17, 2010

SOAP vs. REST

Web Services, Part 1: SOAP vs. REST
By Brennan Spies

* Web Services
* XML

Developers new to web services are often intimidated by parade of technologies and concepts required to understand it: REST, SOAP, WSDL, XML Schema, Relax NG, UDDI, MTOM, XOP, WS-I, WS-Security, WS-Addressing, WS-Policy, and a host of other WS-* specifications that seem to multiply like rabbits. Add to that the Java specifications, such as JAX-WS, JAX-RPC, SAAJ, etc. and the conceptual weight begins to become heavy indeed. In this series of articles I hope to shed some light on the dark corners of web services and help navigate the sea of alphabet soup (1). Along the way I'll also cover some tools for developing web services, and create a simple Web Service as an example. In this article I will give a high-level overview of both SOAP and REST.

Introduction

There are currently two schools of thought in developing web services: the traditional, standards-based approach (SOAP) and conceptually simpler and the trendier new kid on the block (REST). The decision between the two will be your first choice in designing a web service, so it is important to understand the pros and cons of the two. It is also important, in the sometimes heated debate between the two philosophies, to separate reality from rhetoric.

SOAP

In the beginning there was...SOAP. Developed at Microsoft in 1998, the inappropriately-named "Simple Object Access Protocol" was designed to be a platform and language-neutral alternative to previous middleware techologies like CORBA and DCOM. Its first public appearance was an Internet public draft (submitted to the IETF) in 1999; shortly thereafter, in December of 1999, SOAP 1.0 was released. In May of 2000 the 1.1 version was submitted to the W3C where it formed the heart of the emerging Web Services technologies. The current version is 1.2, finalized in 2005. The examples given in this article will all be SOAP 1.2.

Together with WSDL and XML Schema, SOAP has become the standard for exchanging XML-based messages. SOAP was also designed from the ground up to be extensible, so that other standards could be integrated into it--and there have been many, often collectively referred to as WS-*: WS-Addressing, WS-Policy, WS-Security, WS-Federation, WS-ReliableMessaging, WS-Coordination, WS-AtomicTransaction, WS-RemotePortlets, and the list goes on. Hence much of the perceived complexity of SOAP, as in Java, comes from the multitude of standards which have evolved around it. This should not be reason to be too concerned: as with other things, you only have to use what you actually need.

The basic structure of SOAP is like any other message format (including HTML itself): header and body. In SOAP 1.2 this would look something like










Note that the
element is optional here, but the is mandatory.

The SOAP


SOAP uses special attributes in the standard "soap-envelope" namespace to handle the extensibility elements that can be defined in the header. The most important of these is the mustUnderstand attribute. By default, any element in the header can be safely ignored by the SOAP message recipient unless the the mustUnderstand attribute on the element is set to "true" (or "1", which is the only value recognized in SOAP 1.1). A good example of this would be a security token element that authenticates the sender/requestor of the message. If for some reason the recipient is not able to process these elements, a fault should be delivered back to the sender with a fault code of MustUnderstand.

Because SOAP is designed to be used in a network environment with multiple intermediaries (SOAP "nodes" as identified by the element), it also defines the special XML attributes role to manage which intermediary should process a given header element and relay, which is used to indicate that this element should be passed to the next node if not processed in the current one.

The SOAP

The SOAP body contains the "payload" of the message, which is defined by the WSDL's part. If there is an error that needs to be transmitted back to the sender, a single element is used as a child of the .

The SOAP

The is the standard element for error handling. When present, it is the only child element of the SOAP . The structure of a fault looks like:



env:Sender

m:MessageTimeout



Sender Timeout


P5M



Here, only the and child elements are required, and the child of is also optional. The body of the Code/Value element is a fixed enumeration with the values:

* VersionMismatch: this indicates that the node that "threw" the fault found an invalid element in the SOAP envelope, either an incorrect namespace, incorrect local name, or both.
* MustUnderstand: as discussed above, this code indicates that a header element with the attribute mustUnderstand="true" could not be processed by the node throwing the fault. A NotUnderstood header block should be provided to detail all of the elements in the original message which were not understood.
* DataEncodingUnknown: the data encoding specified in the envelope's encodingSytle attribute is not supported by the node throwing the fault.
* Sender: This is a "catch-all" code indicating that the message sent was not correctly formed or did not have the appropriate information to succeed.
* Receiver: Another "catch-all" code indicating that the message could not be processed for reasons attributable to the processing of the message rather than to the contents of the message itself.

Subcodes, however, are not restricted and are application-defined; these will commonly be defined when the fault code is Sender or Receiver. The element is there to provide a human-readable explanation of the fault. The optional element is there to provide additional information about the fault, such as (in the example above) the timeout value. also has optional children and , indicating which node threw the fault and the role that the node was operating in (see role attribute above) respectively.

SOAP Encoding

Section 5 of the SOAP 1.1 specification describes SOAP encoding, which was originally developed as a convenience for serializing and de-serializing data types to and from other sources, such as databases and programming languages. Problems, however, soon arose with complications in reconciling SOAP encoding and XML Schema, as well as with performance. The WS-I organization finally put the nail in the coffin of SOAP encoding in 2004 when it released the first version of the WS-I Basic Profile, declaring that only literal XML messages should be used (R2706). With the wide acceptance of WS-I, some of the more recent web service toolkits do not provide any support for (the previously ubiquitous) SOAP encoding at all.

A Simple SOAP Example

Putting it all together, below is an example of a simple request-response in SOAP for a stock quote. Here the transport binding is HTTP.

The request:

GET /StockPrice HTTP/1.1
Host: example.org
Content-Type: application/soap+xml; charset=utf-8
Content-Length: nnn


xmlns:s="http://www.example.org/stock-service">


IBM




The response:

HTTP/1.1 200 OK
Content-Type: application/soap+xml; charset=utf-8
Content-Length: nnn


xmlns:s="http://www.example.org/stock-service">


45.25




If you play your cards right, you may never have to actually see a SOAP message in action; every SOAP engine out there will do its best to hide it from you unless you really want to see it. If something goes wrong in your web service, however, it may be useful to know what one looks like for debugging purposes.

REST

Much in the way that Ruby on Rails was a reaction to more complex web application architectures, the emergence of the RESTful style of web services was a reaction to the more heavy-weight SOAP-based standards. In RESTful web services, the emphasis is on simple point-to-point communication over HTTP using plain old XML (POX).

The origin of the term "REST" comes from the famous thesis from Roy Fielding describing the concept of Representative State Transfer (REST). REST is an architectural style that can be summed up as four verbs (GET, POST, PUT, and DELETE from HTTP 1.1) and the nouns, which are the resources available on the network (referenced in the URI). The verbs have the following operational equivalents:

HTTP CRUD Equivalent
==============================
GET read
POST create,update,delete
PUT create,update
DELETE delete

A service to get the details of a user called 'dsmith', for example, would be handled using an HTTP GET to http://example.org/users/dsmith. Deleting the user would use an HTTP DELETE, and creating a new one would mostly likely be done with a POST. The need to reference other resources would be handled using hyperlinks (the XML equivalent of HTTP's href, which is XLinks' xlink:href) and separate HTTP request-responses.

A Simple RESTful Service

Re-writing the stock quote service above as a RESTful web service provides a nice illustration of the differences between SOAP and REST web services.

The request:

GET /StockPrice/IBM HTTP/1.1
Host: example.org
Accept: text/xml
Accept-Charset: utf-8

The response:

HTTP/1.1 200 OK
Content-Type: text/xml; charset=utf-8
Content-Length: nnn



IBM
45.25


Though slightly modified (to include the ticker symbol in the response), the RESTful version is still simpler and more concise than the RPC-style SOAP version. In a sense, as well, RESTful web services are much closer in design and philosophy to the Web itself.

Defining the Contract

Traditionally, the big drawback of REST vis-a-vis SOAP was the lack of any way of specifying a description/contract for the web service. This, however, has changed since WSDL 2.0 defines a full compliment of non-SOAP bindings (all the HTTP methods, not just GET and POST) and the emergence of WADL as an alternative to WSDL. This will be discussed in more detail in coming articles.

Summary and Pros/Cons

SOAP and RESTful web services have a very different philosophy from each other. SOAP is really a protocol for XML-based distributed computing, whereas REST adheres much more closely to a bare metal, web-based design. SOAP by itself is not that complex; it can get complex, however, when it is used with its numerous extensions (guilt by association).

To summarize their strengths and weaknesses:

*** SOAP ***

Pros:

* Langauge, platform, and transport agnostic
* Designed to handle distributed computing environments
* Is the prevailing standard for web services, and hence has better support from other standards (WSDL, WS-*) and tooling from vendors
* Built-in error handling (faults)
* Extensibility

Cons:

* Conceptually more difficult, more "heavy-weight" than REST
* More verbose
* Harder to develop, requires tools

*** REST ***

Pros:

* Language and platform agnostic
* Much simpler to develop than SOAP
* Small learning curve, less reliance on tools
* Concise, no need for additional messaging layer
* Closer in design and philosophy to the Web

Cons:

* Assumes a point-to-point communication model--not usable for distributed computing environment where message may go through one or more intermediaries
* Lack of standards support for security, policy, reliable messaging, etc., so services that have more sophisticated requirements are harder to develop ("roll your own")
* Tied to the HTTP transport model

What's Next

In the next article in this series I will discuss WSDL, what contract-first web service development means, and (the dark horse) WADL. Stay tuned!

Thursday, September 16, 2010

Winning by Core Idea + Partnership - Allurent

Adobe
Adobe (www.adobe.com) is motivated by the belief that great experiences build great businesses. Adobe's software empowers millions of business users, developers, and designers to create and deliver effective, compelling, and memorable experiences - on the Internet, on fixed media, on wireless, and on digital devices.

Allurent uses Adobe technology extensively in its core product suite. Additionally, Allurent has built a prototype desktop application named Allurent Desktop Connection (ADC) which is built on the Adobe® AIR,™ platform.
Scene 7
Scene 7, an Adobe Company www.scene7.com), offers Scene7 On Demand, a hosted rich media platform to enable companies to grow revenues, enhance customer experience and cut production costs. Adobe Scene7 On Demand offers rich media solutions built on a robust, integrated technology platform for unrivaled breadth, depth, scalability and ease of ongoing rich media use.

Allurent has extended its existing partnership with Adobe Systems to resell Scene7 On Demand in North America. This reseller relationship provides online retailers with a one-stop shop for creating compelling shopping experiences that leverage the combination of Allurent's rich Internet commerce and Scene7's industry-leading Dynamic Imaging solutions.
Blueport Commerce
Blueport Commerce is the trusted provider of e-commerce technology and services to considered commerce retail chains representing over 2,100 stores and $8 Billion in sales. Created by the management team of Furniture.com, the furniture industry's leading e-commerce solution, Blueport Commerce is a one-stop shop combining a decade of experience, innovative technology and customized services to help make the considered commerce retailer's transition to e-commerce easy, worry-free and profitable. Learn more at www.blueport.com.

Blueport Commerce offers Allurent on Demand to its ecommerce clients. Allurent on Demand interactive widgets are used by Leon's, Canada's largest retailer of home furnishings, as well as Flooring America and Carpet One.
ATG
ATG (www.atg.com) makes the software that the world's largest and most prestigious companies use to create and manage highly targeted, relevant, and rewarding online marketing, sales, and service initiatives. Core to ATG's solution set is the ecommerce platform declared a market leader by both Forrester Research and Gartner. ATG powers the online business of many of the world's best known brands including: Best Buy, The Body Shop, Casual Male, Foot Locker, J.Crew, Restoration Hardware, Sephora, Target, Walgreen Company, Sharper Image, Benetton, Neiman Marcus, InterContinental Hotels Group, American Airlines, Sony Online, Hotels.com, and Mercedes Benz.

ATG and Allurent have partnered to deliver Allurent Checkout, Allurent Details, and Allurent Display as part of the ATG Commerce OnDemand platform. Through this partnership, ATG leverages Allurent's rich shopping features that highlight ATG's strong personalization and commerce capabilities.
Bazaarvoice
Bazaarvoice (www.bazaarvoice.com) develops outsourced technology, services, analytics, and expertise to encourage and harness word of mouth marketing and bring it closer to a company's brand and customer experience. The company is privately held with venture capital funding from Austin Ventures.

Allurent and Bazaarvoice cooperate in marketing and sales initiatives.
Coremetrics
Coremetrics (www.coremetrics.com) is the leading provider of online marketing and business optimization solutions. Its products help businesses increase revenues and find and retain their most profitable customers by maximizing every online interaction. More than 1,500 online brands globally, transacting more than $20 billion this year, use Coremetrics' Software as a Service (SaaS) to optimize their online marketing. The company's solutions encompass Coremetrics web analytics and integrated precision marketing applications, including search engine bid management, email targeting and cross sell recommendations to acquire customers more cost effectively, increase conversion rates, and increase lifetime customer value.

Allurent and Coremetrics cooperate in marketing and sales initiatives.
Demandware
Demandware (www.demandware.com) provides an ecommerce platform that combines full merchandising control and flexible functionality with the optimal profitability that only a Software as a Service (SaaS)-based pricing model can offer. With Demandware, retailers and manufacturers have complete control over the online brand and customer experience because they can tailor every aspect from the "look and feel" to the functionality to meet the needs of their specific customer profile. And all with a scalable architecture that provides features and functionality retailers will never outgrow.

Through its partnership with Allurent, Demandware customers can leverage Allurent's full suite of products and features improving all aspects of the online shopping lifecycle.
Endeca
Endeca's (www.endeca.com) innovative information access software powers the user experience of the world's most successful and demanding websites. More than 500 leading global organizations including Barnes & Noble, Circuit City, Discovery Communications, The Home Depot, Marriott, Newegg, Nike, Panasonic, and Walmart.com rely on Endeca to boost revenue, reduce costs and increase customer loyalty.

Allurent has partnered with Endeca to offer retailers an integrated solution that incorporates the Endeca Information Access Platform with Allurent Navigation and Allurent Details. For additional information, please visit www.endeca.com.
ForeSee Results
ForeSee Results (www.ForeSeeResults.com) is the leader in online customer satisfaction measurement, using online voice of customer data to help organizations around the globe increase sales, loyalty, recommendations, and website value. Using a proven, patented technology, ForeSee Results identifies the improvements to websites and other online initiatives with the greatest ROI. With over 28 million survey responses collected to date and benchmarks across dozens of industries, ForeSee Results offers our clients unparalleled expertise in customer satisfaction measurement and management. ForeSee Results works with clients across industries, including: retail, financial services, healthcare, manufacturing, telecommunications, and government, including clients such as Borders, Sears, Newegg, Ace Hardware, NFL, and The Finish Line.

Allurent and ForeSee Results cooperate in marketing and sales initiatives. ForeSee Results, a privately held company, is headquartered in Michigan and can be found on the web at www.ForeSeeResults.com
Omniture
Omniture (www.omniture.com) is a leading provider of online business optimization software. Omniture's software, delivered to customers through hosted, on-demand services, offers an easier and more flexible way to manage online, multi-channel and off-line business initiatives without costly investments in IT infrastructure.

As an Omniture Accredited Application Partner, Allurent's innovative e-commerce products are available for automated integration via Omniture Genesis. Companies can now use a pre-configured wizard to automate integration between Allurent's rich media products and Omniture SiteCatalyst®.

Online retailers implementing Allurent's rich commerce applications can successfully measure the ROI of e-commerce transactions that take place in Flash-based applications through the integration with Omniture SiteCatalyst.
Onestop Internet
Onestop Internet provides turn-key e-commerce services to companies on a completely outsourced basis. These services include design, fulfillment, customer service, technology, photography and marketing. Clients include Seven for All Mankind, Betsey Johnson, London Fog, J Brand, Paul Frank, Nicole Miller, True Religion Brand Jeans, lululemon athletica and Splendid, among other esteemed brands. The company is based in Rancho Dominguez, California. Please visit www.onestop.com.

Onestop Internet offers Allurent on Demand to its portfolio on ecommerce clients. The companies currently have several joint deployments underway.
PowerReviews
PowerReviews (www.powerreviews.com) is an enterprise solutions company that provides customer reviews and social-merchandising solutions to retailers, driving higher conversion and increased purchase satisfaction. PowerReviews' patent-pending PowerTagsTM technology captures customer opinions in their own words, making reviews more useful for shoppers, empowering them to make more informed and confident purchase decisions. Its customers include Staples, Toys'R'Us, the Wine Enthusiast, NetShops, Ritz Camera, the Sports Authority, and over 100 more. With the introduction of Buzzillions.com, the company has entered the consumer shopping portal market, leveraging its tag-based technology to introduce social navigation and affinity recommendations into the shopping research process for consumers.