SOA.WRK.

Social Service Providers: MySpace vs Facebook vs Google

MySpace fired the first shot last Thursday (5/8/08) with the "Data Availability" announcement. It plans to share with other sites its user social data, e.g., blogs, photos, TV, and friend lists. Major partners that will participate in the initial phase of this project include: Yahoo!, eBay, and Twitter.

Facebook responded the very next day (5/9/08) with an announcement of "Facebook Connect", a new feature allowing its users to connect their Facebook identity to partner sites to share social data like facebook friend lists. In the announcement, Digg was shown as a partner site that can be connected from Facebook.

Google followed up on Monday (5/12/08) with a "Friend Connect" announcement. This is a service that helps website owners to embed into their pages packaged social network functions like user registration, invitations, gallery, and reviews provided by larger social network sites as well as third-party applications built by the OpenSocial developer community.

There is not much details provided by MySapce and Facebook. Google's Friend Connect site is up with several live demo sites running. Google also provided a video showing how to add social widgets to a site.

Friend Connect is a very interesting application of OpenSocial with federated authentication services. It basically turns a social network site into a social service provider. So, instead of creating/managing your own socical network using a provider like Ning, you can just outsource this service to Google!

Google has a jump on others, but I think MySpace, Facebook, and others potential social service providers will have similar things up and running soon.

Posted at 10:55PM May 12, 2008 by tientienli in Personal  | 

Microhoo vs Googlezon: Comparing Microsoft Live Mesh with Google (App Engine + Gadgets + GData)

Over the last weekend I tried the Live Mesh tech preview, watched all related videos on channel 9, analyzed demos and example apps, and had fun tracing through the feed-based mesh object model. Overall, I think Live Mesh is a very positive step forward in advancing the web-based application architecture. To some extend, Live Mesh reminds me of features from several Google projects, e.g., Data APIs, Gadgets, and App Engine. The following is a quick comparison between Live Mesh and Google's projects.

Note 1: Live Mesh services are REST based web services that can be accessed directly from most server-side and client-side apps, not limited by the type of language, server, framework, database, and browser used.

Google has a solid web-based apps and services strategy built from its projects like GData, Gadgets, and App Engine. With popular extensions like Open Social, Google is making significant contributions to the architecture of internet-based application platform. Microsoft pushes the envelop further with Live Mesh. For example, the mesh object model clearly advanced the feed based GData model with interesting new features. How will Google respond? Maybe it will release the long-awaited Google Grid project soon.

Posted at 10:10PM Apr 30, 2008 by tientienli in Personal  | 

Live Mesh: a new component of the cloud platform

Microsoft finally announced Live Mesh publicly at the Web 2.0 conference today. There were a lot of discussions since MIX08 last month about this new mashup platform. So, I was looking forward to learn more about this project. My initial impression so far is very positive. Key features of Live Mesh include:

• Devices, e.g., pc, pda, and phones (coming), can be social networked just like people;
• Mesh objects can be shared and auto-synced on multiple devices;
• Local and remote desktops provide easy access to your social device networks (rings);
• Uses cloud storage, management, identity, and other services from the window Live Platform;

It will be interesting to find more technical details of this platform and see what types of application can be developed from it. I was told that about 100 of the 400 or so people in Microsoft's Live Platform group are working on Live Mesh. So, this must be a major component of Microsoft's cloud platform.

Posted at 09:03PM Apr 23, 2008 by tientienli in Personal  | 

Google Maps Data Collector Wiki

Great!! It's your world. Map it.

A map wiki is a great tool for collecting massive self corrected user data. The only problem I see in this case is that all the free data contributed to Google, like this, will not be free for us to use when needed. According to Google Maps Terms and Conditions:

"you may not use Google Maps in a manner which gives you or any other person access to mass downloads or bulk feeds of numerical latitude and longitude coordinates."

Posted at 08:56PM Mar 18, 2008 by tientienli in Personal  | 

The { REST + Web 2.0 + Data Mashup } vs SOA debate: Part I

OK, after repeating these arguments so many times, I decided to write this series as a reference, since some parts are still unique personal opinion.

What is SOA?

For those who are not familiar with the concept of Service-Oriented Architecture (SOA), a definition I like to use is from Wikipedia, listed somewhere in the middle of the page: (O/T: There is too much spam in this Wikipedia entry. This is a good example why Wikipedia is losing the war on spam. Just like what happen to email today.)

"SOA can be regarded as a style of information systems architecture that enables the creation of applications that are built by combining loosely coupled and interoperable services. These service inter-operate based on a formal definition (or contract, e.g., WSDL) that is independent of the underlying platform and programming language. The interface definition hides the implementation of the language-specific service."

To summarize, SOA is a style of building applications using loosely coupled and interoperable services defined by a formal contract (WSDL) that hides the underlying implementation of the service.

The service contract is the cornerstone of SOA. Most services use the Web Services Description Language (WSDL) to define service operations and associated input/output data. The service data are represented in XML messages and can be transported using HTTP or other protocols between the service provider and its consumers. The name "Web Service" is used because services are accessible from the web using the URI as service addresses.

SOA is not a new technology, but an important step in the evolution of the application composition technology. SOA has its roots in the Unix toolbox philosophy of composable programs, Remote Procedure Call (PRC), and Interface definition language (IDL). The use of XML (derived from SGML) as the data representation format is important. It allows implementation specific data binding to be decoupled from interface definition making the WSDL specification possible.

       60       70     79     80-90    96          98           01   
...coroutine...Pipe...SGML...RPC/IDL...XML...XML-RPC/SOAP...XSD/WSDL -> SOA

WSDL defines not only the operations of RPC interfaces but also message exchange patterns between the service provider and its consumers. However, WSDL cannot define a service protocol completely by itself. Other standards exist for specifying additional service aspects, e.g., the interaction sequence of a service exchange involving multiple partners.

Round 1: REST vs. SOA

In 2000, after studying the Web and other distributed system architectures, Roy Fielding defined Representational State Transfer (REST) as a set of desirable architectural constraints derived from the web. REST is an architectural style that can be applied to improve the web and build a better Internet-scale distributed software system.

The web is also not new, but a step in the evolution of the hypertext technology popularized by Douglas Engelbart and Ted Nelson in the 60s. Tim Berners-Lee implemented a networked hypertext system which he called the "World-Wide Web" in 1990. The web expanded very quickly after the introduction of popular browsers and the standardization of HTML and HTTP. Fielding participated in the web development around that time and defined REST.

        60      79        85      90        93/95           95/96   
...HyperText...SGML...HyperCard...WWW...Mosaic/Netscape...HTML/HTTP -> REST

While working on REST, Fielding examined RPC and quickly dismissed it as a different technology from the web. He stated that:

"What makes HTTP significantly different from RPC is that the requests are directed to resources using a generic interface with standard semantics..."

Fielding's argument has been used repeatedly in the REST vs. SOA debate by proponents of REST. However, according to the HTTP spec, HTTP was designed to be an application-level, generic, stateless, extensible, object-oriented protocol for transferring request/response messages between a client (browser) and the web server with possible intermediaries in the middle. HTTP defines a set of standard (remote) methods: GET, POST, and HEAD. For anyone familiar with RPC, the HTTP design is very similar to an object-oriented RPC interface with remote operations: getResouce, setResource, and isResource. I think it is valid to argue that HTTP was designed as an RPC interface. Not sure why Fielding (BTW, he is an author of the HTTP spec) changed his mind between 1995 and 2000.

Same Web, Different Views

Fielding did not discuss "XML", a word never referenced in his thesis. Consequently, technology like XML-RPC and SOAP were not considered in REST. I think Fielding, like many others, has taken a view that assumes the web is a distributed hypermedia system --- the Resource view. As the result of such an assumption, REST becomes an architecture style applicable more to the design of such systems. REST may not be appropriate for other classes of distributed client-server systems.

SOA, on the other hand, has a different view of the web. It uses the web as a distributed application infrastructure between service providers and consumers --- the Service view. For example, the semantic of HTTP methods GET/POST/HEAD can be interpreted as getServiceDefinition, postServiceRequest, and isService. This view also works well and can coexist with REST's view of the web without problems.

SOA and REST are architecture styles applicable to different application domains. It is not useful to argue which one is better without knowing the target application. REST works well with distributed resources and SOA does better with distributed services. Resource interactions are different from, but in general simpler than, service interactions.

Posted at 08:34AM Sep 20, 2007 by tientienli in Personal  |  Comments[4]

Resumed...

my last blog entry was 11 years ago on VRML... (Google still has some trace of it!!!)

Posted at 09:50PM Feb 20, 2007 by tientienli in Personal  |  Comments[0]