- Research Project: Pig Given Yahoo's usage of Hadoop it's good to see them building a query layer on top of it. And it's not SQL - hence the name - it's relationally based (it uses bags and still has DISTINCT) because that scales. Hah! Some of the documentation is gold, "In a conventional database management system, SQL queries are translated into relational algebra expressions, which are in turn translated into physical evaluation plans. Pig Latin queries are already an algebra, so we're bypassing the first layer." It even has nested relations and a flatten operation (which removes the nesting). A good read at "Yahoo Pig and Google Sawzall". Notes that Google's Sawzall looks like Scala.
- REST Compile/Describe & WADL together with I finally get REST. Wow. all link to WADL. In what seems like an age ago, I remember several enterprise architects asking what the REST equivalent to WSDL was. The later has one of the best one liners to describe REST, "state machine as node graph traversed via URI". An example of how to use is give in "REST Describe first working Beta released"
- Stavanger, oil, and the Semantic Web Talks about the "Norwegian Semantic Web Days" which covered things such as the OBO foundary.
Showing posts with label web services. Show all posts
Showing posts with label web services. Show all posts
Saturday, April 28, 2007
Planet RDF Roundup
Labels:
google,
hadoop,
obo,
rest,
sawzall,
scala,
semantic web,
web services,
wsdl,
yahoo
Monday, August 22, 2005
Things I've Read
* Evangelical Scientists Refute Gravity With New 'Intelligent Falling' Theory related to Boing Boing's $250,000 Intelligent Design challenge (UPDATED: $1 million) and Flying Spaghetti Monster.
* JUnit-Addons and GSBase so at least only two software projects have to reinvent the wheel.
* Non-blocking Data Sharing in Multiprocessor Real-Time Systems "In this paper, we present an efficient non-blocking solution to the general readers/writers inter-task communication problem our solution allows any arbitrary number of readers and writers to perform their respective operations."
* Why I Prefer SOA to REST "The problem is that although it is easy to model resources as services as shown in the example in many cases it is quite difficult to model a service as a resource. For example, a service that validates a credit card number can be modeled as a validateCreditCardNumber(string cardNumber) service. On the other hand it is unintuitive how one would model the service as a resource. For this reason I prefer to think about distributed applications in terms of services as opposed to resources." Now people can just argue about what is intuitive (credit card gateways on the Web existed before SOAP - must have been REST I guess).
* I Need a New Language: Rel? "I want a language for table programming. I think you can write programs in this language that do everything we expect of an application programming language -- building GUIs, reacting to mouse events, listening to sockets -- everything. Don't model your domain as objects. Model it as relations...I can imagine programs that have a relvar (Date's term for a relational variable: essentially a table or a view) for MouseState."
* Package Scoping And Unit Testing "Package scoping particularly shines during unit testing. Some programmers argue that you should only test through the public API. Don't be silly. Limiting your tests to the public API contradicts the spirit of unit testing and subjects you to unnecessary dependency pain. I prefer to isolate and limit the amount of code I test at one time, and test as close to the code as possible." Somewhat related, JSR 277 - Java Module System
* Web as Platform Mash-Ups "There have been a lot of excellent posts and articles this week about APIs, the Web as Platform, web sites as software companies, and so forth..."
* Ruby, Python, "Power" "There are different opinions on the relative power of Ruby and Python. I'm not much more authoritative than other resources (though I'm not less authoritative either; most comparisons between the two languages are flawed). Ultimately I don't believe there are many (any?) places where one language is more "powerful" than the other (and not just in the "they are both Turing complete" sense)"
* JUnit-Addons and GSBase so at least only two software projects have to reinvent the wheel.
* Non-blocking Data Sharing in Multiprocessor Real-Time Systems "In this paper, we present an efficient non-blocking solution to the general readers/writers inter-task communication problem our solution allows any arbitrary number of readers and writers to perform their respective operations."
* Why I Prefer SOA to REST "The problem is that although it is easy to model resources as services as shown in the example in many cases it is quite difficult to model a service as a resource. For example, a service that validates a credit card number can be modeled as a validateCreditCardNumber(string cardNumber) service. On the other hand it is unintuitive how one would model the service as a resource. For this reason I prefer to think about distributed applications in terms of services as opposed to resources." Now people can just argue about what is intuitive (credit card gateways on the Web existed before SOAP - must have been REST I guess).
* I Need a New Language: Rel? "I want a language for table programming. I think you can write programs in this language that do everything we expect of an application programming language -- building GUIs, reacting to mouse events, listening to sockets -- everything. Don't model your domain as objects. Model it as relations...I can imagine programs that have a relvar (Date's term for a relational variable: essentially a table or a view) for MouseState."
* Package Scoping And Unit Testing "Package scoping particularly shines during unit testing. Some programmers argue that you should only test through the public API. Don't be silly. Limiting your tests to the public API contradicts the spirit of unit testing and subjects you to unnecessary dependency pain. I prefer to isolate and limit the amount of code I test at one time, and test as close to the code as possible." Somewhat related, JSR 277 - Java Module System
* Web as Platform Mash-Ups "There have been a lot of excellent posts and articles this week about APIs, the Web as Platform, web sites as software companies, and so forth..."
* Ruby, Python, "Power" "There are different opinions on the relative power of Ruby and Python. I'm not much more authoritative than other resources (though I'm not less authoritative either; most comparisons between the two languages are flawed). Ultimately I don't believe there are many (any?) places where one language is more "powerful" than the other (and not just in the "they are both Turing complete" sense)"
Tuesday, July 26, 2005
APIs on REST
* XINS is a technology used to define, create and invoke remote APIs. XINS is specification-oriented. When API specifications are written (in XML), XINS will transform them to HTML-based documentation and Java code for both the client- and the server-side. The communication is based on HTTP.
* Axis 2.0 Support for REST "Axis2 can be configured as REST Cantainer and can be used to send and receive restful web services requests and responses. The REST Web Services can be access in two ways, using HTTP GET and POST."
* REST vs API "The starting point is usually that somebody has an API that is intended to shield the developer from the inner workings of SOAP and perhaps another protocol or three. The person is thinking about adding REST support (generally in the form of removing the requirement for a SOAP envelope and adding support for additional HTTP methods). What can go wrong?"
* Axis 2.0 Support for REST "Axis2 can be configured as REST Cantainer and can be used to send and receive restful web services requests and responses. The REST Web Services can be access in two ways, using HTTP GET and POST."
* REST vs API "The starting point is usually that somebody has an API that is intended to shield the developer from the inner workings of SOAP and perhaps another protocol or three. The person is thinking about adding REST support (generally in the form of removing the requirement for a SOAP envelope and adding support for additional HTTP methods). What can go wrong?"
Thursday, March 03, 2005
REST vs the Rest
Web Resources and WS-Resources " Now I can still only really talk from the point of view of first impressions, but it seems to me that the WS-Resource approach seems generally more concrete than the resource abstraction of RDF. I think it likely that WS-Resource constructs could be modelled in RDF. However, the emphasis of WS-Resource is very much on the protocol, so this isn’t really comparing like with like."
"I can see how state can be managed using WS-Resources, but what I having discovered is why the assumption is made that because SOAP++ messaging is usually done statelessly, it has to be that way. State can (and often is) maintained at both client and server sides of communications. If state that is global across client and server is needed then that can be maintained using one of the many reliable messaging protocols possible on top of HTTP."
"I can see how state can be managed using WS-Resources, but what I having discovered is why the assumption is made that because SOAP++ messaging is usually done statelessly, it has to be that way. State can (and often is) maintained at both client and server sides of communications. If state that is global across client and server is needed then that can be maintained using one of the many reliable messaging protocols possible on top of HTTP."
Thursday, February 17, 2005
Achieving WS Functionality with REST
REST design questions "REST in its now-broadened meaning is easy to explain: pieces of data (likely XML-encoded) sit out there on the web, and you manipulate them using HTTP’s GET, PUT, and DELETE methods..."
"This very simplicity should raise some alarm bells, though. RDF also has an apparently simple data model, but for RDF 1.0, at least, the model turned out to be painfully incomplete, as I found out when I implemented my RDF parsing library. Is REST hiding any of the same traps? "
REST design question #2: listing and discovering resources "The second in my series of REST design questions is how to handle listing and paging, or, in fancier jargon, resource discovery. I prefer concrete examples, so I’ll start with one that I know is flawed and then try to find ways to fix it."
"This very simplicity should raise some alarm bells, though. RDF also has an apparently simple data model, but for RDF 1.0, at least, the model turned out to be painfully incomplete, as I found out when I implemented my RDF parsing library. Is REST hiding any of the same traps? "
REST design question #2: listing and discovering resources "The second in my series of REST design questions is how to handle listing and paging, or, in fancier jargon, resource discovery. I prefer concrete examples, so I’ll start with one that I know is flawed and then try to find ways to fix it."
Tuesday, February 15, 2005
Where's the SOAP?
SOAP is boring, wake up Big Vendors or get niched "Evidence continues to mount that developers can' t be bothered with SOAP and the learning requirements associated with use of the standard for information interchange. It is often described as "lightweight", but its RPC roots keep showing.
Developers are turning their backs on the standard. Folks that is, building interesting information splicing apps--semantically rich platforms like flickr and Amazon are being accessed by RESTful methods, not IBM/MS defined "XML Web Services" calls. Now it seems the Creative Commons is responding to RESTful demand. Or more pertinently-not responding to SOAP demand because there isn't any."
"Whats a web service? Still a great question. But anyone that defines a Web Service using SOAP in the definition is missing out on where the action is. Distinctions between enterprise and "consumer" are breaking down. REST is evidently where that convergence is being played out, not WS-I."
Via Is SOAP a washout?.
Also, Interop is Hard: "If you find that you must use a toolkit to help with generating the contract, I'd recommend a technique that is similar to Steve's customer's: generate WSDL using a foreign toolkit, remove all unwarranted idioms and assumptions, and then try to import the result in the toolkit that you are using to develop the service."
Jon Udell had a very interesting post about Google's new map service (all plain XML/HTTP and XSLT where you want): Google Maps is a web of linked XML documents.
Developers are turning their backs on the standard. Folks that is, building interesting information splicing apps--semantically rich platforms like flickr and Amazon are being accessed by RESTful methods, not IBM/MS defined "XML Web Services" calls. Now it seems the Creative Commons is responding to RESTful demand. Or more pertinently-not responding to SOAP demand because there isn't any."
"Whats a web service? Still a great question. But anyone that defines a Web Service using SOAP in the definition is missing out on where the action is. Distinctions between enterprise and "consumer" are breaking down. REST is evidently where that convergence is being played out, not WS-I."
Via Is SOAP a washout?.
Also, Interop is Hard: "If you find that you must use a toolkit to help with generating the contract, I'd recommend a technique that is similar to Steve's customer's: generate WSDL using a foreign toolkit, remove all unwarranted idioms and assumptions, and then try to import the result in the toolkit that you are using to develop the service."
Jon Udell had a very interesting post about Google's new map service (all plain XML/HTTP and XSLT where you want): Google Maps is a web of linked XML documents.
Saturday, February 12, 2005
What a MEST
On Interoperability and Tim Ewald's 3 Web Services Stacks "Replacing a world of distributed applications written with DCOM, CORBA, Java RMI, etc with one where they are written using the WS-* protocols is a step in the right direction. I completely agree that it leads to better interoperability across technologies produced by the big vendors who are using incompatible technologies today.
But when your plan is to reach as many parties as possible one should favor simpler Web services technologies like plain old SOAP or just plain old XML (aka POX). Plain old XML doesn't necessarily mean following the principles of REST either."
Intersecting XML threads "What the REST vs SOAP and Doc vs RPC debates miss is the subtle point at which systems become multi-celular. At some point, evolution stopped producing organisms consisting of every bigger and bigger cells, and started producing organisms consisting of multiple differentiated cells. These cells communicate exclusively via message passing."
MEST is already omni-present, if you look for it "As far as I can tell, the basic idea behind MEST is that web services developers should be thinking about message passing instead of RPC calls. I completely agree. But I disagree with the idea that that means there should be one WSDL interface with one operation “ProcessMessage”. There's no need to go there, because we're there already."
Some of the earlier MEST postings were covered in "MEST Architecture".
But when your plan is to reach as many parties as possible one should favor simpler Web services technologies like plain old SOAP or just plain old XML (aka POX). Plain old XML doesn't necessarily mean following the principles of REST either."
Intersecting XML threads "What the REST vs SOAP and Doc vs RPC debates miss is the subtle point at which systems become multi-celular. At some point, evolution stopped producing organisms consisting of every bigger and bigger cells, and started producing organisms consisting of multiple differentiated cells. These cells communicate exclusively via message passing."
MEST is already omni-present, if you look for it "As far as I can tell, the basic idea behind MEST is that web services developers should be thinking about message passing instead of RPC calls. I completely agree. But I disagree with the idea that that means there should be one WSDL interface with one operation “ProcessMessage”. There's no need to go there, because we're there already."
Some of the earlier MEST postings were covered in "MEST Architecture".
Subscribe to:
Posts (Atom)