Requirements for an Enterprise Service

re: Requirements for an Enterprise Service

Sam Judson — Tue, 12 Dec 2006 18:51:01 GMT

Very thoughtful post with lots of valid points. Well done.

re: Requirements for an Enterprise Service

Steve Rdzak — Wed, 20 Dec 2006 22:15:36 GMT

Nice take. We have the notion of Channels on our ESB where Services exposed on the Enterprise channel must have many of the characteristics you denoted. What we don't have is the built in Admin/Management operations you describe. I am going to explore that with my team. Other channels on the ESB may be private and provide for less stringent service requirements.

re: Requirements for an Enterprise Service

Benjy — Mon, 15 Jan 2007 23:08:56 GMT

Interesting post. Im developing a sort of blueprint for the internals of Business Services in my platform architecture. (The overall model follows the SOA Blueprint prescribed by OASIS, but there is no drill down guidance as to whats inside a Business Service). I think these business services map somewhat to your Enterprise Services.

I like the idea of Ping and Check. But i am not sure of the GetSupportData idea.

1 problem is security. depending on who can access that data, knowing the servers etc could pose a security risk. You dont really want people knowing whether your service accesses a particular database or whether it calls some other service do you?

Secondly, shouldnt be able to install the service on any available box as your infrastructure grows and changes so would you then impose an extra management task to update the config data ? for an ops team , they would of course have to have this stuff documented but within the service?

somewhere else, someone mentioned that the management interface to the service should be able to provide info such as audit trails, which consumer connected at what time (using certificates etc) and so on. what do you think of this?

i think it would be useful to drill down a bit deeper into the anatomy of an enterprise service. Maybe MS will provide some prescriptive guidance.? would definitely be useful.

Cheers

Benjy

re: Requirements for an Enterprise Service

NickMalik — Tue, 16 Jan 2007 11:31:16 GMT

Hello Benjy,

I grant you that the GetSupportData service should only be allowed to be called by users who perform a Support role. Therefore, if a non-support consumer were to make the call, they should get an access violation.

That said, I do think that it makes sense that a service should describe where it is installed, even if that adds the effort to change the config file when the service is installed (although a lot of support info, including the name of the server, is available through API calls). If you have a load balanced service running on four servers, and one instance is having trouble, you want to be able to isolate the instance to the specific server.

While I agree that an audit trail is necessary, I'm not sure that I would build a GetAuditTrail call into the interface of the service, or if I would have the service call a plug-in to register calls to a common infrastructure. That way, you could pass the name of the service to the audit infrastructure, and it could produce the audit trail. This is not the interesting case, however.

A central audit infrastructure can go the extra step of providing end-to-end audit, so that a sequence of calls to a series of composable services orchestrated in a process can be demonstrated in a single audit trail, allowing for not only a reliable audit but excellent information for both root cause analysis and validation of the compensation mechanism.