Contracts
Contracts bring clearer communication. They are subjective at first, but understanding once they are on paper They make everything easier. Examples of contracts are given below:
Document names, including schemas, WSDL and connection specification files.
File location and physical structure of executive services and projects.

Standards
Standards are more formal and serious than contracts, and it can be said that they have been resolved in a way (there is less disagreement about them Standards have functional goals, that is, if we do not proceed with them, they will lead to side effects on function and Performance will be poor.
It is good to standardize the following:
Ability to use service creation programs, such as JAXB or JAX-WS
Is it possible to upgrade? Internal or external?
Importing WSDL connections versus defining them inline
Entering schema types into WSDL versus defining them on line
Choosing the default protocol and when to add other protocols
Selection of start form methods
Proper use of your design patterns
Use of interfaces
Using optimal methods, such as FastInFoset and MTOM/XOP
Use of headers
Using attachments
If SOAP is used, determine the acceptable style, use and type values of its parameters, such as document/literal wrapped
Selection of one-way methods Using asynchronous clients
Coding for binary data
Focused schema
More items can be added to this list depending on executive choices.
Failure to follow such guidelines will result in interoperability issues, poor performance, and increased production time.

specifications
In the world of SOA and web services under Java, there are important characteristics.
The Java specification should include the following:

•  
• JAX-WS
• JAXB
• SAAJ
• JAXR
• Web services
• WS-Annotations
• DOM, SAX, StAX

And the specifications of SOA and WS-* include:

•  
• XML Schema
• XSLT
• SOAP
• WSDL
• OASIS UDDI
• WS-Policy
• BPEL
• WS-Security
• WS-Trust
• WS-ReliableMessaging
• WS-Transaction
• WS-MetadataExchange

Focused marks
Provide a wiki page to encourage developers to markup public web services, and so on It will be easy for everyone to find and use these web services. Invite others to participate.
industry standards
It is better to inform others about industry standards that are not useless to know. These standards include The following are:
Basic Profile 1.1
OASIS XML Catalog
W3C Web Services Architecture
OASIS Web Services Implementation Methodology
According to accepted industrial successful examples, we define a set of successful examples for the organization and put them in We include design. Some of them can even be derived from standards, such as WS-I BasicProfile.

Security
Dedicate a part of the site to security, because it is considered an important and complex issue of web services, and of course There are many standards for this.
There are guidelines for ensuring interoperability that include:
Use specific coded strings
Use of digital signature
Transfer security layer
Validation methods
As SOA grows, it's good to keep a list of rules for each service to help our harmonization efforts across the organization. will do .
Cookbook
According to the amount of experience of the organization, you may have examples of code that show how to build services and the attendant It shows the assemblies.
Glossary
Prepare a list of important terms and their desired definitions to clarify the concepts in the minds of team members. to this The reason why some SOA concepts are vague and debatable is that they don't really seem to be talking about the same thing. Therefore, using a dictionary for terms such as service, contract, sovereignty, etc. can be a meaningful communication create
Documentation
This is where JavaDocs, project documentation, vendor documentation, requirements, use case documentation, model analysis documentation We create and communicate.
Architectural products (artifact)
You might want to look into SOA runtime products (if the infrastructure allows it, of course), Products such as: centralized schema, modeling documents, business process, visible display of BPEL synchronization and... Provide monitoring tools to users so they can make the right decisions about new service candidates, SLAs have new combinations or infrastructure changes.
News
To give people equal information and keep team members informed with each other, include a field in your reference architecture portal. which collects websites related to different SOAs.
Conclusion
Remember that the goals of reference architecture are very diverse, such as:
1- Gives beginners the necessary instructions to use the organization's web services.
2- It allows experienced programmers to find and use the organization's web services.
3- It helps the Governance Board or COE to make decisions according to the service candidate and in line with the future architecture.