Welcome to Windows CardSpace
Tasks :

Windows CardSpace Team Bloggers

Browse by Tags

All Tags » Performance » Service Orientation   (RSS)

  • Where do I stand today on ESB and the mythical "successful big project"?

    I received an email from a long-time follower of my blog that I thought might serve to spark a little interesting debate and also serve as a marker in time for my opinions on the subject of ESB and the ever elusive "successfully delivered big project": Hi Rich- Followed your blog from loosely coupled. I am reading these thoughts about the ESB from your post and the loosely coupled post, right around the same time, I had been pushing the same thoughts at various Government of <country> project that I was involved with....somehow "figure stuff out first, build some stuff, and then worry about all this big infrastructure stuff" just does not appeal to people. Hence I have seen two rather large ESB projects crumble under the weight of the huge initial investment and the lack of interest from would-be users. So I am interested in finding out....2 years after your "debate" with Dave Chapell [ part1 , part 2 ], where do you think the ESB situation is? Are the WS-* standards that mature yet? I am once again on a similar path, preaching the same message... Would love to hear where you are with the ESB stuff now? --cheers <name> <name>@<domain>.com SOA Architect To be honest, I don't see any change in my perception on this matter because my beliefs back then were based on painful experience. I haven't yet seen any revolutionary improvement in the way projects are executed that leads me to believe that someone has thought up a significantly "better way". This is largely Read More...
  • How Granular Should My Services Be?

    This is a) a very common question, and b) very hard to provide absolute prescriptive guidance on. In short, this is where the “art” of architecture & design comes into play! How granular you make your service largely depends on how you’ll use it. Always bear in mind, however, that you should avoid traversing the wire as much as possible. Therefore, if you design your service so that you have to call 10 actions in order to refresh a customer data page, then you’ll likely experience severe perf and scale issues. A better approach is to call one GetCustomerData(…) method once and build the customer data page from the returned data. “Ah, but my service has to be used by many callers – some require a great deal of customer data, but many only need the name of the customer”. In which case, your service should expose BOTH fine-grained and large-grained actions: [ServiceContract] class Customer { // Only returns customer name. [OperationContract] string GetCustomerName(Uuid customerID) { /* implementation */ } // Only returns customer address. [OperationContract] CustomerAddress GetCustomerAddress(Uuid customerID) { /* implementation */ } // Large-grained customer record retrieval. [OperationContract] CustomerRecord GetCustomer(Uuid customerID) { /* implementation */ } // Large-grained customer record update – note that this is one-way!! [OperationContract(IsoneWay=true)] Void UpdateCustomer(Uuid customerID, CustomerRecord customerRec) { /* implementation */ } } Note that when using Read More...

Copyright © 2006 Microsoft Corporation. All Rights Reserved. | Terms of Use | Privacy Statement | Contact Us