1) Скрапим страницу
2) Парсим ее
3) Впихиваем ее в свою БД
4) Отображаем на свое сайте
Нет у них никаких API, разумеется.

Ну это сложный вопрос. Я ж не разработчик этой системы. Но вы будете смеяться - я сейчас делаю точно такой же проект, но по другой тематике. Точнее пока что проектирую, до разработки дело еще не дошло. Проблем возникает много - как поддерживать актуальность, как правильно инкрементально выгружать данные с сервера, как регулировать нагрузку, как вовремя заметить изменение верстки и т.д.. Это все интересно, но не просто (но с другой стороны и не rocket science )
Какие тут могут быть варианты? Самый простой - опрашивать страницы с какой-то периодичностью и смотреть на HTTP код. Получили 404 - значит объявы больше нет.

LeonidvУ вас ручной разбор планируется? Мы пытались так делать (только у нас задача в чем-то проще, в чем-то сложнее), в итоге не взлетело. Хотя тут от количества сайтов зависит - если речь о десятках, то прокатит и ручной разбор. У нас более 5000 сайтов в системе добавлено было, в итоге ручной разбор себя не оправдал.Не совсем понял, что значит ручной разбор. Если вы имеете ввиду "под каждый сайт свой парсер", то да - делаю так. Сайтов у нас не очень много, сейчас около 10, в перспективе не более 50.

LeonidvМне кажется, сделать автоматический парсер для специфичной области должно быть не очень сложно. Хотя сам такого не делал, возможно задача окажется сложнее, чем кажется. Если у вас есть возможность выделить человека на направление авт. извлечения данных - я бы советовал его развивать.Ну тут как посмотреть. Проблема в том, что информация неструктурирована. То есть тут во-первых РСУБД не очень подходит, во вторых надо уметь извлекать кучу атрибутов из plain text. Например, написал кто-то в описании "цвет - металлик,2009гв,без докум.", и из этого надо понять, что продавец выставил ворованную тачку цвета металлик 2009 года выпуска
Этот момент сейчас главная проблема для меня.

Leonidvsvenom,
Кстати, вы какие библиотеки/фреймворки планируете использовать?Да пока это все открытый вопрос. У меня в любом случае все будет закрыто своими интерфейсами, так как проект обещает быть крайне нагруженным, а потому и надо при необходимости суметь махнуть РСУБД, быстро поменять, скажем Хибер на iBatis или вообще мигрировать на NoSQL. Так что пока все вопросы по либам открыты.
Отправная точка у меня такая:
- парсинг HTML страниц делаю сам; сторонние решения есть, может быть приду постепенно к ним, но пока и руками нормально получается - достаточно быстро, производительность пока устраивает;
- индексация - Lucene
- БД бизнес-данных - пока Cassandra
- анализ текста - ХЗ, пока что темный лес для меня

LeonidvsvenomНе совсем понял, что значит ручной разбор. Если вы имеете ввиду "под каждый сайт свой парсер", то да - делаю так. Сайтов у нас не очень много, сейчас около 10, в перспективе не более 50.
Ага, именно это. У вас парсеры в коде прошиты? У нас они хранились в СУБД и тех. персонал забивал данные. Но повторюсь, у нас объемы были другие.Ну у меня там принцип такой. Работа с каждым сайтом - это отдельные процессы. Они конфигурируются через базу данных, эдакая metadata-driven система. Каждый процесс состоит из ряда активностей. Например, выгрузка обычного объявления это:
[HTTP активность] -> [Parse-активность(и)] -> [Сохранить одну запись в БД]
Если же надо получить страницу и выдрать из нее другие ссылки (ну т.е. мне надо, например, из форума Java получить ссылки на все топики), то это уже другой парсинг и другое сохранение в БД.
Все это описывается в БД, у каждой активности свои конфиги то же в БД. Так что что-то вынесено в БД и конфигурируемо, что-то жестко вбито.

Leonidvsvenom во вторых надо уметь извлекать кучу атрибутов из plain text. Например, написал кто-то в описании "цвет - металлик,2009гв,без докум.", и из этого надо понять, что продавец выставил ворованную тачку цвета металлик 2009 года выпуска
Этот момент сейчас главная проблема для меня.Насколько я понимаю, ничего умнее поиска слов рядом (т.е. смотри цвет - значит за этим идет цвет) не придумать. Плюс проверка, что данные лежат в нужном диапазоне.
Еще на nutch и solr посмотрите.Да средства есть - http://en.wikipedia.org/wiki/Information_extraction
Вопрос в том - насколько качественно они будут работать с кириллицей. Ну еще не дошел я до этого места, так что пока не хочу забиваться себе голову всякими Марковскими моделями

OOsalivansvenom,
Т.е. в вашем проекте нужно прочекать каждое объявление с сайта. Допустим на примере сайта бибика - мы должны посылать запрос к серверу модифицируя юрл http://www.bibika.ru/card.php?gidcar=2516998&car=%C7%C0%C7+1102+used+car, чтобы он выдавал очередную машину. Какой алгоритм формирования очередного ЮРЛ , и когда мы должны остановиться, и получаеться что мы когда обнавляем свою базу должны выполнить тысячи запросов к исходному серверу откуд черпаем данные?Да, все верно. Условно говоря - есть страницы с объявлениями, а есть страницы со ссылками на объявления. Я иду в цикле по таким страницам и выдираю из них ссылки, потом иду по ссылкам.
Вопрос "как сформировать строку" - как нафантазируете. Я просто конкатенирую постоянные и изменяющиеся части.
Как остановиться - тут однозначного ответа нет. Можно просто идти до тех пор, пока не встретится 404. Можно идти до тех пор, пока не достигните определенного количества выдранных ссылок, которые уже были у вас в базе. Можно идти вперед - из настоящего в прошлое, можно идти из прошлого в настоящее. В общем вариантов обработки масса - тут все зависит от ваших требований.

Petro123OOsalivan,
Нет. Поисковый робот так не ходит. А у него немого сайтов и Ручной режим.Ну тут как бэ поискового робота и нет. Такие штуки именуются scrapper'ами.