How should the SOA architecture be implemented?

Question

My project is turning an obsolete desktop application for a fat client on the Internet. As a result, the database does not change. Therefore, we are forced to call external web services to access data in our own database. Combine this with the fact that some parts of our application are allowed to access the database directly through the DAO (a practice that is much faster and easier). The functionality that we should call web services is what was deemed necessary for downstream dependent systems.

Does SOA really work? Admittedly, this is my first step into the world of SOA, but I must think that this is the complete wrong way to do this.

Answer 1

I saw people try to hush up the SOA too low, and that could be so. Of course, I would not identify DAO and SOA at the same level.

I agree with @ewernli
What is plain English SOA?

IMHO, SOA makes sense only at the enterprise level and does not mean anything for one application.

If I read your question correctly, your web services are for C / R / U / D data in the database. If so, the provision of C / R / U / D services is directly in the database, and its tables are probably too low to serve the SOA.

I would look for services at a higher level and try to determine whether they are interesting for the enterprise. If so, this is your service. I would also ask if my old desktop application would provide services (i.e. if you want to make your new application the SOA service itself, rather than trying to force the SOA architecture in the desktop application to be low.

Answer 2

I agree that this is the wrong approach. Calling your own database through the webservice should raise the red flags in the design overview, and a simple DAO is the way to go ( KISS principle ).

Now, if this is data that really needs to be shared between your company (accounts, billing, etc.), THEN you need to think about a more complex solution, such as SOAP or REST. But your team could access it directly, which would be faster.

My team had the same thing with the web service we wanted to call in batch mode. Instead of calling our SOAP endpoint, we instead set it to invoke the POJO (plain old Java object) interface. There is no XML conversion or additional network hop through the SOA device.

It is unnecessary to put the XML interface between the MVC layers when your team owns the entire application. It may not be a traditional SOA ... but IMO is traditional common sense .;)

Answer 3

Therefore, we are forced to call external web services to access data in our own database.

Man, this should hurt. For services in SOA, a service is a repeatable logical manifestation of a business task . This means that you do not implement SOA if you are not performing business processes. If you host some web services to select data from your database, all you have is a bunch of web services that will slow down your applications, which could be faster than regular data access patterns (like DAO).

When you equate SOA with web services, there is a risk of replacing existing APIs with web services without a proper architecture. This will lead to the identification of many services that are not consistent with the business.

In addition, service orientation is a way to integrate a business as a group of related services . So ask yourself, is the organization using these nuclear services to achieve further benefits?

Do a Google search for anti-SOA templates and you will find what are the different ways to end up dumping web services instead of SOA.

Answer 4

Good SOA design is all about sharing behavior and data. I repeat that the behavior and the data must be separate, otherwise you will have many problems or problems if you call it CORBA / SOAP / REST / XMLRPC or even simple old calls in the same JVM method.

Many people will talk about service endpoints, message processing, and contracts that make SOA one of the dullest areas of computing when it is surprisingly easy.

If you are doing Java, it is very simple. Make a POJO for your domain objects without any weird states and no weird co-authors, and then create service classes with behavior. Most often then you can’t just use your DAO as a service (I mean, you should have a thin layer over the DAO, but if you don’t need it ...).

OOP lovers will disagree with this separation of data and behavior, but this design pattern scales very well, which means that most functional programming languages ​​like Erlang do.

Saying that if you are creating a video game or something very wealthy, then this design philosophy is a bad idea. BTW SOA is about as empty as the term enterprise.

Answer 5

SOA ... SOA ... this is the curse of my existence for this very reason. What and what does not make SOA? I support SOA products in my daytime work, and some people get it, and some don't. SOA .. SOA about wrapping individual business services in XML. ZIP + 4 checks. Payment gateways. Messaging in B2B.

SOA CAN can be used to decouple desktop applications from databases. Sometimes it makes no sense, sometimes it happens. What almost NEVER makes sense is high-latency, high-latency logic. If you ever need an application in France that is directly linked to a database in California, you will understand what I mean. SOA pretty much forces you to figure out how you model and return your data (see SDO - Service Data Objects ). The devil is in the details. Marching data to / from XML can be expensive.

Answer 6

Which part do you think is wrong? The part that you must go to the web service, or the part that you directly click on the database?

SOA is more of an API development guide rather than a development methodology. This is not an easy task, but the reward for reuse is often worth it.

See Service-Oriented Architecture Extends Web Services Vision or Any SOA Technical Book. Simply handling function calls using a web call does not make it a service-oriented architecture. The idea behind an SOA is to make reusable services, and then you provide a higher level of services (like a website) by linking or organizing low-level services. At a very low level, you should focus on such things as statelessness, loose communication, and granularity. Modern environments, such as Microsoft WCF, support wiring protocols such as SOAP, REST, and faster binaries nearby.

If your application is designed to work over the Internet, you should be aware of problems with network latency. In a traditional client-server application, which is deployed on the local network, since the latency is less than 10 ms, you can get into the database every time you need data without interrupting the user's work. However, on the Internet, it is not uncommon to have a delay of 200 ms if you go through proxies or oceans. If you get into the database 100 times, and this will add up to 20 seconds of pause. In SOA, you try to put all this into one document and you exchange the document back and forth, just like the tax filed using form 1040 if you live in the USA.

You can say that the latency issue doesn't matter, since the web service is consumed only by your web application tier. But you can hit the web service from the browser using AJAX to reload the data, which should give the user a shorter response time.