In-depth SOA details

There are a lot of articles on SOA in the blog Hall. It seems that the actual project of SOA may be just around the corner.

 

Because SOA is by no means a standard and an architecture that has just been developed and launched, some details (which may not be listed below) can be found on the Internet, each has its own opinions and reasons.

 

I. Does service fa C Ade disclose entity or argument?

 

For example, it should be like this:

Customerservice. addcustomer (customerinfo customer)

Or:

Customerservice. addcustomer (string name, string zipcode, int32 level)

 

First look at the figure, http://bbs.dotnettools.org/upload/1308-Architecture%20Design.jpg (this figure from. net tools Evaluation Network Forum redmoon introduces the product architecture, at the same time, we recommend that you go to the Forum to see redmoon, ccboy, jjx, jgtm2004 wonderful speech on SOA ).

 

From this figure, we can see that the entity implemented by Typed Dataset spans the entire system (that is, passed between the entire system, as I mentioned in my previous article, dto flows between modules), or even passes to the service customer through the service boundary. If your entire system is. and can deploy the Assembly containing the entity to each module of the system (so we recommend that you put all the entity used in the system in one project separately, and is referenced by all other projects). This is definitely a simple, clear, and efficient choice.

 

But many people disagree with this (I guess jgtm2004 will disagree, based on the opinions expressed in his post ). Many people think that, as an independent, self-maintained, and decoupled service, you disclose an entity that you only understand, what's more, a java system may want to call this service in the future. Therefore, many people say that "Services expose schema and contract, not class and type" means that a neutral message must be transmitted between services with a well-defined schema.

 

On the other hand, it seems that in the February this year programmer magazine, there was an article about a failure case. One of them is that calls between modules are through parameters rather than entity, as a result, the customer added a field information, which involved a lot of changes (because the Module Interface must be changed). Therefore, the author of the article believes that, in order to ensure that the interface is relatively fixed when the object structure changes, the module interface parameter must be a class.

 

2. Does entity maintain their own relations?

 

For example, should the pure data entity of customerinfo contain a set of orderinfo (providing an orders attribute for public publishing) and orderinfo contain a reference of customerinfo (providing a customer attribute )?

 

Include? When the service customer requests a customerinfo from the service, the corresponding orderinfo set is also automatically retrieved from the database and packaged into customerinfo and transmitted back together? Or do I need to use methods like lazy-loading to retrieve them first? It is an obvious waste in some scenarios. Wow, it seems like a headache.

 

Lazy-loading is not a simple application in SOA. For example, the client requests an orderinfo and then references its customer attribute. The service uses lazy-loading to load and return the correct customerinfo object, and then the client references the orders attribute of the customerinfo object, at this time, the Service should be able to correctly determine which orders have been loaded and can be directly retrieved from the cache, which are not loaded and need to be retrieved from the database... Orm may be a good choice.

 

If entity does not maintain its relations, the client will call the Service as follows:

 

Customerinfo customer = customerservice. getcustomer ("kaneboy ");

//...

Orderinfocollection orders = customerservice. getorders (customer. Name );

//...

Customerservice. updatecustomer (customer );

Customerservice. updateorder (orders [0]);

 

Repeat the request to the service for processing by the service that knows its relationship. In addition, the client code is troublesome, because customerinfo and orderinfo "actually" do not know the relationship between them. When you need to perform some processing based on their relations, you need the code to handle it manually.

 

It seems that the article has not come to a conclusion, because it cannot make an "absolute" correct choice. Personally, I prefer the service to expose entity and entity to maintain their relations. However, do right things in right place.

Note: A lot of ideas come from Udi Dahan-the software simplist.