バッチ処理時間が要件の7倍、SQL最適化から発想変えて対処
1. 届け先を管理する新設のDBサーバーで、バッチ処理時間が想定の6～7倍と判明 2. 一括ロードツールを使い、メモリー上での処理を活用して1時間以内に収めた 3. SOAサービスの粒度は、カスタマイズの手間を減らすため単純な機能単位にした 「1時間が要件のバッチ処理に当初、6～7時間もかかった。工夫を重ねて、ようやく時間内に収められた」（ヤマトシステム開発 グループソリューションカンパニー 次期NEKOプロジェクト マネージャー 田中諭氏）。 ヤマト運輸が5年ぶりの刷新を進めている基幹システム「第7次NEKOシステム」。住宅に送る「宅配」から、住宅に住む個人の都合に合わせて送る「個配」を目指したものだ。2010年9月には、送り状に記載された届け先の個人名や住所などを登録した「届け先DBサーバー」を新たに稼働させた。これまで送り状に書かれた届け先は、郵便番号など一部の情報しかシステムに登録
時代はRESTへ。SOAPの終わりを象徴する、Webサービス標準化団体のWS-Iが活動終了
SOAP、WSDL、UDDIなどを基盤とするWebサービスの標準化を行ってきた団体WS-I（Web Services Interoperability Organization）が、2002年からの約8年間の活動に幕を下ろしたことを正式に発表しました（参考：WS-I Completes Web Services Interoperability Standards Work（pdf））。 WS-Iは、WS-*と総称されるWebサービスのさまざまなプロトコル策定に取り組んできましたが、複雑すぎるといった評判がつきまとい、また策定そのものにも予想以上の時間がかかったことなどで、当初の想定ほど普及に至りませんでした。 そのSOAPに代わり、ここ数年サービス間をつなぐAPIとして存在感が高まっているのがREST（Representational State Transfer）と呼ばれるアーキテクチ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
