SOA: Is it preferable to implement a service instead of just writing service-ready code, when no external access is needed?

Generally speaking you'd be better to wait.

Generally speaking you'd be better to wait. You could design and implement a web service which was simply a technical facade that exposes the underlying functionality - the question is would you just do a straight one for one 'reflection' of that underlying functionality? If yes - did you design that underlying thing in such a way that it's fit for external callers?

Does the API make sense, does it expose members that should be private, etc. Another factor to consider is do you really know what the callers of the service want or need? The risk you run with building a service is that (as you're basically only guessing) you might need to re-write it when the first customers / callers come along. This can could result in all sorts of work including test cases, backwards compatibility if it drives change down to the lower levels, and so on.

Having said that the advantage of putting something out there is that it might help spark use of the service - get people thinking - a more agile principled approach.

If your application is an isolated Client type application (a UI that connects to a service just to get data out of the Database) implementing a SOA like architecture is usually overkill. Nevertheless there could be security, maintainability, serviceability aspects where using web services is a must. E.g.

Some clients needs access to the data outside the firewall or you prefer to separate your business logic/data access from the UI and put it on 1 server so that you don’t need to re-deploy the app every time some bus. Rules changes. Entreprise applications require many components interacting with each other and many developers working on it.In this type of scénario using SOA type architecture is the way to go.

The main reason to adopt SOA is to reduce the dependencies. Enterprise Applications usually depends on a lot of external components (logic or data) and you don’t want to integrate these components by sharing assemblies. Imagine that you share a component that implements some specific calculation, would you deploy this component to all the dependent applications?

What will happen if you want to change some calculation logic? Would you ask all teams to upgrade their references and recompile and redeploy their app? I recently posted on my blog a story where the former Architect had also choosed not to use web services and thought that sharing assemblies was fine.

The result was chaos. Read more here.

Thanks, the article was informative. However, as mentioned, the application does not have any external users or integration needs.. at launch, it will be the only application. I take it that this situation would fall under the "overkill" you described?

– roberttdev Apr 5 at 20:30.

As I mentioned, it depends on your requirements. If it’s a monolithically application and you’re sure you’ll never integrate this app and that you’ll never reuse the bus. Logic/data access a 2 tier application (UI/DB) is good enough.

Nevertheless this is an Architectural decision and as most of the architectural decisions it’s costly to change. Of course you can still factor in a web service model later on but it’s not as easy as you could think. Refactoring an existing app to add a service layer is usually a difficult task to accomplish even when using a good design based on interfaces.

Example of things that could go wrong: data structure that are not serializable, circular references in properties, constructor overloading, dependencies on some internal behaviors….

I cant really gove you an answer,but what I can give you is a way to a solution, that is you have to find the anglde that you relate to or peaks your interest. A good paper is one that people get drawn into because it reaches them ln some way.As for me WW11 to me, I think of the holocaust and the effect it had on the survivors, their families and those who stood by and did nothing until it was too late.