It has been written in the Development of SOA. It does not mean to develop all functions as public services, but to design the components that will interact with other software as services.
In this way, you must re-developProgramTo extract the service. So how should we extract the services here? What is the relationship between the extracted services and other functions in the program?
Looking at SOA, many introductions refer to the original system as an underlying dependency for implementing SOA services. Based on this assumption, according to the previous hierarchical relationship: X. iservices X. iservices. impls... it should be in X. iservices layer is built on top of the iservices layer, and this iseservices is implemented, and X. iservices layer. The existing software can be fully used to package new functions. This means that the use of SOA in the development of new software is the same as the transformation of existing software to provide SOA functions. In this case, enterpriseservices only packs X. iservices as one or more services. In addition, in some cases, enterriseservices may provide the same functions as X. iservices, and this will not cause any problems.
Another way is to create a new pair of enterpriseservices and X. this part of iservices does not have a relationship. This is a good solution because X. after all, iservices does not focus on implementing the functions of the software, but cannot guarantee its performance. Data entities must be redefined for service requirements. If you develop a new enterpriseservices, you can develop it specifically for enterpriseservices. However, the problem that arises here is that the enterpriseservices's dependency on X. iservice's database data exists objectively and cannot fully utilize the existing data.Code.
How can these two methods be better? Or, after talking about such a long SOA, what should the software look like at the end. Is the entire system fully SOA or only partially SOA. I have been thinking for a long time and don't know the answer.