I've been working with web services/SOA for about a year now. I've been trying to keep a watchful eye on the overall issues I've encountered and how they effect SOA design; or an attempt at SOA design. One thing that has become very apparent over the last year is that it seems that there is a very difficult to manage line between service orientation and just plain old (somewhat tight) itegration between business parteners that happen to use web services as a messaging technology.
One of the issues that I've struggled with time and time again with any actual requirements and a resulting design are the principles of service autonomy and loose-coupling between service provider and consumer; specifically how these issues relate to a scenario where a request is made to service by a specific type of service consumer. For example, I often run into situations where requirements dictate that the service needs to be designed so that it has the capability to determine the "type" of consumer that is making the service request because the request needs different processing steps based on the "type" or consumer context. While there are many ways to handle this requirement, this issue often results in a tighter coupling between the service consumer and provider due to the fact that both the consumer and provider must share this contextual knowledge so that the provider can appropriately process the message. It seems to me that this violates some of the basic SOA principles. To make matters worse, existing decentralized implementations that backend many web service processing are based on unexposed/private, non-federated user identities or domain specific support data. It is often that case that it's required that services accept various private system identifers and identifier mappings so that the service provider can process a specific request in a way that appropriately interacts with the consumer. One might imagine that these kinds of issues could be remedied by exposing addtional contextual information based services so that the consumer can use them to discover provider specific information or that in some cases the provider might be given the ability to internally determine this info via something like content enricher processing but these implementations also have their consumer/provider coupling and partener support data synchronization issues. Does anyone have any experience/opinions to share that shed some light on how to best handle these issues? Am I just confusing SOA design/wishful thinking that I might be able to implement an SOA given the circumstances with what is really a just a systems integration in my real-world? =================================== This list is hosted by DevelopMentor® http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com
