问题
I've been doing a lot of research lately about SOA and ESB's etc.
I'm working on redesigning some legacy systems at work now and would like to build it with more of a SOA architecture than it currently has. We use these services in about 5 of our websites and one of the biggest problems we have right now with our legacy system is that almost all the time when we make bug fixes or updates we need to re-deploy our 5 websites which can be a quite time consuming process.
My goal is to make the interfaces between services loosely coupled so that changes can be made without having to re-deploy all the dependent services and websites.
I need the ability to extend an already existing service interface without breaking or updating any of its dependencies. Have any of you encountered this problem before? How did you solve it?
回答1:
I suggest looking at a different style of services than maybe you've been doing so far. Consider services that collaborate with each other using events, rather than request/response. I've been using this approach for many years with clients in various verticals with a great deal of success. I've written up quite a bit about these topics in the past 4 years. Here's one place where you can get started:
http://www.udidahan.com/2006/08/28/podcast-business-and-autonomous-components-in-soa/
Hope that helps.
回答2:
There are a couple of approaches you can take. Our SOA architecture involves XML messages sent to and from the services. One way we achieve what you describe is by avoiding the use of a data binding library to our XML schema and use a generic XML parser to get just the data nodes you want ignoring those you aren't interested in. This way the service can add additional new nodes to the message without breaking anyone currently using it. We typically only do this when we need just one or two pieces of information from a larger schema structure.
Alternatively, the other (preferred) solution we use is versioning. A version of a service adheres to a particular schema/interface. When the schema changes (e.g the interface is extended or modified), we create a new version of the service. At any time we may have 2 or 3 versions on the go at any one time. In time, we deprecate and then remove older versions, while eventually migrating dependent code onto newer versions. This way those dependent on the service can continue using the existing version of the service while some particular dependency can 'upgrade' to the new version. Which versions of a service are called are defined in a configuration file for the dependent code. Note that it is not only the schema which gets versioned, but all of the underlying implementation code as well.
Hope this helps.
回答3:
What you're asking isn't an easy topic. There are many ways you can go about making your Service Oriented Architecture loosely coupled.
I suggest checking out Thomas Erl's SOA book series. It explains everything pretty clearly and in-depth.
回答4:
There are a few common pratices to achieve loose coupling for services.
Use doc/literal style of web services, think in data (the wire format) instead of RPC, avoid schema-based data binding.
Abide strictly by the contract when sending out data, but keep few assumptions processing incoming data, xpath is a good tool for that (loose in, tight out)
Use ESB and avoid any directly point to point communication between services.
回答5:
Here is a rough checklist for evaluating whether your SOA implements Loose Coupling:
Location of the called system (its physical address): Does your application use direct URLs for accessing systems or is the application decoupled via an abstraction layer that is responsible for maintaining connections between systems? The Services Registry and the service group paradigm used in SAP NetWeaver CE are good examples of what such an abstraction might look like. Using an enterprise service bus (ESB) is another example. The point is that the application should not hard code the physical address of the called system in order to truly be considered loosely coupled.
Number of receivers: Does the application specify which systems are the receivers of a service call? A loosely coupled composite will not specify particular systems but will leave the delivery of its messages to a service contract implementation layer. A tightly coupled application will explicitly call the receiving systems in order; a loosely coupled application simply makes calls to the service interface and allows the service contract implementation layer to take care of the details of delivering messages to the right systems.
Availability of systems: Does your application require that all the systems that you are connecting to be up and running all the time? Obviously, this is a very difficult requirement especially if you want to connect to external systems that are not under your control. If the answer is that all systems must be running all the time, the application is tightly coupled in this regard.
Data format: Does the application reuse the data formats provided by the backend systems or are you using a canonical data type system that is independent of the type systems used in the called applications? If you are reusing the data types of the backend systems, you probably have to struggle with data type conversions in your application, and this is not a very loosely coupled approach.
Response time: Does the application require called systems to respond within a certain timeframe or is it acceptable for the application to receive an answer minutes, hours, or even days later?
来源：https://stackoverflow.com/questions/2503071/how-to-implement-loose-coupling-with-a-soa-architecture