Service-oriented analysis and design principles

Service-oriented analysis and design principles

Author/OLAF Zimmermann, pal krogdahl, Clive Gee

Experience from the initial Service-Oriented Architecture (SOA) Implementation Project shows that, for example, object-oriented analysis and design (OOAD) enterprise Architecture (EA) framework and business process modeling (BPM) such existing development processes and representations only cover some of the requirements required to support the architecture patterns currently present in SOA.
In a recent interview with Info World, Grady booch claims that "engineering foundations like good abstraction and good separation of problems will never be outdated", but he also pointed out: there are still opportunities to improve the abstraction level. Past experience has shown that abstract levels must be upgraded to the business field processed by the company, so that the entire enterprise it prospects can be considered.
As Mark colan introduced in the article "prospects for expanding web services in service architecture", SOA is a new form of enterprise architecture that can be used to design next-generation enterprise applications. The SOA method has added some other topics while strengthening the well-established general software architecture principles (such as information hiding, modularity, and problem separation, for example, service orchestration, service library, and service bus middleware mode.
Structured or analytical or design methods are required to design high-quality SOA. Because none of the existing methods can meet the requirements of programmers for the latest SOA project, they recommend that you incorporate existing good practices (such as OOAD, EA, and BPM) and use innovative principles as needed to supplement them.

Introduction
The basic concepts of Service-Oriented Architecture (SOA) and Web services will become part of our daily language and can be seen as an architectural form suitable for designing modern enterprise applications. In this context, what constitutes a good service is the key to ensuring the successful implementation of SOA.
Object-oriented analysis and design (OOAD), enterprise architecture (EA) framework, and Business Process Modeling (BPM) such existing Modeling Rules provide us with high-quality practices that can help identify and define appropriate abstractions within the architecture for a long time. However, experience shows that these practices cannot meet the requirements of individual applications.
In this article, we will study the appropriate principles in OOAD, EA, and BPM. We will also promote the demand for mixed methods, which combine the principles in all these rules with many unique new principles. This cross-disciplinary OOAD method makes it easier to successfully develop SOA. We call it service-oriented analysis and design (Soad ), it is still to be formally defined. We just entered the Soad Hall.

Service-oriented concept
With the expectation of discovering new business opportunities or threats, the SOA architecture is designed to provide enterprise business solutions that can be scaled or changed as needed. An SOA solution consists of reusable services with well-defined and compliant released interfaces. SOA provides a mechanism through which existing legacy applications can be integrated regardless of their platform or language.
In terms of concept, SOA has three main abstract levels:
L operation: a transaction that represents a single logical unit of work (luw. Executing an operation usually results in reading, writing, or modifying one or more persistent data. SOA operations can be directly compared with object-oriented (OO) methods. They all have specific structured interfaces and return structured responses. Like the method, the execution of a specific operation may involve calling additional operations.
L service: indicates the logical group of operations. For example, if we regard customerprofiling as a service, we will find the customer by phone number, list the customer by name and zip code, and save the data of the new customer.
L Business Process: A group of long-term actions or activities performed to achieve specific business goals. A business flow usually includes multiple business calls. Examples of business processes include accepting new employees, selling products or services, and completing orders.
In SOA terminology, a business process includes a series of operations performed in an ordered sequence based on a set of business rules. The sorting, selection, and execution of operations are referred to as service or Process Orchestration. A typical scenario is to call the orchestration Service to respond to business events.
From the modeling point of view, the challenge is how to describe the features of well-designed operations, services and processes, and how to systematically construct them. These issues are currently the most frequently discussed in the industry and academia. As far as we know, almost all recent SOA projects or seminars have made such service modeling an important topic and have aroused a lot of debate. Therefore, let us take a closer look.

Why Is BPM, EA, and OOAD insufficient?
Early SOA implementation project experiences show that existing development processes and representations such as OOAD, EA, and BPM only cover part of the requirements required to support the SOA paradigm. While strengthening the well-established general software architecture principles (such as information hiding, modularity, and problem separation), the SOA method also adds additional themes, such, service orchestration, service library, and service bus middleware models require special attention during modeling.
Figure 1 shows the main application fields of the existing EA, BPM, and OOAD modeling methods. It is also the starting point for us to discuss Soad later. The horizontal axis in the figure indicates the project life cycle stage; the vertical axis indicates the differences between different abstract layers or fields, and modeling activities are usually carried out on them.
The vision of SOA is quite easy to understand, as its technical basis is well known. For example, in any SOA work, applying general software architecture principles and OO technology is an effective start. However, as we have already mentioned, early adopters often ask how to identify the right service. As mentioned above, OOAD, EA, and BPM cannot provide satisfactory answers when they are independently applied, which is exactly what we want to explain now.
Object-Oriented Software Engineering: A Use Case Driven Approach, published about 10 years ago) the OOAD method described in provides a very good starting point for defining SOA. Similarly, although the application of OOAD technology and Unified Modeling Language (UML) notation in the architecture hierarchy for many years is a common practice, however, OOAD is related to the abstraction of micro layers such as classes and individual object instances. Because each problem domain often creates a separate condition model, the general direction of the enterprise for application development projects is blurred in many cases. In addition, for various reasons, the usage model is not always synchronized with its equivalent bpm.
Such as Treasury enterprise architecture framework (Treasury enterprise architecture framework, teaf, http://www.software.org/pub/architecture/teaf.asp), feature-Oriented Domain Analysis (feature-Oriented Domain Analysis, FODA, http://www.sei.cmu.edu/domain-engineering/FODA.html), and Zachman (http://www.zifa.com /) such an EA method adds the urban planning perspective to the solution architecture, but it does not solve the problem of how to find high-quality enterprise abstraction that is easy to reuse and persistent.
Although BPM methods (such as bpmi, http://www.bpmi.org/) provide end-to-end views on functional units of work, they generally do not touch architecture and implementation areas. For example, BPM notation lacks the Operational Semantics before a language such as business process execution language for Web Services, BPEL, and http://www.research.ibm.com/journal/sj/412/leymann.html appears. In addition, we also see a lot of separation between Process Modeling and development activities.
Finally, none of the existing rules can solve the problem of how to enable existing applications for SOA. Most of the time, the top-down process is adopted. Existing systems usually store a large amount of important data and business logic, and cannot be replaced simply. Therefore, in order to study packaging and restructuring strategies, we must analyze these systems from the bottom up. Therefore, the consideration of existing applications will lead us to the process of meeting.
Due to these reasons, a hybrid Soad modeling method is required. This method combines OOAD, BPM, and EA principles in the best way, and incorporates some innovative principles. Figure 2 shows the Soad resources (principles and technologies) of this new method ):
EA
Developing enterprise applications and IT infrastructure into SOA may be a huge burden, affecting multiple business lines and organizational units. Therefore, the EA framework and reference architecture (such as the open organization architecture framework, the Open Group architecture framework, togaf, http://www.opengroup.org/architecture/togaf) and Zachman, to achieve the consistency of the architecture between separate solutions.
Based on past experience, most existing EA frameworks have limits on one or more aspects. For example, if the main problem is how low-level components of technical devices are connected at a macro level, the business layer process or service view cannot be obtained. However, in the context of SOA, this method of consideration must be switched to a logic component that represents the business service as the center, it also focuses on defining interfaces and SLA between services ).
In addition, many enterprise-level reference architectures and frameworks are quite common and have not touched on the design field. Such an advanced architecture cannot provide specific tactical advice to architects and developers, and often leads to fundamental differences between the enterprise architecture and the solution architecture.
Soad must help SOA architects define the overall business-level view of service prospects. This is what today's ea frameworks cannot provide, and they require future-specific enhancements to SOA; On-Demand operating systems (On Demand operating environment, odoe, http://www-1.ibm.com/partnerworld/pwhome.nsf/weblook/ebod_environment.html) is the main strategy developed by IBM for this trend.

BPM
BPM is an incomplete rule with many different forms, representations, and resources. Another common technique is to define an event-driven process chain that represents a conceptual process flow, which is different from the UML notation.
In addition, many specialized methods (such as BPM technology) may be considered competitive by consulting companies and Enterprise Resource Planning (ERP) software package vendors. Aris implementation platform is an example of such a product. Other methods include line of visibility enterprise modeling (lovem) and IBM Component Business Modeling (CBM) strategies.
A recent trend is to define a standard method that represents an executable stream model, such as the Business Process Execution Language for Web Services. BPEL extends the scope of the process from analysis to implementation. Such an executable model raises a series of new problems, including:
L what aspects should be described by using BPEL and what aspects should be described by WSDL? What is the difference between a process model and a traditional programming model?
L how to add non-functional requirements and service quality features to the model?
L how much logic is executed in the Programming Language extension of the BPEL engine compared with more traditional encoding (such as in J2EE?
L how can we evaluate the quality of an executable process model? What is the best practice for its application?
L what role is a business expert (analysis personnel) or a development role (software architect) responsible for implementing the process of BPEL Stream Management )?
All existing BPM methods must be used as the starting point for Soad; however, additional technologies used in the process model to drive candidate services and their operations must be used to supplement them. In addition, the Process Modeling in Soad must be synchronized with the design layer's case modeling and provide answers to the problems related to the BPEL.

OO paradigm and so paradigm
OO analysis is a very powerful and widely acclaimed method. Similarly, Soad should use as much oo analysis technology as possible. To successfully apply oo analysis to an SOA project, you must analyze multiple systems at a time. The usage model must continue to play an important role. However, Soad must be primarily a process rather than a user-driven process. Therefore, Soad requires a strong link between BPM and situation modeling activities.
At the design layer, oo aims to quickly and effectively design, develop, and execute flexible and scalable applications. An object is a software structure, and its behavior is like a real-world entity that they model. For example, a customer may have a name and contact information, and there may be one or more associated account objects. From the OO perspective, everything is an object.
The basic principles of OO are:
L encapsulation: software objects are discrete packages that contain physical properties (data) and functions (behavior) of objects simulating the real world. For example, the account object maintains a balance of payments and includes a balance-based lending mechanism.
L Information Hiding: well-structured objects have simple interfaces and do not expose any internal mechanisms to the outside world. An example of information hiding in the real world is that you can drive a car without having to know in detail how it works.
L class and instance: A class is a template that defines the types of attributes and behaviors of a specific type of software object, and an instance is an individual object with these attribute values. A new instance of the created class is called Instantiation. Using biology for analogy, humans are a class. All people have some attributes, such as height, weight, hair and eye color. Each of us is a humanbeing-like instance with specific height, weight, and other attribute values. The instance has a limited life cycle.
L Association and inheritance: In Oo, the ability to express associations between classes and objects is a key concept; inheritance is a strong form of association for expressing relationships: In the same way, biological Species are composed of kingdom, phylum, class, order, family, and genus) species ). We often find the natural hierarchy of software objects. For example, when you create a financial application entity, you may need to construct a structure such as a regular account (checking account), a savings account (savings account), and a loan account (loan account) such an object. If you take a closer look (see figure 3), you will find that these classes share many attributes, such as balance of payments accounts, debit accounts, and credit accounts.
Instead of repeatedly defining and managing the code for these attributes, it is better to create a general account class that has a balance of cash receipts and payments and can handle lending transactions. All other classes are the special form of the account class object. For example, a loan account (loanaccount) will have a negative balance between zero and the maximum value of a certain agreement, while a savings account (savingsaccount) will have a negative balance and will show the behavior of increasing interest, and so on.
L message transmission: software objects need to communicate with each other to complete some useful work. They do so by sending messages to each other. For example, to transfer $1000 from a regular account to a savings account, you can send a borrow message with the $1000 parameter to a checkingaccount instance, and send the corresponding loan message to the savings account (savingsaccount) instance. When an instance receives a message, it executes the corresponding function, called a method, which has the same name as the message.
L polymorphism: This term describes how two or more classes receive the same message but implement it in different ways. For example, the freecheckingaccount instance and the checkingaccount instance will respond to the borrow ($100) message, but the freecheckingaccount) the instance will be recorded as the balance debit of $1000 in its account, while the regular account (checkingaccount) instance will add $1000 plus the transaction fee to the balance debit of its account.

OO supports the full lifecycle of application analysis, design, and development:
L OOAD tries to find the optimal objects and the most natural class inheritance to implement them.
L OO development focuses on the progressive development of applications, each time a business scenario or usage is implemented. Tools such as IBM WebSphere Studio Application Developer help developers quickly construct and test oo applications.
L oo runtime environments, such as those provided by Java virtual machines, provide application services (such as garbage collection (delete resources that are no longer used because their objects have been discarded )) and frameworks (such as J2EE) to provide communication mechanisms for objects residing on different servers.
At present, the main problem of so-related OO design practices is that its granularity level is concentrated at the class level, which is too low for business service modeling. Strong associations such as inheritance produce a certain degree of tight coupling (and thus dependency) between stakeholders ). In contrast, the so paradigm attempts to promote flexibility and agility through loose coupling. Currently, there is no cross-platform inheritance support and first-class representation of service instances in SOA to avoid service lifecycle maintenance and management issues (such as remote garbage collection ).
These considerations make it difficult for oo to be directly consistent with the So architecture style. However, oo is still a valuable method for designing the underlying classes and Component Structures of defined services. In addition, many OOAD technologies (such as class, responsibility, and collaboration (CRC) cards) can also be used for service modeling (if they are elevated to a higher level of abstraction ). Later in this article, we will go back and discuss this point.
Figure 4 shows the relationship between the visibility level and the focus of OO, component-oriented, and so design. It also shows the relationships between SOA and Soad.
As for the representation, the Unified Modeling Language (UML) is enhanced by some additional stereotypes and summaries-naturally becoming an important basis for Soad.
The use of UML models is of primary value in the use of Rational Unified Process (RUP, http://www-306.ibm.com/software/awdtools/rup/)-a process considered to be one of the mainstream OOAD flows supporting iterative software development analysis and design. However, based on the OOAD principle, RUP makes it difficult to be consistent with the SOA design. From the perspective of RUP, the system architecture is the architecture of the main components for interaction through defined interfaces. In addition, these components are also composed of smaller components gradually reduced to class-level granularity. On the contrary, in SOA, the system architecture usually includes stateless, fully encapsulated, and self-described services that meet the needs of common business services. It is closer to BPM ing to bpm, 5.
These services may include many collaboration or orchestration services. This does not rule out the OO viewpoint adopted by RUP, but implements another abstraction layer on it. The role of this superlayer is to encapsulate components designed as the rational components (software services) in the formal cross-layer interface structure.

Soad principles
In this section, we will describe Soad requirements in more detail and begin to determine its themes and principles. The purpose is to introduce the discussion on this topic to further design work. Further work will undoubtedly require the formal Soad method.

What must Soad provide?
The following requirements have been determined for Soad:
L like any other project or method, the process and representation must be formally defined (at least semi-formally. By selecting and combining OOAD, BPM, and EA principles, you can determine additional principles as needed.
L there must be a structured approach to conceptual service:
M ooad provides us with classes and objects at the application layer, while BPM has an event-driven process model. Soad needs to combine them.
The m method is no longer situation-oriented, but driven by business events and processes. Using Case modeling is performed at a lower level as the second step.
The m method includes syntax, semantics, and strategy. This requires special combination, semantic proxy, and runtime discovery.
L Soad must provide well-defined quality factors and best practices (for example, answer question granularity ). You must answer the role question raised by BPEL. For example, who is responsible for what part of the work: developers, architects, or analysts?
L Soad activities must also answer the following question: what is not a good service? For example, nothing that can be reused cannot become a good top-class SOA member (that is, a service ). Another example is a challenging, non-functional embedded real-time system that cannot afford any XML processing overhead.
L Soad must be easy to perform end-to-end modeling with comprehensive tool support. If SOA brings flexibility and agility to the business, we should have the same expectations for the support methods from the enterprise to the architecture and application design fields.

Quality Factors
Some general principles or quality factors have been determined and can be used as design benchmarks in Soad:
L well-conceived services bring flexibility and agility to the business; they make refactoring easier through loose coupling, encapsulation and information hiding.
L well-designed services are meaningful and not only applicable to enterprise applications; the dependencies between services are minimized and explicitly declared.
L service abstraction is cohesive, complete, and consistent. For example, when designing services and their operation signatures, you should consider creating (create), reading (read), and updating (update) delete and search (cruds) metaphor.
L it is often declared that the service is stateless (for example, non-conversational). In order to require the service to be stateless in a specific problem domain and context, this statement will be weakened.
L domain experts can understand service naming without deep professional knowledge.
L in SOA, all services follow the same design system (connected by mode and template) and interaction mode; the underlying architecture form can be easily identified (for example, during the architecture review ).
L development of service and service users requires basic programming language skills in addition to domain knowledge. Only a few professionals need middleware expertise. Ideally, this knowledge is used by tools and runtime vendors, rather than by companies that make enterprise applications such as SOA.

Service ID and definition
Top-down business-level modeling technology (such as CBM) can provide a starting point for SOA modeling activities. However, as we mentioned earlier, SOA implementation rarely begins with a brand new project. Creating an SOA solution almost always involves integrating existing legacy systems, the method is to break them into services, operations, business processes, and business rules (see Figure 6 ):
L break down existing applications and vendor software packages into discrete service sets that represent related operation groups (bottom-up method ).
L abstract business processes and rules from applications into separate bpm for business orchestration model management.
All OOAD operations are related to the identification and definition services, but a higher level of view is required. In addition, when SOA is committed to development at a higher level than a classic development project, it has room for other creative thinking.
Direct and indirect business analysis
BPM and direct demand analysis through project-related personnel talks and CBM is an easy-to-understand and suitable Method to Identify Candidate services.
Past experience shows that this main approach should be improved by supplementing indirect technologies. When selecting candidate services, the product manager and other business leaders should negotiate. For example, what is the model of planned payment and invoicing? Consider the assumption that the organizational structure of an enterprise is using a system being built. We recommend that you consider any existing usage models in non-SOA projects. The term used to describe marketing for a system being constructed is another good source of candidates for service operations (especially verbs, with little attention to marketing verbs !).

Domain Decomposition
At endrei (http://publib-b.boulder.ibm.com/Redbooks.nsf/RedbookAbstracts/sg246303.html? The domain decomposition, subsystem analysis, target model creation, and related technologies defined in open are SOA process construction methods or service conceptual frameworks (which are built based on Levi and Arsanjani previous work) the most promising proposal. FODA (http://www.sei.cmu.edu/domain-engineering/FODA.html) work from SEI has also contributed to this discussion.
Service Granularity
Choosing the correct abstraction level is a key issue in service modeling. You will often hear suggestions for coarse-grained modeling. This is a bit too simple. You should change it to coarse-grained modeling without compromising relevance, consistency, and integrity. In any SOA, there is a space for fine-grained service abstraction (assuming there are business requirements ). Because SOA is not equivalent to Web Services and soap, you can use different protocol bindings to access services at different abstract levels. Another option is to bundle related services into coarse-grained service definitions, which is a variant of the facade model.
Naming Conventions
The Enterprise naming mode (XML namespace, Java package name, and Internet domain) should be defined ). A simple example is to always use nouns to name a service and verbs to name the service. This best practice comes from OOAD space.
First Soad Principle
In addition to combining OOAD, BPM, and EA technologies, there are also several important Soad concepts and aspects to be enriched:
L service classification and aggregation
L policies and aspects
L intermediate meeting process
L semantic proxy
L service acquisition and knowledge proxy
Service classification and aggregation
Services have different usage and usage. For example, software services can be different from business services (as shown in Figure 5 above ). In addition, you can also orchestrate Atomic Services into services with a higher level and complete functions.
A Service combination can be simplified through an executable model (such as a model modeled by BPEL). This is something that traditional modeling tools and methods cannot handle.
Policy and Aspect
Services have syntax, semantics, and QoS features. All of these features must be modeled. Formal interface contracts must cover more than Web Service Description Language (WSDL. Therefore, the Web Service Policy Framework (WS-Policy, http://www.ibm.com/developerWorks/cn/webservices/ws-polfram/) is an important specification.
In addition to the well-established system architecture trackability principles, business trackability is also an ideal quality: it is possible to associate all runtime components directly with languages that can be understood by non-technical experts. This is very important for abstraction that is exposed directly at the business and service layers. Sarbanes-Oxley (SOx) Act (see articles from Astor, http://sys-con.com/author? Id = 526) is an example of a business driver that requires this service trackability.
Process: intermediate meeting
In the real world, there are no completely new projects. You must always consider legacy systems (legacy systems are synonymous with existing systems ). Therefore, an intermediate approach is required, rather than a simple process of top-down or bottom-up.
When the design depends on the existing IT environment rather than the current and future business needs, the bottom-up approach will often lead to poor business service abstraction. Top-down methods may produce insufficient non-functional requirements and damage other architecture quality factors (such as performance problems caused by lack of standardization in domain models ), in addition, mismatch may also occur in services and components.
Service acquisition and knowledge proxy
This is a question of knowledge management and lifecycle: how can we successfully prepare services and make them reusable after conception?
Reuse should be considered as one of the most important criteria for promoting the identification and definition of services. If a component (or service) cannot be reused, it cannot be deployed as a service. It can connect to another service related to the enterprise architecture, but cannot exist as a service separately.
However, even if reuse is planned from the beginning, the Service acquisition process must also be formal. Using services by multiple users is a clear SOA design goal. The Service Registration Center (such as the enterprise UDDI directory) may solve some problems during construction.

Example: automobile work order
An Automotive work order describes a vehicle repair company's process of managing its customer operations. We will discuss Soad's point of view through issues in this field.
A work order represents an agreement between the automotive service company and the customer to carry out a series of routine or emergency repairs, such as routine 50,000-mile service, replacement of brake pads or tires, or oil change.
Business scenarios (7) are as follows:
L create a work order when a customer makes an appointment by phone.
Create an independent work order item for each planned service activity or operation, including detailed information about the parts, spare parts and services to be used.
L Ensure that all necessary parts are in stock before making an appointment.
L maintenance rooms with appropriate equipment and machines with appropriate conditions need to be arranged for each work order item.
L calculate the estimated total cost, and then the customer accepts the reservation; or the plan is terminated, and the work order is canceled immediately.
L assemble necessary parts, spare parts, tools and equipment in the selected service room immediately prior to the reservation.
L any activities planned and necessary when the customer arrives, as well as any other activities that appear necessary when checking transportation.
Record the actual value and labor of the parts and Spare Parts Used.
L calculate the total cost when all repairs are completed.
L create an invoice and deliver it to the customer.
If you create an independent application from scratch, you may create a group of classes shown in 8.
If you construct a work order as an OO application, these software objects will contain all the necessary business rules and understand the business processes that should be followed.
However, this method has some shortcomings in practice:
L many steps involve connections to existing legacy systems and databases (such as Bill preparation, schedules, and inventory systems) that cannot be designed in accordance with the OO Paradigm (in this case, application adapter or arbitration will be helpful ).
L to make the system as flexible as possible, it is helpful to externalize some rules so that you can modify the process or workflow without changing the code. For example, a rule like the following:
L standard 24,000-mile service includes four-litre oil. Additional Postage is only required when more than four liters of oil is used or when customers require high-quality oil (such as synthetic oil.
L there is a set of industrial standards in legacy applications for labor valuation for general vehicle maintenance activities. Unless the service personnel charge more than X % of the estimate and report the cause of the difference, the customer shall pay the standard labor fee.
L if the value exceeds Y %, contact the customer for confirmation.
Soad provides excellent solutions for these problems. Because it groups services based on relevant behaviors, rather than encapsulating (behavior and data), this set of services is slightly different from the business objects.
For example, you may divide a work order and a work order item into work order services and create Scheduling), catalog and inventory services. In addition, because there is no service instance, there is no equivalent relationship with the service. The service model of the work order may look like 9.
Unlike the OO paradigm, this model does not represent a functional system. Neither stream nor business events or rules are taken into account. In the SOA paradigm, the Business Process Orchestration maintained outside the Service determines the order and time of service invocation.
In terms of concept, the entire business from the first customer contact to the completion of work and bill payment represents a single macro-level work unit, with a life cycle ranging from several days to weeks. After all, from the enterprise perspective, work units will generate income.
However, the actual situation is a series of concentrated activities that take place independently within a relatively long period of time, such as defining activities, arranging appointments, selecting parts and spare parts, and performing maintenance activities. In the IT system, no actual process lasts for more than a few minutes. The Business Process status between events is stored in the database as data.
This type of process can be well represented by a state transition model (such as available in UML. Figure 10 shows an example of how to model a business flow using the finite-state machine method. It is an advanced view of how the status of a work order changes during a business flow.
Business Process Orchestration focuses on these changes between States. Independent Operations permanently record relevant status changes.
Figure 11 shows some orchestration examples, including steps 1 to 5 in the business scenario shown in Figure 10 (for example, the customer defines the work required for their transportation work, and schedule an appointment for implementation ).

Summary and prospects
In this article, we have discussed and stimulated the need for methods that meet in the middle of innovation. This method builds a bridge between business and IT, it also supports the analysis and design phases of SOA projects. We also propose to use this new interdisciplinary Soad method as an overall modeling rule, which is based on the well-established and widely acclaimed OOAD, EA, and BPM.
While defining Soad representations and processes in detail, key principles are also identified, such as service conception (or identification), service classification or aggregation, Policy and aspect, intermediate encounter process, semantic proxy and service acquisition (for reuse ).
Soad needs to enhance existing software development methods to further improve the availability and applicability of enterprise application development projects. Over time, related best practices will also be developed.
We also realized that UML will continue to dominate the process's representation selection; it may need to be enhanced to meet broader Soad requirements.
The next step to completing the Soad method is to define the required end-to-end processes and representations, review roles and their responsibilities in the activity, and continue to check the effectiveness of the proposed method in the project.