My experience causes me to agree with all of your points. Some of your points are a little more relevant to my short situation and some will be more relevant in the longer term.
For short term, my main source of pain relates to your "Tier 2" communications scenarios when I find that I need to provide the facilities for a close business partener/consumer of my service's functionality in a way to tell my services how they need the message to be processed via their context. This can be done in many ways, each still results in at least some level of coupling and or a somewhat RPC style/chatty level of communications. 1)The consumer must supply contextual info directly within the request message. 2) The consumer must know about and make additional services calls in order to obtain context specific info only known by the producer prior to working with the main operation(s) of the service. 3) The consumer must know and complete an agreed to sequence of steps to complete a conversation. For these types of issues, I still have problems feeling my way along the rules of thumb that will lead to a good design. e.g. at what point is an operation too general. How do I work with consumers that require my internal data in order to work with my main operations (things like internal entity identifiers or as you noted agreed upon standards) In the not so long term, I see "Tier 3" communications in my enterprise and I too have been moving towards looking at using BizTalk in conjunction with Indigo for its business process control capabilities. Unfortunetly, the Indigo stack will not be fully integrated with BizTalk until version 2006. So I might have to work with these toolsets in more of a hybrid/custom approach until BizTalk and Indigo are fully integrated. =================================== This list is hosted by DevelopMentor® http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com
