- Thiết kế website giá rẻ

I have a question whether it is a good or bad practice to use an SOA layer for the application servers to talk to the database. A web application server can obviously directly connect to a database, but in the hype to make everything SOA, the architects are mandating that everything has to make an SOA call to midtier servers that connect to the database.

To me, this seems terribly wasteful that you have an application in the same datacenter as the database and the applications can directly access the database server, but they don’t. There is already a level of abstraction on the application servers which looks identical to what we eventually end up with SOA, so this isn’t a matter of a better interface.

By using SOA you are adding a lot of steps to build up the request, send it out, have it received and then decoded and then finally make the database call and then you have to package that up, send it out, have it received, decoded and finally you can use the data.

From what I have read about SOA, it is useful when you have geographically spread out systems where a server in Boston needs information from a server in Seattle and there is no way that a direct database connection could be possible. This is also useful when you have many different customers that need to call a central point to receive data according to a fixed contract.

However, to use SOA as the means for just directly communicating with your database from your application seems to be a complete abuse of the concept and seems to provide little advantage while significantly slowing down the transactions. A typical usage would be to call a stored proc and instead of calling it directly, you have to use a SOA call to a midtier server to get the exact same information.

So, am I crazy or what? Is everyone just drinking the SOA Kool Aid and applying SOA to absolutely everything until the point of absurdity? Or is there really some advantage to doing this?

There are many factors about your application stack that may indicate or contra-indicate use of SOA, so it will be very hard to tell you if everything they are asking for is appropriate.

I will say that I don’t think you should specifically not use SOA just because the machines happen to be in the same data-center. What if you need to enforce a new security scheme, or need to move some of the servers, or support servers in different data-centers for DR-1 implementation, or you want to switch to new database software, or …

One of the advantages of SOA is that it abstracts away those issues for you the front-end developer or even middle-tier developer(unless you are responsible for the db api).

SOA has many advantages other than increasing efficiency over a raw database confection.

The most important benefit is that it provides a layer of abstraction that can be used to allow an underlying database to evolve its design without the need to synchronise releases with all consumers of the data it stores (this is particularly important if the database is maintained by a different team to its consumers, but is still helpful even if they are both managed by the same team, as it allows the team to concentrate on changes to one aspect of the system at a time)

Its not an abuse if your organization demands it. If there are security concerns or architectural guidance/governance that dictates it then it is warranted.

We went through this with a 3rd party audit a while back and one of the 3rd party audit concerns was that our service layer directly interacted with the database. We had a web application layer and service layer. The service had a data access layer and interacted to the database via stored procedures. The data and service layer were in the same network zone.

Basically, the architecture team reviewed the 3rd party finding and asked what would be need to be done.

The response was to add another service that would only interact with the database. This meant more cost to the project and raised a performance risk. Our SLAs were less than 100ms per call. Neither the additional cost or performance risk was acceptable to the business.

Because of the cost and risk, the team decided it was not necessary to do this. But your situation may be different.

Taking all things into account, your right it’s over kill. I’ve seen SOA tken to the extreme where is takes 1/2 dozen service callouts to get the data that is required. Data is scattered to the four winds. You want a happy medium.

Filed under: softwareengineering - @ 19:47

Danh mục