mmmm, I'd be very wary of doing this. This kinda of "data" or "infrastructure" level service often devolves into a service that can accept SQL or lands up exposing the oddities of the DB anyway. Because they are low-level they also tend to be very chatty and performance goes right out the window. They probably should be an anti-pattern.
If you image a pyramid of service types:
Business Process
Business Operation
Component
Infrastructure/Data
Then you want to shoot for building "Business Operation" type services. These give you the maximum reuse in an enterprise as they encapsulate a useful atom of business functionality. They hide the complexity of an enterprise's IT systems from consumers and typically use semantics that are business not IT system specific. For example CreateOrder, CreateCustomer etc...
Component services are the other useful one. Typically used to wrap a system with web services. This eases integration and allows for aggregation of these services into Business Operation services.
For instance the CreateCustomer service above might call CreateCustomer in System A, RegisterMember in System BB and write a record into a the Users table of System C (sometimes its impossible/cheaper not to use web services).
As for as the consumer (the helpdesk app, the self service portal etc.) is concerned they just created a Customer within the business and they don't need to know anything about Systems A, B and C.
If you image a pyramid of service types:
Business Process
Business Operation
Component
Infrastructure/Data
Then you want to shoot for building "Business Operation" type services. These give you the maximum reuse in an enterprise as they encapsulate a useful atom of business functionality. They hide the complexity of an enterprise's IT systems from consumers and typically use semantics that are business not IT system specific. For example CreateOrder, CreateCustomer etc...
Component services are the other useful one. Typically used to wrap a system with web services. This eases integration and allows for aggregation of these services into Business Operation services.
For instance the CreateCustomer service above might call CreateCustomer in System A, RegisterMember in System BB and write a record into a the Users table of System C (sometimes its impossible/cheaper not to use web services).
As for as the consumer (the helpdesk app, the self service portal etc.) is concerned they just created a Customer within the business and they don't need to know anything about Systems A, B and C.