Monday, July 30, 2007

Where to start with services

If you ask 100 people what they mean by SOA applications you'll probably get 100 different answers. However, there are some common requirements:

i) they should scale from several to hundreds and thousands of participants/services.
ii) they should be loosely coupled, so that changes of service implementation at either end of an interaction can occur in relative isolation without breaking the system.
iii) they need to be highly available.
iv) they need to be able to cope with interactions that span the globe and have connectivity characteristics like the traditional Web (i.e., poor).
v) asynchronous (request-request) invocations should be as natural as synchronous request-response.

Scalability and availability are possible with other technologies, such as CORBA. Although (ii) and (iv) can certainly be catered for in those technologies as well, the default paradigm is one based on an implementation choice: objects. Objects have well defined interfaces and although they can change, the languages used to implement them typically place restrictions on the type of changes that can occur. Now although it is true that certain OO architectures, such as CORBA, allow for a loosely coupled, weakly types interaction pattern (e.g., DII/DSI in the case of CORBA), that is not typically the way in which applications are constructed and hence tool support in this area is poor.

There is no objective way in which to approach the question of whether SOAs can be catered for in traditional environments. The answer is obviously yes, because no new language has been invented for SOAs and current tools are used to develop them. However, the real question is what is the best paradigm in which to consider an SOA that allows it to address all 5 points above.

Concentrating on the message and making it the central tenant of the architecture is the key to addressing the 5 points. How this is mapped onto a logical architecture (objects, procedures, etc.) and ultimately onto a physical implementation (objects, methods, state, etc.) is not important. The fact is that many different implementations and sub-architectures could be used. So what is the fundamental concept or mind-set in which to work when considering SOA?

The answer is that this is not about request-response, request-request, asynchrony etc. but it's about events. The fundamental SOA is a unitary event bus which is triggered by receipt of a message: a service registers with this bus to be informed when messages arrive. Next up the chain is a demultiplexing event handler (dispatcher), that allows for sub-services (sub-components) to register for sub-documents (sub-messages) that may be logically or physically embedded in the initially received message. This is an entirely recursive architecture.

JBossESB does not impose restrictions on what constitutes a service. The ideal SOA infrastructure encourages a loosely coupled interaction pattern between clients and services, where the message is of critical importance and implementation specific details are hidden behind an abstract interface. This allows for the implementations to change without requiring clients/users to change. Only changes to the message definitions necessitate updates to the clients.

As such, JBossESB uses a message driven pattern for service definitions and structures: clients send Messages to services and the basic service interface is essentially a single doWork method that operates on the Message received. Internally a service is structured from one or more Actions, that can be chained together to process incoming the incoming Message. What an Action does is implementation dependent, e.g., update a database table entry, or call an EJB.

When developing your services, you first need to determine the conceptual interface/contract that it exposes to users/consumers. This contract should be defined in terms of Messages, e.g., what the payload looks like, what type of response Message will be generated (if any) etc.

Clients can then use the service as long as they do so according to the published contract. How your service processes the Message and performs the work necessary, is an implementation choice. It could be done within a single Action, or within multiple Actions. There will be the usual trade-offs to make, e.g., manageability versus re-useability.

4 comments:

sexy11 said...

情趣用品,情趣用品,情趣用品,情趣用品,情趣用品,情趣用品,情趣,情趣,情趣,情趣,情趣,情趣,情趣用品,情趣用品,情趣,情趣,A片,A片,情色,A片,A片,情色,A片,A片,情趣用品,A片,情趣用品,A片,情趣用品,a片,情趣用品

A片,A片,AV女優,色情,成人,做愛,情色,AIO,視訊聊天室,SEX,聊天室,自拍,AV,情色,成人,情色,aio,sex,成人,情色

免費A片,美女視訊,情色交友,免費AV,色情網站,辣妹視訊,美女交友,色情影片,成人影片,成人網站,H漫,18成人,成人圖片,成人漫畫,情色網,日本A片,免費A片下載,性愛

情色文學,色情A片,A片下載,色情遊戲,色情影片,色情聊天室,情色電影,免費視訊,免費視訊聊天,免費視訊聊天室,一葉情貼圖片區,情色視訊,免費成人影片,視訊交友,視訊聊天,言情小說,愛情小說,AV片,A漫,AVDVD,情色論壇,視訊美女,AV成人網,成人交友,成人電影,成人貼圖,成人小說,成人文章,成人圖片區,成人遊戲,愛情公寓,情色貼圖,色情小說,情色小說,成人論壇


av女優,av,av片,aio交友愛情館,ut聊天室,聊天室,豆豆聊天室,色情聊天室,尋夢園聊天室,080聊天室,視訊聊天室,080苗栗人聊天室,上班族聊天室,成人聊天室,中部人聊天室,一夜情聊天室,情色聊天室,情色視訊

A片,A片,A片下載,做愛,成人電影,.18成人,日本A片,情色小說,情色電影,成人影城,自拍,情色論壇,成人論壇,情色貼圖,情色,免費A片,成人,成人網站,成人圖片,AV女優,成人光碟,色情,色情影片,免費A片下載,SEX,AV,色情網站,本土自拍,性愛,成人影片,情色文學,成人文章,成人圖片區,成人貼圖

sex999 said...

A片,A片,情色,情色,A片,A片,情色,情色,A片,A片,A片下載,做愛,成人電影,.18成人,日本A片,情色小說,情色電影,成人影城,自拍,情色論壇,成人論壇,情色貼圖,情色,免費A片,成人,成人網站,成人圖片,AV女優,成人光碟,色情,色情影片,免費A片下載,SEX,AV,色情網站,本土自拍,性愛,成人影片,情色文學,成人文章,成人圖片區,成人貼圖

美女交友,AIO交友愛情館,AIO,成人交友,視訊交友網,視訊交友,拓網交友,PC交友,視訊交友90739,交友,情色交友,聊天室交友,辣妹視訊,視訊辣妹,美女視訊,視訊美女,情色視訊,日本AV,免費視訊聊天,視訊聊天,AV女優,AV,視訊聊天室,視訊,免費視訊,情人視訊網,本土自拍,自拍,AVDVD,SEX,微風成人,微風論壇,微風成人區,成人網站,成人,成人電影,嘟嘟成人網,成人貼圖,成人影片,成人圖片區,成人圖片,18成人,成人小說,成人影城,成人文章,成人論壇,愛情公寓,情色論壇,情色,色情聊天室,色情,情色貼圖,情色文學,色情小說,情色小說,寄情築園小遊戲,色情遊戲,情色電影,情色網,做愛,UT聊天室,聊天室,聊天,哈拉聊天室,豆豆聊天室,尋夢園聊天室,聊天室尋夢園,080苗栗人聊天室,苗栗人聊天室,080中部人聊天室,080聊天室,中部人聊天室,柔情聊天網,6K聊天室,小高聊天室,上班族聊天室,免費A片,A片,成人聊天室,一夜情聊天室,情色聊天室,色色網,免費AV

eda said...

情趣按摩棒,自慰套,角色扮演,按摩棒,跳蛋,跳蛋,
.,.,

情趣,性感丁字褲,情趣,角色扮演服,吊帶襪,丁字褲,情趣用品,跳蛋,男女,
潤滑液,SM,內衣,性感內衣,自慰器,充氣娃娃,AV,
按摩棒,電動按摩棒,飛機杯,視訊,自慰套,自慰套,情趣用品,情趣內衣,

dfadf said...

i like it
Microsoft Office 2010
Office 2010
Office 2007
Microsoft Office 2007
Microsoft Office
Windows 7
Microsoft outlook
Outlook 2010
Microsoft outlook 2010