Information System Practice Notes 4-some considerations of platform docking

Source: Internet
Author: User

Description: Information System Practice Notes series is the author in peacetime research and development has encountered the size of the problem, perhaps simple and subtle, but often is often encountered problems. The author is more typical of which to collect, describe, summarize and share.

Absrtact: This article describes the interface between the information system or the platform which the author has contacted, and exhaustive to share it.

Body

Series of essays Directory: Information System Practice notes (http://www.cnblogs.com/taichu/p/5305603.html)

In

Reprint instructions: Please specify the original author, connection, and source.

1. What is platform docking?

There are two general information systems: one is a single set of single-function, the general comparative Professional, installed on a single general or specialized hardware, unified user interface (such as the client) dedicated to perform a function. It often completes its own data collection, calculation, presentation, control, feedback and other content. The other is groupware. The information system contains multiple modules (typically differentiated by high-function cohesion), or even multiple platforms (defined as platforms with a set of more complete sets of features). If the latter is a multi-platform connected to the larger information system, it will certainly be more platform docking? Why? Of course, a contract in the information system of multiple platforms, is generally a number of manufacturers (companies) development, mutual third-party, cooperation to complete the overall function. Each small part (platform) must be connected to one another in accordance with certain rules and mechanisms. This is the problem of platform docking.

2. What are the aspects to be considered for platform docking?

Generally, in terms of their own platform or the company's platform product perspective, you will find that your platform A, will need docking platform B, platform C and so on, then what should be considered?

  • Partitioning of functions between platforms
    • This is often where the product manager and the program manager are. The products developed by the Research and development department are "FeatureList" (functional collection). Take these bricks and build up a number of schemes solution, which is the "Functional Boundary" (SCOPE) provided by our products or platforms. Figuring out your scope, you also need to know about the "functional boundaries" scope of several other third-party platforms.
    • And so on all platform A,b,c, who do, argue after, set, e-mail issued leave evidence, form to the user's final plan, led by the integrator, and organize the deployment of different platforms and the joint adjustment.
  • Inter-Platform Interoperability Protocol determination
    • Now that the functional boundaries are defined, the interoperability between the different platforms is put on the agenda. We need you to sit together and make an agreement based on your needs.
    • In general, each platform has a "system expert (architect)", will participate in the discussion, integrator lead, this time to see who strong. Each platform wants to do or less to do additional development, the other party directly in accordance with their own agreements or standards to docking their own signaling and data, this is a fact, the truth of the time. But objectively there can be rules to follow.
  • Platform Interoperability Protocol design principles
    • try to stand on your own platform, trying to change the smallest, most convenient, this is the first.
    • use common technical frameworks as much as possible, such as GB GBXXX, International standard H264,RTP/RTSP,SIP. This is beneficial to the later linking, docking, grasping, analyzing, leaving evidence, etc., to be clear. This second.
    • try not to temporary early adopters, find an immature framework or agreement, each platform is not very understanding, no domain experts, such things absolutely can not do, but often do not know the technical leadership will be required. This is its third.
    • In other cases equivalent, try to use a simple technical framework, because docking is a troublesome thing, the unexpected trouble will certainly happen (Murphy's Law), can save the province, can reduce, the four.
    • encountered a new situation, must not directly think about the workaround approach, want to go around the past, the final must be a disadvantage, it should be in the initial docking difficulties on the table, everyone noisy, this its five.
    • Smart PM will suggest, do not put the workload on a platform, bullying him in order to make money and willing to yield, you need to review its manpower, ability, whether the delivery on time, even if there is a contract guarantee, but objectively speaking, research and development is a scientific process, the workload imbalance, not only easy to cause unnecessary " Critical path "and often leads to overall failure. Even if the compensation, the extension also to the whole solution disadvantage. This is its six.
    • The rest of the technology, the above considerations, belong to the technical aspects, there are many principles, but the general rule of laws, the rational can be said, and then described below.
  • Development of platform interoperability and joint adjustment
    • Each platform will be developed and will be linked. Always remember, to be prepared in advance, as soon as possible to cut into development, do the initiative of the urging, do not do passive laggards. Although the urge is easy to spend effort to coordinate, keep an eye on each other, but the process of commissioning is biased to their own, can get the initiative, the other side around your head, you get the "Management authority"!
    • Ready to meet the error, the joint tune will be wrong, to have the means to test, audit, grab the package, check the process (step-by-step troubleshooting network elements), view signaling, view data, no according to the professional embodiment, it is often easy to lead to multi-entanglements and excuses. Must be pre-emptive to give evidence, even if wrong, do not lose face, actively promote, get the "joint initiative", let other people's manpower around you.
    • Commissioning completed, the main line merge code, must be formally out of the package, on-site re-test! This is very important. Because there are often multiple sites, a third-party platform also has multiple versions, the other side of their own version management may have problems, your own version management will often be busy in error, be sure to re-test, hold the version number to speak.
    • There are too many lessons to be cited.
  • Platform Interoperability Closure
      • In fact, there are a lot of things to do in the joint transfer. For example, technical summary, Project process summary, version storage, branch and main line of the merger, workaround processing, the disposition of legacy issues.
      • The functionality of this interlock is also synchronized to the main line or branch to provide additional onsite deployment and upgrades.

3. Platform docking practical experience sharing

  • Project Experience
    • take the initiative and be sure to have our Product manager, Program Manager, System expert (architect), project manager, as early as possible to discuss, even detailed technical solution discussion.
    • clearly divides the work interface, product scope, interface definition clear, not arbitrary, not arbitrary, there is a good debate, here is the most easily disputed. The
    • uses its own familiar technology to be compatible with each other's acceptance and balance the workload.
    • Be sure to identify the interface person, determine the time, even if the last time will certainly change, start uncertain, the last change on the side flaky!
    • Some third parties throw over 3 developers, do not manage, let us pm ourselves to manage, to remember, this is a good situation, the other side depends on not work is the most troublesome.
    • with the "Progress table", "Bug tracking Table" and other support PM work, it is important to stare at each other, get the joint initiative. Take the initiative, lead the joint adjustment, to ensure that their platform is not dragged.
    • Complete, code merge, release record, re-release of the official version of the test, must be meticulous, don't be happy, the result is messy.
  • Technical Experience
    • General platform docking, signaling to docking, data also to docking. Signaling docking is mostly the transmission of data structures, typically the delivery of "device List", this situation is too much. How does it pass? There are many ways.
      • There is a direct way to read the other side of the DB: fast, simple, direct, rough, not very recommended, unless it is a brother product can be "deep integration", otherwise there will be problems, the other side of an upgrade will lead to unpredictable situation.
      • Interface Docking Method: This is the usual method, the general speed can also be relatively complex, but the coupling degree is low, universal and strong. The other side even upgrade, but need to maintain the interface does not change, and the test is convenient.
      • According to the standard interoperability: for example, according to a certain area of "GB GB" docking "equipment list" and other signaling information, then we have to thoroughly understand standard, often interoperability, some standards even have additional "custom" field, these are pits! A careless fall in, must often discuss meetings, exchange progress. Additional technical interfaces and protocols can also be developed as a guarantee of change.
    • Docking platform In addition to signaling, the most is the data. General data will be large, demanding high-speed, real-time, which on both sides of the platform is a test.
      • Friendly consultation between the two sides, whether or not the other party is professional, we must report the results of professional consultation analysis, discuss with each other.
      • To discuss the laws of the data, the frequency, peak, regularity, performance, spatio-temporal characteristics, whether it is necessary to store, data in the consumption node PX a series of behaviors. Data initiation and termination nodes are often of additional importance.
      • Select a good data structure, consider the need for security and compression.
      • Consider the solution of the node PX failure time, and consider the abnormal situation.
    • There's a lot of experience, and finding a reliable system expert is the key.

Description: Please contact the original author if you have any questions about the relevant proper nouns or other issues. Article content, for reference only.

[END]

Information System Practice Notes 4-some considerations of platform docking

Contact Us

The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion; products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the content of the page makes you feel confusing, please write us an email, we will handle the problem within 5 days after receiving your email.

If you find any instances of plagiarism from the community, please send an email to: info-contact@alibabacloud.com and provide relevant evidence. A staff member will contact you within 5 working days.

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.