3

I'm currently tasked with writing a wcf service that, for now, will only used inside the company network, the problem is that I'm not sure how I should handle the operations it exposes.

The software that will use this service will have to modify similar tables in different ways. For example a table, that has columns a,b,c and d. Program X only updates columns a and b, while program Y updates b,c and d.

I feel that a generic Update method that accepts the whole record is easier to write and makes the service less bloated. But it does feel less secure, and would probably make it harder to understand for new developers.

How do I best handle these situations on a service level?

edit: Yes the tasks are in a sense unique, but the problem is that it's difficult to figure out how unique the service should be. Do I make a general service to allow access to the data, and let the details of those tasks be handled client-side? Security concerns are not that high. The biggest concern is maintainability and ease of understanding. At this moment we have 20+ databases where some of them have 100+ tables.

Improve this question
1
  • Are the two operation tasks unique? I mean what they want to accomplish. Commented Jan 25, 2011 at 14:34

2 Answers 2

Reset to default
3

In general a service should take a stateless approach.

The service is about providing access to data or manipulation of the data however it should if at all possible remain stateless. IBM has a great explanation that states...

Services should be independent, self-contained requests, which do not require information or state from one request to another when implemented. Services should not be dependent on the context or state of other services. When dependencies are required, they are best defined in terms of common business processes, functions, and data models, not implementation artifacts (like a session key). Of course, requester applications require persistent state between service invocations, but this should be separate from the service provider.

They also go on to provide an example...

Here is an example of the wrong way to define a conversation:

  • Requester: “What is Bruce’s checking account balance?"

  • Provider: "$x"

  • Requester: “And what is his credit limit?"

  • Provider: “$y"

The provider is required to remember Bruce’s account between requests, which introduces complexity into the service implementation. Stateless service design would redefine the conversation as follows:

  • Requester: “What is Bruce’s checking account balance?"
  • Provider: “$x"
  • Requester: “What is Bruce’s credit limit?"
  • Provider: “$y"

As you can see there are existing approaches for dealing with an SOA architecture. In addition make a focused effort on defining the interface with longevity in mind. A rapidly changing API makes it much more difficult on a developer then coming up to speed on a more difficult yet stable API.

Improve this answer
0

Performance may be a concern, so the size of the record data may be a consideration.

Does the consumer need the data, are there any security concerns?

Improve this answer

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.