| WDLL Studio's profileWDLL StudioPhotosBlogLists |  Tools  Help |
WDLL Studio大多数人眼中的误导也许才是真正可以引导我们的东西...... |
August 08 SOA (service-oriented architecture)SOA (service-oriented architecture)
エスオーエー / ソア / サービス指向アーキテクチャ ビジネスプロセスの構成単位に合わせて構築・整理されたソフトウェア部品や機能を、ネットワーク上に公開し、これらを相互に連携させることにより、柔軟なエンタープライズ・システム、企業間ビジネスプロセス実行システムを構築しようというシステムアーキテクチャのこと。 ここでいう“サービス”とは、ほかのコンピュータから利用可能となるようにネットワーク上にインターフェイスを公開したソフトウェアという意味とであるのと同時に、「注文受付」「信用照会」「在庫確認」「出庫指示」「請求処理」などといった“ビジネスプロセス上の処理単位”を示している。
すなわちSOAは、標準的なインターフェイスを持った再利用可能なソフトウェア部品の組み合わせによってシステムを構成するという“コンピュータシステムの作り方”であるとともに、独立して運営されるビジネスファンクションの組み合わせによってビジネスプロセスを構成するという“ビジネスシステム構築手法”という側面もあるといえるかもしれない。
全体システムを“組み合わせ”によって構築することによって、外部の“サービス”を新たにプロセスに組み込んだり、不要な“サービス”を外したりといった形で、プロセス変更が容易かつ柔軟に行えることがメリットとなる。
コンピュータシステム・アーキテクチャとしてのSOAを実践するためには、構成要素となるソフトウェア・サービスは、標準化されたインターフェイスを実装している必要がある。1企業のエンタープライズ・システムのようなクローズドなシステムであれば、社内の標準としてプロトコルやデータ形式を定めればよいが、広範な社外連携を想定するならばグローバルな標準技術を採用することになる。
その最右翼がWebサービスで、WebサービスがSOAの代名詞のように使われることもある。また、レガシーシステムのサービス化、サービス同士のビジネスプロセス制御などの機能を持つシステムインフラ製品としてEAI／BPM／ESBなどが登場している。
SOAの発展には、いくつかの段階があるとされる。第1段階はきちんと記述言語で定義されたサービスが、統一されたインターフェイスで静的に相互に接続し、イベントドリブンに動作するフェイズ、第2段階はビジネスプロセス定義に基づいてサービス同士が統合されるフェイズ、第3段階がUDDIのようなサービスブローカによって、サービス同士が動的に協調・連携する“コンポジット・アプリケーション”が実現されるフェイズだという。
ただし、SOAの厳密な意味での定義・範囲は一定ではなく、非同期、疎結合、粗粒度の分散コンポーネント・コンピューティングと同義とするものから、上記のサービスブローカによるサービスの発見メカニズムが不可欠で、単にサービス同士の接続によるシステム構築アーキテクチャは、サービスベース・アーキテクチャ（SBA）と呼び、区別すべきだとする意見もある。
ASP（application service provider）ASP（application service provider） エーエスピー / アプリケーション・サービスプロバイダ 業務アプリケーション・ソフトウェアをはじめとする各種システム機能をネットワーク経由で提供する事業者、ないしサービスのこと。また、そのようなソフトウェア提供形態（デリバリモデル）、あるいはそのようなソフトウェア・サービス提供に対価を求める事業形態（ビジネスモデル）を指す場合もある。 利用者（ユーザー企業）にとってはハードウェアやソフトウェアなどのコンピュータ資源を導入・所有しないため、初期投資なしにアプリケーションの利用を開始できる。情報システムコストが固定費から変動費になり、アプリケーション利用の中止やサービス購入先の変更も容易となる点もメリットといえる。 ASPという言葉が登場するのは1998年ごろだが、これに似たコンピュータ利用法は古くから存在したメインフレームにおけるTSSはその1つといえ、ビジネスとしては日本においても1970年代には科学技術計算や販売在庫管理などのレンタルサービスが登場、また企業の会計・税務計算などを受託した会計事務所・税務事務所向けの計算サービス（センター方式）などは広く使われた。 しかし、次第に自社にコンピュータ（日本ではオフィス・コンピュータが多かった）を導入する企業が増え、1990年代に入るとクライアント／サーバ方式で社内にシステムを構築する方法が一般的となった。 その後米国では1990年代半ばになると、業務の標準化・パッケージソフトの普及・インターネットの環境整備などの流れを受けて、再びネット経由でサービス事業者や特定企業のアプリケーションを預かって運用するホスティング事業者が登場してきた。1998年ごろからこうした事業者をASPと呼ぶようになり、1999年5月には米国に業界団体ASP Industry Consortiumが設立されている。 このようにASPはもともとは「事業者」を指していたが、今日ではむしろサービスそのもの、あるいはビジネスモデルの意味で使われる例が多くなっている。ASPインダストリアルコンソーシアム・ジャパンによるASP白書（2005年）では「特定及び不特定ユーザーが必要とするシステム機能を、ネットワークを通じて提供するサービス、あるいは、そうしたサービスを提供するビジネスモデル」としている。 従来のASPは、標準的な業務アプリケーションをノンカスタマイズで提供するものが一般的で、料金モデルもユーザー数や利用回数などによる従量課金が多かった。今後、Webサービス関連技術の標準化・SOAの考え方などにより、複数の事業者が提供するサービスを連携させて、アプリケーションとして利用するというような形態も予想されている。 August 07 GIF文件格式(二)GIF文件格式(二)
5) 局部彩色表 局部彩色表(Local Color Table)用于紧跟在它后面的图像。彩色表是否存在取决于图像描述块(Image Descriptor)中局部彩色表标志(Local Color Table Flag)位的设置。彩色表的结构和大小与全局彩色表(Global Color Table)完全相同。 6) 表基图像数据 GIF图像采用了LZW算法对实际的图像数据进行压缩。为了提高压缩编码的效率，对LZW编码器输出的代码采用可变长度码VLC(variable-length-code)，不是用位数高度的代码来表示输出，而且代表码字的位数是可变的。 表基图像数据(Table Based Image Data)由LZW最小代码长度(LZW Minimum Code Size)和图像数据(Image Data)组成，如图6-09所示。LZW最小代码长度域的值用来确定图像数据中LZW代码使用的初始位数。图像数据(Image Data)由数据子块(Data Sub-blocks)序列组成。
|
6
|
5
|
4
|
3
|
2
|
1
|
0 |
|
域的名称
|
类型
|
LZW Minimum Code Size |
|
LZW最小代码长度
| Byte
|
|
图像数据
|
Data 图6-09 图像数据的存储格式 数据子块(Data Sub-blocks)的结构如图6-10所示，这是一个可变长度的数据块，其长度由块大小域(Block Size)域中的值确定，字节数在0～255之间。
|
6
|
5
|
4
|
3
|
2
|
1
|
0
|
字节号
|
域的名称
|
类型
|
Extension Introducer
|
0
|
扩展导入符
| Byte
|
Graphic Control Label
|
1
|
图形扩展标签
| Byte |
|
|
|
|
Block Size
|
0
|
块大小
| Byte
|
<Packed Fields>
|
1
|
包装域
| See below
|
Delay Time
|
2
|
延时时间
| Unsigned |
|
|
|
|
Transparent Color Index
|
3
|
透明彩色索引
| Byte |
|
|
|
|
Block Terminator
|
0
|
块结束符
| Byte 图6-11 图像描述块的结构 (4) 包装域的结构如图6-12所示。处理方法(Disposal Method)规定图形显示之后译码器要用表6-03中所述方法进行处理。 表6-03 包装域规定的处理方法
|
处理方法
|
0
| 没有指定要做任何处理
|
1
| 不处理，图形留在原处
|
2
| 显示图形的区域必须要恢复成背景颜色
|
3
| 恢复成以前显示的图形
|
4～7
| (未定义) 用户输入标志(User Input Flag)域表示在继续处理之前是否需要用户输入响应。在延时时间(Delay Time)和用户输入标志(User Input Flag)都设置为1的情况下，继续处理的开始时间取决于用户响应输入在前还是延时时间结束在前。
图6-12 图形控制扩展块的包装结构 (5) 透明(Transparency Flag)表示是否给出透明索引(transparency index) (6) 延时时间(Delay Time)用来指定在图形显示之后继续处理数据流之前的等待时间，一百分之一秒为单位。 (7) 当且仅当透明标志位设置为1时，透明索引(Transparency Index)用来指示处理程序是否要修改显示设备上的相应象点。当且仅当透明标志位设置为1时，就要修改。 (8) 块结束符(Block Terminator)表示该图形控制扩展块(Graphic Control Extension)结束，它是由一个字节组成的数据块，该域的值是一个固定的值：0x00，因此称为零长度数据子块(zero-length Data Sub-block)。 8) 无格式文本扩展块 无格式文本扩展块(Plain Text Extension)包含文本数据和描绘文本所须的参数。文本数据用7位的ASCII字符编码并以图形形式显示。扩展块的结构如图6-13所示。
|
0
|
块大小
|
Byte
|
Text Grid Left Position
|
1
|
文本网格左列位置
| Unsigned |
|
2 |
|
|
Text Grid Top Position
|
3
|
文本网格顶行位置
| Unsigned |
|
4 |
|
|
Text Grid Width
|
5
|
文本网格宽度
| Unsigned |
|
6 |
|
|
Text Grid Height
|
7
|
文本网格高度
| Unsigned |
|
8 |
|
|
Character Cell Width
|
9
|
字符单元宽度
| Byte
|
Character Cell Height
|
10
|
字符单元高度
| Byte
|
Text Foreground Color Index
|
11
|
文本颜色索引
| Byte
|
Text Background Color Index
|
12
|
文本背景颜色索引
| Byte
|
|
无格式文本数据
|
Data Sub-blocks |
|
|
| 图6-13 无格式文本扩展块结构
9) 注释扩展块 注释扩展块(Comment Extension)域的内容用来说明图形、作者或者其他任何非图形数据和控制信息的文本信息。 注释扩展块的结构如图6-14所示。其中的注释数据是序列数据子块(Data Sub-blocks)，每块最多255个字节，最少1个字节。
|
字节号
|
域的名称
|
数据类型
|
Extension Introducer (0x21)
|
0
|
扩展导入符
| Byte
|
Comment Label (0xFE)
|
1
|
注释标签
| Byte
|
0
|
注释数据 |
|
|
|
| Data Sub-blocks |
|
… |
| |
|
N－1 |
|
|
|
块结束符
|
Byte 图6-14 注释扩展块
10) 应用扩展块 应用扩展块(Application Extension)包含制作该图像文件的应用程序的相关信息，它的结构如图6-15所示。
|
0
|
块大小
|
Byte |
|
1 |
| |
|
2 |
| |
|
3 |
|
|
Application Identifier
|
4
|
应用程序标识符
| 8 Bytes |
|
5
|
(程序名称) | |
|
6 |
| |
|
7 |
| |
|
8 |
| |
|
9 |
|
|
Appl. Authentication Code
|
10
|
应用程序识别码
| 3 Bytes |
|
11 |
|
|
需要
|
标签
|
扩展
|
版本号.
|
Application Extension(应用扩展)
|
Opt. (*)
|
0xFF (255)
|
yes
| 89a
|
Comment Extension(注释扩展)
|
Opt. (*)
|
0xFE (254)
|
yes
| 89a
|
Global Color Table(全局彩色表)
|
Opt. (1)
|
none
|
no
| 87a
|
Graphic Control Extension(图形控制扩展)
|
Opt. (*)
|
0xF9 (249)
|
yes
| 89a
|
Header(文件头)
|
Req. (1)
|
none
|
no
| N/A
|
Image Descriptor(图像描述)
|
Opt. (*)
|
0x2C (044)
|
no
| 87a (89a)
|
Local Color Table(局部彩色表)
|
Opt. (*)
|
none
|
no
| 87a
|
Logical Screen Descriptor(逻辑屏幕描述块)
|
Req. (1)
|
none
|
no
| 87a (89a)
|
Plain Text Extension(无格式文本扩展)
|
Opt. (*)
|
0x01 (001)
|
yes
| 89a
|
Trailer(文件结束)
|
Req. (1)
|
0x3B (059)
|
no
| 87a Unlabeled Blocks(无标号块)
|
Req. (1)
|
none
|
no
|
N/A
|
Logical Screen Descriptor(逻辑屏幕描述块)
|
Req. (1)
|
none
|
no
| 87a (89a)
|
Global Color Table(全局彩色表)
|
Opt. (1)
|
none
|
no
| 87a
|
Local Color Table(局部彩色表)
|
Opt. (*)
|
none
|
no
| 87a Graphic-Rendering Blocks(图像描绘块)
图6-04 逻辑屏幕描述块中的包装域结构 (2) 屏幕描述块中的第6个字节是背景颜色索引(Background Color Index)，它是彩色表的一个索引值，用来指定背景颜色。如果全局彩色表标志(Global Color Table Flag)域G＝0，这个域的值也设置为0。 (3) 像素宽高比(Pixel Aspect Ratio)域中的值是一个因数，是计算原始图像像素的宽高比的一个近似值。如果该域的值范围为1～255，如果不等于0，宽高比的近似值按下式计算： Aspect Ratio = (Pixel Aspect Ratio + 15) / 64 3) 全局彩色表 由于一个GIF文件可以包含多幅彩色图像，每幅彩色图像也许都包含适合自身特点的彩色表，所以一个GIF文件可以有好几个彩色表。但归纳起来只有两类：全局彩色表(Global Color Table)或局部彩色表(Local Color Table)。全局彩色表可用于图像本身没有带彩色表的所有图像和无格式文本扩展块(Plain Text Extension)，而局部彩色表只用于紧跟在它后面的一幅图像。在处理全局彩色表和局部彩色表时需要注意下面一些规则。 ① 如果GIF文件包含全局彩色表(Global Color Table)，而且要显示的图像本身又带有局部彩色表，那末显示该幅彩色图像时就用它自己的彩色表，而不用全局彩色表。在这种情况下，解码器就首先保存全局彩色表(Global Color Table)，然后使用局部彩色表(Local Color Table)来显示图像，最后再回复全局彩色表(Global Color Table)。 ② 全局彩色表(Global Color Table)和局部彩色表(Local Color Table)都是可选择的。由于这个原因，解码器最好要保存全局彩色表(Global Color Table)，一直到出现另一个全局彩色表(Global Color Table)为止。这样做之后，对于包含完全没有彩色表的一幅或者多幅彩色图像的GIF文件就可以使用最后保存的全局彩色表(Global Color Table)进行处理。 ③ 如果同类型的图像能够使用相同的彩色表来显示，编码器就要尽可能使用一个全局彩色表(Global Color Table)；如果没有彩色表可用，解码器就可以使用计算机系统提供的彩色表或者解码器自身的彩色表。 ④ 全局彩色表(Global Color Table)存在与否由逻辑屏幕描述块(Logical Screen Descriptor)中字节5的全局彩色表标志(Global Color Table Flag )域G的值确定。如果存在，彩色表就紧跟在逻辑屏幕描述块(Logical Screen Descriptor)之后。彩色表的表项数目等于2(n +1)，其中n=b2b1b0，每个表项由3个字节组成，分别代表R、G、B的相对强度，因此彩色表的字节数就等于3×2(n +1)。彩色表的结构如图6-05所示。
图6-07 图像描述块中的包装域结构 图像描述块(Image Descriptor)中的第9个字节称为包装域(Packed Fields)字节，它的位结构如图6-07所示，它由5个子域组成： ① 局部彩色表标志(Local Color Table Flag )域L用来说明是否有局部彩色表存在。如果L＝1，表示有一个局部彩色表(Local Color Table)将紧跟在这个图像描述块(Image Descriptor)之后;如果G＝0，表示图像描述块(Image Descriptor)后面没有局部彩色表(Local Color Table)，该图像要使用全局彩色表(Global Color Table)。 ② 交插显示标志(Interlace Flag)域I用来表示该图像是不是交插图像(Interlaced Images)。如果I＝0，表示该图像不是交插图像，如果I＝1表示该图像是交插图像。使用该位标志可知道图像数据是如何存放的。GIF文件格式定义了两种数据存储方式：一种是按图像行连续顺序存储，这个顺序与显示器上显示行的顺序相同；另一种按交插方式存储。交插图像按行分成如下所示的4组(Group)： Group 1：每隔8行组成一组，从第0行开始显示 /第1遍交插 Group 2：每隔8行组成一组，从第4行开始显示 /第2遍交插 Group 3：每隔4行组成一组，从第2行开始显示 /第3遍交插 Group 4：每隔2行组成一组，从第1行开始显示 /第4遍交插 由于显示图像需要较长的时间，使用这种方法存放和显示图像数据，人们就可以在图像显示完成之前看到这幅图像的概貌，而不觉得显示时间长。图6-08说明了这种交插图像的存储和显示顺序。
|
像 点
|
交插遍次
|
0
|
……………………………………
|
1 |
|
|
|
1
|
…………………………………… |
|
|
| 4
|
2
|
…………………………………… |
|
|
3 |
|
3
|
…………………………………… |
|
|
| 4
|
4
|
…………………………………… |
|
2 |
|
|
5
|
…………………………………… |
|
|
| 4
|
6
|
…………………………………… |
|
|
3 |
|
7
|
…………………………………… |
|
|
| 4
|
8
|
……………………………………
|
1 |
|
|
|
9
|
…………………………………… |
|
|
| 4
|
10
|
…………………………………… |
|
|
3 |
|
11
|
…………………………………… |
|
|
| 4
|
12
|
…………………………………… |
|
2 |
|
|
13
|
…………………………………… |
|
|
| 4
|
14
|
…………………………………… |
|
|
3 |
|
15
|
…………………………………… |
|
|
| 4
|
16
|
……………………………………
|
1 |
|
|
|
17
|
…………………………………… |
|
|
| 4
|
18
|
…………………………………… |
|
|
3 |
|
19
|
…………………………………… |
|
|
| 4 图6-08 交插图像显示顺序 ③ 彩色表排序标志(Sort Flag)域的含义与全局彩色表(Global Color Table)中(Sort Flag)域的含义相同。 ④ 保留(Reserved)。 ⑤ 局部彩色表大小(Size of Local Color Table)域的值用来计算局部彩色表(Global Color Table)中包含的字节数。 July 15 Base64についてBase64
インターネットメールでバイナリデータを送る場合に使用されるデータエンコード方式の1つ。 インターネットメールは、基本的に7bitのキャラクタコードからなる文字列を送受信するためのシステムとして設計されているため、バイナリコード（やShift JISやEUCなどの漢字コード）をそのまま直接送信することはできない。バイナリコード中には、メール本文のメッセージ行を区切るための特殊文字が含まれていたり、キャラクタとして利用できない多くのデータが含まれている可能性があり、そのまま送信しようとすると、途中でデータが化けたり、場合によっては、メールシステムに障害を発生させることがあるからだ。このためアプリケーションの文書ファイルデータや、GIFやJPEGなどのグラフィックスデータ、音声データなどはそのままではインターネットメールのデータとして送信できない。また、ワープロソフトの出力するテキストファイルのように、1段落が1つの文であるような長い行の文を送ろうとすると、メールシステムの制限により、途中で不要な改行などが行われてしまうことがある。 この問題を回避するには、送り手側でこうしたバイナリのデータをインターネットメールシステムが問題なく転送できるキャラクタコードのデータにいったん変換し、それを受信側で元のバイナリデータに戻せばよい。こうしたデータ変換処理がデータのエンコード化であり、Base64はこのエンコード方式の1つである。インターネットメールで使用されるバイナリデータのエンコード方式としては、ほかにもuuencodeやQuoted Printableなどがあるが、Base64は最も広く利用されている。 Base64では、元のバイナリデータの6bit分を0～63までの数値とみなし、これらにアルファベットの大文字（26文字）、アルファベットの小文字（26文字）、数字（0～9までの10文字）、記号（「＋」と「／」の2文字）の64文字に変換する。このデータ変換は、元のデータの3byte（24bit）を6bit×4とみなして、4文字に変換する。元のデータが3の倍数でない場合には、変換結果が4の倍数になるように、「＝」を1つないし2つ追加する。 このエンコード方式では、元の3byteが常に4byteに変換されるので、元のデータよりもサイズが33%程度増えることになる（たとえすべてテキスト文字の場合でも、必ず3byteが4byteに変換される）。メールシステムによっては、一度に転送できるメールサイズに制限がある場合があるので、大きなファイルを送る場合は、あらかじめ圧縮しておくか（Base64やuuencode、Quoted Printableなどエンコードには、圧縮機能は含まれていない）、複数のメールに分割して送り、受信側で復元する必要がある。
|
|
|
|
 
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Send a private message
Tell a friend
Add to My MSN
Add to your network
Sign up for alerts