锘??xml version="1.0" encoding="utf-8" standalone="yes"?> Modules are discrete units of software (binary and source).
Binary modules are instantiated at run time and these instantiations are
commonly called components and connectors. A given module may contain the specifications for
several component types and connector types. The component (instances) may be of
a fixed number in some situations. For example, a Web server executable, when
launched, results in a single Web server component instance. The Web server module is the binary code that exists as a set of
program files. The Web server component is a running
instance of the Web server. I have seen some confusion over the use of the terms module, component, and connector. A module is a discrete unit
of design that is composed of a hidden set of elements and a set of shared
elements. Modules have high internal cohesion and low external coupling. Modules
may represent the physical packaging of the application's binary code, which can
be described further by component types and connector types. Components and
connectors describe the physical instantiation of a system. The term component is often used to mean a component type or module. A
module refers to a unit of software that can be designed,
implemented, and compiled into a deliverable executable system or subsystem; it
is a unit of execution. A component is a runtime entity,
the definition of which exists in a module. A classic modular architecture is a
client-server system. The client and the server are two modules. The server
exports some elements such as a set of publicly visible relational database
tables and views. The client knows about this publicly visible schema. The
client and server are unaware of the internal composition of the other.
]]>
1 .鍙傝冧竴涓嬨婅蔣浠舵灦鏋勮壓鏈嬩竴涔︼紝Stephen T. Albin 鍦ㄩ噷闈㈡弿榪幫細
妯″潡寮忚蔣浠惰鍒掑垎鎴愮嫭绔嬪懡鍚嶇殑錛屽茍鍙鐙珛璁塊棶鐨勬垚鍒嗐傛ā鍧楀垝鍒嗭紝綺掑害鍙ぇ鍙皬銆傚垝鍒嗕緷鎹槸瀵瑰簲鐢ㄩ昏緫緇撴瀯鐨勭悊瑙c?/span>
榪欎釜瀹氫箟錛屼技涔庢湁娌℃湁銆婅蔣浠舵灦鏋勮壓鏈嬮偅涔堜弗鏍箋傛病鏈夊畾涔夊叿浣撲粈涔堜負“琚嫭绔嬭闂?#8221;鐨勬垚鍒嗐?br>3. 銆奃ocumenting_Software_Architectures銆?br> A module tends to refer first and foremost to a
design-time entity. Parnas's foundational work in module design (1972) used
information hiding as the criterion for allocating responsibility to a module.
Information that was likely to change over the lifetime of a system, such as the
choice of data structures or algorithms, was assigned to a module, which had an
interface through which its facilities were accessed.
鍏惰錛屾ā鍧楁槸璁捐鏃剁殑瀹炰綋錛岀壒鐐規槸淇℃伅闅愯棌鍜岃兘閫氳繃妯″潡鐨勬帴鍙h闂傚湪浠嬬粛妯″潡瑙嗗浘鏃朵粬璇達細
A module is a code unit that implements a set of responsibilities. A module can
be a class, a collection of classes, a layer, or any decomposition of the code
unit. Every module has a collection of properties assigned to it. These
properties are intended to express the important information associated with the
module, as well as constraints on the module. Sample properties are
responsibilities, visibility information, and author. Modules have relations to
one another. Example relations are is part of or
inherits from.
---------------------------------------------------
涓嶅悓鐨勪綔鑰呮湁涓嶅悓鐨勭湅娉曪紝浣嗙患鍚堜竴涓嬶紝鎴戣涓烘ā鍧楀洜璇ユ槸涓涓嫭绔嬭璁$殑鍗曞厓錛屽茍涓哄叾浠栨ā鍧楁彁渚涜闂帴鍙c備篃灝辨槸璇達紝浠栨槸涓涓灦鏋勪腑鐨勮璁″厓绱狅紝浣嗕笉闄愬埗浠栫殑瀛樺湪妯″紡錛屼篃灝辨槸浠栨槸鎻愪緵浜嗗彲璁塊棶鎺ュ彛鑰屼笖瀹炵幇鏌愪竴鍔熻兘鐨勪竴涓疄浣擄紝鍙互鏄竴涓被鎴栦竴緇勭被鎴栧彲鎵ц紼嬪簭絳夈?br>
]]>
]]>
OPAL VOIP錛?淇濈暀Opal鐜版湁H323鍔熻兘錛屼絾閲嶇偣鏄庢樉鏄鍚戝吋瀹?span lang="EN-US">SIP鏂瑰悜鍙戝睍錛涘叾緗戠珯浠嬬粛涓猴細
OPAL implements the commonly
used protocols used to send voice, video and fax data over IP networks.
Originally part of the OpenH323 project, OpalVoip has grown to include SIP and
IAX2.
h323plus錛氬湪鍘熸湁OpenH323鍩虹涓婄戶緇畬鍠?span lang="EN-US">ITU鐨?span lang="EN-US">H323緋誨垪鐨勫崗璁紝鍏朵粙緇嶄負錛?/span>
The H.323 Plus project intends to do much more than simply provide a new
home for open source H.323 developers. Developers have told us they intend to
work to provide significant new enhancements to the very successful H.323
systems deployed worldwide. For example, NAT/FW
traversal, instant messaging, presence, and many other enhancements are
already in progress or being planned. Further, the open source community has
expressed interest to us to enable more collaborative features to H.323,
including such things as application sharing, whiteboarding, and other
capabilities.錛堝彲鎯滐紝榪欎簺鍔熻兘OPAL灝嗕笉鑳界敤鍒頒簡錛?span lang="EN-US">
鑷充簬搴曞眰鐨?span lang="EN-US">pwlib錛堝嵆ptlib錛変及璁℃殏鏃惰繕浼氫繚鎸佷竴鑷淬?span lang="EN-US">
鍒嗗鍚庢湡閭歡鍒楄〃涔熷皢鍒嗗紑錛?span lang="EN-US">
https://lists.sourceforge.net/lists/listinfo/opalvoip-devel
http://lists.packetizer.com/mailman/listinfo/h323plus
緗戠珯鍦板潃鍒嗗埆錛?span lang="EN-US">
http://www.h323plus.org/
http://www.opalvoip.org/
瀵逛簬鎴戜滑鍙兘浼氭洿鍏沖績OpenH323鐨勪富瑕佸紑鍙戣?Simon 鐨勪互涓嬭█璁猴細
The following projects are currently
planned to be supported within H323plus.
OpenMCU (including remote conference
controls) OpenAM (upgraded to support
VoiceMail support to GnuGk) MyPhone OhPhone
The Library is almost drop-in
replacable with the existing OpenH323 and contains numerous enhancements
including video plugins (compatible with
Opal) and large amount of new work
not currently supported in Opal.
Some of the new work now available in
h323plus H.230 Conference Controls (incl
tunneling GCC (T.124))
H.239
Application Sharing
H.249
Extended user inputs
H.341
SNMP support
H.350
LDAP WhitePages
H.460
Numerous custom Extensibility features
Text Messaging (working doc ITU),
Follow Me,
PDI (Personal Data Interchange)
H.460.9 RealTime QoS Measurements
Video Plugins (fully compatible with
Opal)
H.235 Plugins (for external Biometric
and smartcard authenticators) QoS Capability negotiation Conference Controls
capability advertisement.
New work planned/proposed
H.460.presence
H.460.18/19 Nat Traversal
Video on Demand project (using
H.239/H.249)
We can also provide full consulting
service support for existing openH323 based projects as well as provide
assistance in migration of these projects to h323plus.