Thursday, January 17, 2008

Tooling and governance

All good SOA platforms need a good SOA governance solution. Governance covers a number of factors and interacts at different levels of the SOA architecture. For example, there are tooling requirements (displaying the important information, customizing the view on the data, etc.) and infrastructure support (for enforcing SLAs, checking when they are [about to be] violated, etc.) The best governance implementations will perform well across these levels. However, you shouldn't be persuaded just by the gloss of a governance solution: don't judge a book by its cover.

So far we've been concentrating on the low-level infrastructure support for governance, both with JON and more native support within the ESB and other projects. Plus, from the start we've made the registry (UDDI in our case) a central component within the ESB. Plus, the Drools team have been making waves with their BRMS implementation, which is important in governance too. And of course there's the tried and tested jBPM Graphical Process Designer (not directly related to governance, but definitely to tooling) and our friends from MetaMatrix. However, what we haven't been able to do until now is discuss where we are going (both with in-house development as well as with partners).

As well as tools from the individual projects within the SOA Platform, here is a brief synopsis of architectural requirements on SOA-P specific tooling and governance. I don't want to go into details about how these tools (and the necessary supporting infrastructure) are implemented. Depending upon the role of the user or component (more in another posting) it makes more sense for some of them to be Eclipse based, whereas others will be Web console based. There will be some tools that ideally would have representations in both arenas. It's important to realise that some of the capabilities I'm going to mention will have to be duplicated across different tooling environments. For instance, sometimes what a sys admin needs to do is also what a developer needs to do (e.g., inspect a service contract). We won't require the sys admin to have to fire up the developer tool in order to do that. And vice versa.

Governance of SOA infrastructures is critically important. If any of you have tried to manage distributed systems in a local area before, you'll understand how difficult that can often be. Imagine expanding that so it covers different business domains where you (the developer or deployer) do not control all of the underlying infrastructure and cannot work on the assumption that people are trustworthy. With SOA governance, there is a runtime component that executes to ensure things like SLAs are maintained, but there is also a tooling component (runtime for management and design time).

With the JBoss governance/tooling effort, you'll be able to graphically display:


  • MTTF/MTTR information on behalf of specific nodes and services on those nodes. Also for all nodes and services that are deployed.

  • throughput for services.

  • time taken to process specific types of messages (e.g., how long to do transformations, how long to do transformations on behalf of user X).

  • number of requests services during the lifetime of the service/node (in general, it is always important to distinguish between services and the nodes on which they execute).

  • number of faults (service/node) in a given duration.

  • information about where messages are being received.

  • information about where messages are being sent (responses as well as faults).

  • potential dependency tracking data. This can be used to determine sources of common failure. Can also be used when deciding whether or not (and where) to migrate services, for improved availability or performance.

  • what versions of services exist within a specific process (VM).

  • Includes sending probe messages that can test availability and performance on request. However, this functionality needs to be duplicated into the design-time tooling.


Note, you can do some of this with the current releases!

All of this information may be obtained periodically from a central (though more realistically a federated) data store or direct from the services themselves. However, both sys admins and developers (more of them later) will need to be able to connect to services (and composites) and inspect their governance criteria, e.g., when was the last time they violated a contract, why and under what input messages/state, at will: the dynamic factor is incredibly important. This information needs to be made available across individual services as well as the entire SOA-P deployment.

Going back to what I mentioned earlier about governance. We're working on a separate and dedicated governance console that is used to receive alarms/warnings when contracts/SLAs are violated or close to being violated. Obviously the console is only one such destination for these alerts: sys admin inboxes are just as important. However, that's where the infrastructure comes into play: remember that JBossESB has a very flexible architecture.

Traditional management tooling (e.g., via JMX) would include:

  • start/stop a service.

  • suspend/resume a service.

  • add/update restriction lists for services. This limits the list of receivers that a service considers valid and will process messages from. A similar list of destinations for responses will exist. This plays into the role/relationship concept because although a developer may not consider the issue of security (maybe can't, given that services could be deployed into environments that did not exist when the developer was building the service), the sys admin (or service container admin) will have to.

  • migrate services (and potentially dependent services).

  • inspect service contract.

  • update service definition.

  • attach and tune specific service parameters.


Design time tooling includes:

  • defining the service definition/contract, which includes specifying what message types it allows. This is tied into the service implementation in order that the ESB infrastructure can verify incoming messages against this contract for validity. Part of the contract will also include security and role information which will define who can interact with the service (may be fine grained based on time of day, specific message type, etc.) Policies are attached at this level on a per service or per operation basis (if not defined on an operation basis, the service level policy is taken if defined).

  • policy definition/construction, tracking and enforcement. Not just part of the development tool, but also an integral part of the underlying ESB infrastructure. Policies need to be shared so that other developers can utilise them in their own service construction. Typically these will be stored in the repository.

  • service construction from other services, i.e., composite services. This has an input on SLA and on governance enforcement. In some cases a physical instance of the service may not exist either and the infrastructure becomes responsible for imposing the abstraction of a service by directing interactions accordingly.

  • inspecting the registry and repository during design time to locate and inspect desired services for composition within applications. Also ties into runtime management so that the user can inspect all running services. This would also tie into our graphical process flow tool, by allowing a drag-and-drop approach to application construction.

  • service development then into service deployment. The tool will allow the user to view a list of available nodes and processes. The availability, performance etc. of those nodes will also be displayed (more tooling and infrastructure support). Then you can drag a service implementation on to the node and deploy it, either dynamically or statically. This ties into the runtime management tool that allows the user to view deployed services on nodes (see previously).



Service implementation tool:

  • from the client perspective you go to the registry and select the right service based on requirements (functional as well as non-functional). The associated contract defines the message format, as mentioned earlier. The tool will either auto-generate an appropriate stub for the client code or provide a way of tying state variables (from the application code, or incoming messages etc.) in to the outbound invocations on the service. Fairly obviously we cannot prevent developers from ignoring the design-time tools and coding their applications without that support, which is really where the need for stubs comes in. At the tooling level, we're really looking at defining client tasks that the developer writes and defines the output instance variables that are hooked into the service's input variables. As far as the client tool is concerned, we are simply tying together these variables. Under the cover, the tool generates the right set of service-specific messages. The ESB infrastructure sends and receives and dispatches accordingly. Capabilities such as security and transactions may be exposed to the client.

  • from the service developer perspective, we are defining services as compositions of tasks, actions, dispatchers etc. In the graphical designer we specify the input variables that are required for each operation type (defined as specific messages). This also plays into the contract definition effort mentioned earlier, since the message formats accepted by a service are implicitly defined by the requirements on input state variables.

  • there's a separate discussion to be had about the term "task". The OPENflow work that originated within Arjuna can help here.

  • WS-CDL tooling here as well.

  • the need to be able to deploy services into a virtual environment to allow it to be tested without affecting a running system. A service has to be able to be deployed in a test mode. What this means is that at a minimum the service is not available to arbitrary users. Test services should also not be deployed into a running process/container that is being used by other (non-test) services and applications in case they cause it to fail and, worst case scenario, take the entire process with them.


Some things that I have not had a chance to write up yet include roles and relationships between roles, and (related) security and ACLs. Task definitions (lots of notes on that). Diagrams illustrating the kinds of things I want to see. So expect more later.

9 comments:

Anonymous said...

governance, you keep using that word. I do not think it means what you think it means.

Unni Vemanchery Mana said...

Will JBoss DNA try to achieve what is mentioned here or JBOSS DNA is the tool for SOA governance ?

Mark Little said...

anonymous: I know I have enough experience to know what governance means. Thanks.

Mark Little said...

JBossDNA will be a core part of the governance solution from us, but governance is more than just a repository. Take a look at labs.jboss.com/soag for more information.

wholesale air jordan said...

wholesale shoes
Shoes wholesale
wholesale designer shoes
wholesale athletic shoes
wholesale jordans shoes
wholesale nike
wholesale sandals
wholesale purses
wholesale clothing
wholesale flip flops

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成人網,成人交友,成人電影,成人貼圖,成人小說,成人文章,成人圖片區,成人遊戲,愛情公寓,情色貼圖,色情小說,情色小說,成人論壇

情色貼圖,色情聊天室,情色視訊,情色文學,色情小說,情色小說,色情,寄情築園小遊戲,情色電影,色情遊戲,色情網站,聊天室,ut聊天室,豆豆聊天室,美女視訊,辣妹視訊,視訊聊天室,視訊交友網,免費視訊聊天,免費A片,日本a片

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

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

mithun said...

Great post with lots of really good information!


Construction Tools