Shulou(Shulou.com)06/01 Report--

The content of this article mainly focuses on what are the common questions of xunit. The content of the article is clear and clear. It is very suitable for beginners to learn and is worth reading. Interested friends can follow the editor to read together. I hope you can get something through this article!

Design granularity "with regard to the product you shared, we also discussed it in the evening. Some people have done similar things before. In practice, we found that the business logic will be very complex, and the drawings made will be very complex, so they will eventually become martyrs. Do you have any experience in the process of practice?"

This problem is caused by the lack of granularity in use.

In general, each graph corresponds to an api of a service for the system, and each API corresponds to some steps. Just draw the picture so that you know what to do at each step. The code for each step had better be no more than 50 lines, which refers to pure code.

Do one thing clearly at each step. In addition to the very relevant logic, do not make branch judgment.

My recommendation is: the length of the picture should not exceed 5 nodes, and the height should not exceed 5 nodes, basically ensuring that a screen can be displayed when enlarged.

If a system / subsystem is indeed complex and has many steps, then use the combination of main graph and sub-graph to describe the system at two abstract levels

The design of this tool is very user-friendly and can be used very quickly. In fact, you will know how to use the appropriate granularity in practice. There is no need for special specifications. Because when you use this tool to review code, you will quickly reach a consensus on granularity and code length.

It is not difficult to build a system. But it's hard to make the system great. The model diagram of a great system must also be very beautiful. The code refactoring, function merging, splitting and so on that are needed to achieve this beauty need and are worth the effort. And my tools provide the best platform for this kind of grinding.

Interface design problem Context design ideas and how to encapsulate? As a resource chain, Context has been designed as a tree structure by some systems in the past, such as: RootContext (root) |-ChannelContext (channel) |-SessionContext (session) |-Context (service)

Data search and operation are carried out from the subordinate node to the superior node, and the service-level Context (used in the business process) is automatically destroyed and stateless after the completion of the process.

Recommendations:

It is possible for complex systems to use this idea. A simple system does not need so many layers, as long as it is sufficient. The purpose of providing Converter is to encapsulate / isolate the data as much as possible through the conversion interface, so that extraneous unit cannot see all the information.

Can the application system implement its own Context according to the actual situation? Because many existing systems already have their own Context.

As a data container, Context manages and carries the data used in the business process. The toolset provides the definition of Context interface: public interface Context {} and the specific implementation of MapContext. Can the application system implement its own Context according to the actual situation? Because many existing systems already have their own Context.

Answer:

Of course, only an empty interface is defined in order to adapt to all situations.

(3) how does the service request data be automatically bound to Context?

Json data (front-end submission) → service (parsing json data and converting the data to java types or objects), how to achieve this does not require developers to manually set the converted java types or objects to Context one by one, but the framework automatically assigns these data to Context. Developers operate the data through the get methods and set methods provided by Context, without paying attention to the internal construction of Context.

Recommendations:

Generally, data binding is provided by a specific access platform. For example, with Jerssy, you can directly bind the request to the implementation of a specific Context, depending on what capabilities your platform provides. Since this piece is not within the scope of xunit, it is not provided by default. I intend to provide some examples based on web containers later.

At present, what are the solutions or ideas used by companies that have used xUnit for development in the face of the above problems?

One Internet healthcare company I know uses container-based request-to-context mapping. The container first maps the requested field to a specific field of context. After obtaining the initial context, the system provides other necessary information at the session or app level through subsequent processing. I can't find the specific code example right now.

Does xUnit consider configuring Context through a visual interface from the data model level, such as the data definition of Context?

This is not the core function of xunit. It can be used as a gadget.

Problems related to integration with existing frameworks existing frameworks or platforms such as dubbo, spring cloud, etc., are widely used. After xUnit graphically assembles the business processes that were originally coded and implemented in these services, how can xUnit processes be integrated into these frameworks?

The methods given in the examples are: XunitFactory f = XunitFactory.load ("new_xross_unit.xunit"); Processor p = f.getProcessor ("chain1"); TextContext ctx = new TextContext ("xUnitTest"); p.process (ctx)

Do all services need to write this fixed format code to execute the business process? Or is there another way?

Recommendations:

You can use the factory of spring

Is there a way to continue to use frameworks such as dubbo and integrate xUnit without writing code like "eight-part essay"?

For example, the FacadeService (specific business process implementation) exposed to the dubbo server after assembling its internal business process through xUnit, its internal code has been extracted and encapsulated into a single functional component for reuse, resulting in no other valid code in the FacadeService except the above fixed code to execute the business process. That is, the code is made up of public void addBannerinfo (para1, para2, …) Throws ServiceException {/ / Business process implementation. . }

Evolve into:

Public void addBannerinfo (para1, para2.) Throws ServiceException {/ / execute business processes XunitFactory f = XunitFactory.load ("new_xross_unit.xunit"); Processor p = f.getProcessor ("chain1"); TextContext ctx = new TextContext ("xUnitTest"); p.process (ctx);}

However, if you do not implement FacadeService and configure the relevant dubbo server, the service will not be automatically registered with the service center, so you will not be able to continue to use the original platform services for automatic registration and discovery, service governance and other features. Is there a way to continue to use these frameworks and integrate xUnit without writing code like "eight-part essay"?

Recommendations:

The reason why you have this problem is that you manage all the processes in one large process through xunit. You can still provide registration at the original service granularity. You can provide a separate process for each of the original services. There will still be multiple FacadeService to configure and register. And you can do a general FacadeService implementation, using parameterization to avoid defining multiple classes.

Exception handling what is the exception handling mechanism of the X-Series toolset?

An exception is thrown directly within the unit, so if there is an exception in a unit, you can

This unit handles the exception itself, captures the exception and places the exception information or flag in the context

Exception handling is performed in a decorator,ecorator wrapped around the unit. Specific fields can be set according to the captured exception, and the exception flow can be judged and handled by validator/locator in the subsequent processing steps.

No handling, exception thrown for the outermost caller to handle

During the process processing, are the thrown exceptions handled uniformly by the toolset or thrown as-is, handled by the external executor?

See above to answer.

Can the compensation mechanism be supported to facilitate subsequent processing after an exception occurs in the execution of the process?

See above to answer.

Database transaction in the same process, if there are multiple database operations among multiple components (for example, DB component 1 and DB component 2), for example, an exception occurs when the process is executed to DB component 2, what considerations or supporting measures does the toolset have to ensure the success or failure of both DB component 1 and DB component 2 in order to ensure data consistency? Does DB component 1 perform a rollback based on the pre-configuration of the toolset (such as stand-alone transactions)? Or do you use the global transaction configuration for unified submission after the normal execution of the process?

This is not the scope of xunit, how to deal with it depends on your needs. You can wrap the process in things. I have a research project on database lock-free operations, which should solve this problem. Coding has not been officially started yet.

Does xUnit consider supporting database transaction control in configuration (by extending some independent database operation components according to the actual situation of the business system)? Or is it controlled by developers only from the application development level?

This is outside the scope of xunit.

Industry-specific component extension of component library

X-Series provides a lightweight tool set independent of platform and business, which well solves some problems encountered in previous development. For example, using existing Processor components, process development can be achieved by configuring specific business implementation classes. However, this flexible support may cause great trouble, and poor control will result in a large number of Processor component implementation classes that cannot be controlled. At the same time, many companies have been ploughing in some business areas for many years, and there are more technologies to achieve accumulation and precipitation. Once xUnit is applied to specific industries for development, if companies can encapsulate industry-specific reusable components on the basis of existing xUnit according to their own conditions, such as [schematic diagram of user component library]

Will be able to effectively reduce the developer development threshold and development costs, and control code quality. In the process of development, ordinary developers only need to know the functions and usage of each component, and simply configure some business-related properties by dragging the component directly. In most cases, ordinary developers are no longer required to specify or even write their own specific implementation classes (configured when specific components are encapsulated). In fact, in large and medium-sized systems, it is impossible and impossible for ordinary developers to understand what specific classes implement what functions in the application. Eventually, it will cause different developers to write their own implementation code for the same function, resulting in difficulties in maintenance. Even if the original application already has relevant implementation classes for reuse, it results in repeated development because the developer does not understand it. (1) so, how do people at the framework management level customize and extend their common components in the industry? (2) what is the basic flow of implementing components, and is there a Demo? (3) what skills are required for component expansion? Must be proficient in Eclipse plug-in development (with a high threshold)? Can you provide some advice and learning materials on plug-in development?

Suggestion: your question is so complicated that I can't answer it because it is related to the specific field. As for 3, if the current plug-in development is like xunit, the threshold is frankly very high, and it took me a long time to get this thing done. If it's just a function like your screenshot, it should be relatively simple.

Is the release strategy process configuration file released together with the program code package or uniformly released by the configuration center?

Either is fine. If the release is highly automated, it can be packaged. If the overall code is too large, it is recommended to put the configuration in the configuration center.

Does it support online update / replacement without restarting the service?

Yes, that's what Ctrip does. # if it supports the unified release of the configuration center, can it be integrated with Ctrip's open source configuration management center Apolo? Yes # will it affect the ongoing process during the online update process? Update operation is to regenerate the flow, replace the original, the old context processing or continue to finish, the new context request to go to the newly created flow

Load policy what loading mechanism is used by the XunitFactory.load ("new_xross_unit.xunit"); method before each execution of the process?

This can be done once during system initialization, @ WebServlet ("/ PeoplePortal") public class XunitPeoplePortal extends HttpServlet {private static final long serialVersionUID = 1L; private PeopleDao dao; private Processor demo

/ * * @ see Servlet#init (ServletConfig) * / public void init (ServletConfig config) throws ServletException {try {demo = XunitFactory.load ("dal_demo.xunit"). GetProcessor ("main");} catch (Exception e) {throw new ServletException (e) }} / * * @ see HttpServlet#doGet (HttpServletRequest request,HttpServletResponse * response) * / protected void doGet (HttpServletRequest request,HttpServletResponse response) throws ServletException, IOException {WebContext context = new WebContext (request, response, dao); try {demo.process (context);} catch (Exception e) {throw new ServletException (e) }} do you need to parse the process profile in real time every time?

Do not need # or can it be loaded in the cache when it is hit and then read? There is no internal cache. As long as load is called, it will be read again.

If cache loading is supported, how do I reset the cache when subsequent configuration files are updated? Directly invalidate the cache?

The cache of factory is left to the user.

How do components begin and end issues related to component design? Are the start and end components that must be configured in a process?

If it is xunit, no, just provide the start and end nodes above to display in order to follow the conventions of these diagrams. If it is a state machine, the user can provide a trigger at the start and end node

Adapter component, how to understand "translating the behavior of one unit into another"?

For example, if you only have processor class but no code, or you are too lazy to write, and the step you need is converter, you can provide converter behavior through adapter, call the previous processor internally, and do the extra processing you need.

Automatic attribute recognition: how to understand "as long as any component defines a static String constant that begins with PROP_KEY, after opening through the editor, the contents of the defined constant can be recognized and displayed by the editor as configurable properties of the component. These properties are set through the UnitPropertiesAware interface when the component is created." ?

You define a processor, which defines a PROP_KEY_abc = "abc". If the class is bound to a processor in the xunit editor, there will be an abc attribute in the property bar. This is just a contract that defines what properties can be set.

In each component, if you need to get the value of a property, do you need to independently implement the setUnitProperties (Map arg0) method of the UnitPropertiesAware interface? For example: @ Overridepublic void setUnitProperties (Map arg0) {testValue = Double.parseDouble (arg0.get (PROP_KEY_TESTFILED));}

This is currently the case, so if you do not implement this interface, even if the property is defined, it will not work, and you may consider dealing with it in a reflective way later.

Treatment of structural inconsistency

"if the behavior mode of Chain is Converter and the Chain contains Processor, the input Context of Processor is passed to the next unit as the result of Convert." "if the behavior mode of the Chain is Processor and the Chain contains Converter, the convert method of the Converter is called, but the converted output Context is discarded. The initial input Context is passed to the next unit." How to understand these two points?

Answer:

This is the internal default adapter implementation of processor and converter. If chain is converter and there is processor in it, according to the definition of converterchain, each unit should be converter, and the current one is indeed processor. According to normal processing, the processor should be packaged with an adapter and packaged as converter, but since this is a common phenomenon, general processing is done in this way. Think of processor as a converter whose inputs and outputs are of the same type of context. Another similar treatment

The Default implementation of xUnit requires the showMessage property to be specified when displaying specific information as Processor and Converter. The runtime displays the given content directly, and the showApplicationProperties property needs to be specified to display the application-level properties. Property names are separated by ",". How to understand and use these two attributes in practical application?

The implementation of Default is only to facilitate people to quickly build and run the prototype of the system without writing code, and to let users adjust the system and show real interaction by displaying the provided string.

Is there any plan for the X-Series toolset to develop into a development platform (other than Xeda)? Or, in addition to the process definition, provide some other support, such as: (1) data definition: (2) data message: (3) data dictionary (4) visual management of core configuration file

These are supported by ready-made and good tools. So I quit. My principle of providing tools is to provide only blind spots or functions that none of us have.

Thank you for your reading. I believe you have some understanding of "what are the common problems of xunit?" go ahead and practice it. if you want to know more about it, you can follow the website! The editor will continue to bring you better articles!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.