...you get a personal letter from the store manager at Home Depot thanking you for my business.
Well I just finished my brick/stone patio. I had a good friend with a lot of building experience layout the proper way to do things. It turned out really nice. Low and behold I got a letter from the store manager. My wife's response. Exactly how much did I spend? Too funny.
The mono project is something I have been watching but not getting involved with. It's not that I don't want to. With so much going on in our fast-moving technology space, i have had to carefully pick where I spend my time. Lately it has been about looking at whidbey, object databases, AOP and some other personal and business endeavors....Mono, although fascinating, is just too far down the list for me. When this happens I often pick up a book on the subject in order to stay abreast of the going-on. I saw this book on mono and considering reading up on it. Mono: A Developer's Notebook. Any other suggestions?
I supply WebServices in my day to day work for a number of different 3rd party vendors working in or for the Telecom and Cable industry. An advantage of using WebServices is that once a contract is defined, it is a firm contract between a supplier of a service and its clients. However, when defining a contract, it is important to model the data in business terms. If your service is just a pass-thru to a database or a set of database calls, you are missing the point to a Service Oriented Architecture and potentially harming your clients (see WOTL Blog Entry).
Your contract is more then just a set of data-types and exceptions. It is also about the data and if you do not model the data in terms of the business, then you are coupling your clients to any underlying system or database that your services is communicating/integrating. The problem with presenting a set of services that merely map directly to a database record is that if the meaning of your data changes, your clients will be ill-prepared for the change. As a writer of a service, you have a responsibility of always presenting the data in your service in terms of the business. If you are having a tough time doing this, then you should seriously look at your justification for a Service Oriented Architecture in the first place.
For example, let’s say your service is accessing a system to check on the state of an order existing in yet another system. Chances are it is an older data-driven system and it will have arcane values describing the state of an order (e.g. CP for Complete or IC for Incomplete). If you just pass these values directly back to a client then you are tying your clients to an underlying implementation of this 3rd party system that your client should really care less about. If this underlying system changes (e.g. now uses CMP for complete) or adds a new status, then all of your clients will be affected. Instead, you should define an element in your application domain for OrderStatus and then go about mapping the underlying system’s status values. If an underlying status value changes (e.g. CP==CMP), then you merely need to remap. If a new status is added, you can at the very least map it to an existing status or re-release your service with the change. Either way, you are presenting a layer of abstraction to your clients and presenting real business value.