Visual Studio .NET 애드인 형식의 Subversion 클라이언트 프로그램입니다. VS.NET과 통합성이매우 높습니다. VS.NET의 솔루션 뷰에서 커밋, 업데이트 등의 작업이 가능하며 솔류션 뷰의 각 파일에 수정되었거나 수정되지않은 파일의 상태를 표시해줍니다.
MOM을 Java로 구현한 xmlBlaster가 감동을 주는군요. http://xmlblaster.org에서 필요한 자료만 추려 보았습니다. 성격이 급하신 분들은 Cool demos와 Replication Demo를 먼저 보시는 것도 좋은 접근이 되겠군요. XMLParser로 Xerces를 사용하기 때문에, C++ Client를 빌드하기 위해서는 xerces-c-src_2_7_0.tar.gz가 필요합니다.
XmlBlaster is MOM (Message oriented Middleware) with a lot of features.
XmlBlaster is a publish/subscribe and point to point 100% Java based MOM server (message-oriented middleware) which exchanges messages between publishers and subscribers. The message is described with XML-encoded meta information. Messages may contain everything, GIF images, Java objects, Python scripts, XML data, a word document, plain text - just anything.
Communication with the server is based on socket, CORBA (using JacORB), RMI, XmlRpc, HTTP or email, clients are free to choose their preferred protocol. Other protocols like SOAP may be plugged in.
Subscribers can use XPath expressions to filter the messages they wish to receive.
This is the publish/subscribe middleware server you have needed many times before, now available for free to glue together your distributed client/server application.
The xmlBlaster server is pure Java and under LGPL.
PHP, Perl, Python, C, C++, C#, Visual Basic.net, Flash, J2ME, Java (applications, servlets, applets) client samples are delivered in the xmlBlaster distribution.
You should be ready to go with your preferred development language.
XmlBlaster provides a browser callback framework, allowing browsers (Mozilla, MSIE, Netscape) to receive instant callbacks over a persistent http connection.
Features:
Free for private,commercial,education use (LGPL - License)
Message Orientated Middleware (MOM) with Publish/Subscribe and PointToPoint (PtP) support
Multi platform support (server is pure Java)
Multi protocol support (CORBA, RMI, XmlRpc, raw socket, EMAIL, native access)
Language neutral (clients for C++/C, Java, Python, PHP, Javascript, Perl, C#, Visual Basic.net ...)
Client side persistent queuing with C/C++/Java/ActiveX/Javascript
When a publisher sends a message toxmlBlaster it passes several plugins until it is rejected by a pluginor savely stored in the server.
When a subscriber subscribes on atopic, the message is passed with a callback to the subscriber,traversing several plugins before it is delivered.
The grafic below gives you an overviewof such a message flow. Please click on the plugin symbol to get moreinformation about the plugin and how to code and register a specificplugin yourself.
The grey plugins are mandatory, youneed to registered a plugin, otherwise a default plugin is chosen.
The green plugins are optional, theyare registered on startup. The mime plugins are activated dependingon the message mime type, the dispatch plugin is activated on demandby a client on login.
The brown plugins allow to control theclustering behavior, they are mandatory if clustering is switched on.
Fig:Message flow in the server (click on plugins for detailedinformation)
The following table shows on the columns different implementationlanguages for the clients and on the rows the different features aredisplayed. If a certain feature is already implemented, a green tickis written into the corresponding cell. In case the feature is notimplemented yet (or if the language does not allow this kind offeature) a red cross is drawn. For features under implementation agreen arrow is drawn.
Publishing ten thousand small messages to xmlBlaster, which updates the messages to one subscribed client. The published and updated messages are acknowledged:
672 messages per second
on a AMD-K7 600 MHz, both client and server on the same machine running Linux 2.4.4 using JRockit 3.1 JVM with JacORB 1.3.30 CORBA lib.
The java virtual machine options are set to -Xms18M -Xmx32M: java -server -Xms18M -Xmx32M org.xmlBlaster.Main java -Xms18M -Xmx32M org.xmlBlaster.test.stress.LoadTestSub
The socket connections eat up most of the cpuload, thereafter XML parsing is expensive. The xmlBlaster code itself only consumes little of the processing time.
Green threads and native threads have more or less the same performance.
Running xmlBlaster and "TestSubManyClients" on the same machine.
There are in this example 10-thousand clients which login to xmlBlaster simultaneously.
For RMI, every login consums ~9 kByte on the server, for CORBA ~11 kByte per login.
All 10.000 clients subscribe to a message.
A publisher client then publishes this message which is updated to all 10.000 clients.
With CORBA, 435 messages/sec are delivered
on a AMD-K7 600 MHz, both client and server on the same machine running Linux 2.2.16 using JDK 1.3 (IBMJava2-13) with JacORB 1.2.2 CORBA lib.
With POA/CORBA the server request handling is finegrained adjustable, here we used 'one thread per request' policy (using a thread pool).
With RMI no server policy is adjustable, looking into Suns java code shows us, that they use 'one thread per request' policy as well (but this is nowhere specified).
In both cases, the number of clients is only limited by the amount of memory (RAM) you have on your server.
Delivering messages in "burst mode"
The "burst mode" collects messages over a certain time and sends them in a bulk.
Collecting 10-thousand messages and publishing them in burst mode, with no client update.
CORBA resulted in 2647 messages/sec
RMI resulted in 2763 messages/sec.
XMLRPC reached 1431 messages/sec.
on a 600MHz Athlon
XmlBlaster does XML parsing for each message.
Message latency
Data about the brutto round trip latency of a message publish/update.
The following results are for one round trip including publish -> processing in xmlBlaster -> update -> parsing in client on a 600 MHz AMD Linux.
CORBA in intranet: ~ 6 milliseconds
XMLRPC in intranet: ~ 16 milliseconds
CORBA over internet: ~ 105 milliseconds
XMLRPC over internet: ~ 320 milliseconds
The persistent http pushback over internet is not measured yet, but expected to be ~60 milliseconds (only the update).
Tested with "java Latency" in directory xmlBlaster/demo/javaclients/Latency.java
Try a traceroute 'desthost' to compare the MoM based round trip with the raw tcp/ip roundtrip times.
Message throughput per second native compiled
The same scenario as above but compiled with TowerJ 3.5.0 native compiler on Linux:
20% - 35% performance increase compared to JDK 1.2.2
It is possible that these number are higher in other test scenarios since this test case cycles mainly in TCP/IP calls.
Publishing one thousand different messages with only 8 bytes of content and with a relatively small meta data key to xmlBlaster (x86 PC):
Approximately 2.4 KByte RAM per message
Note this is the raw memory consumption of xmlBlaster to handle a single message. Your message content (for example a gif picture or some text) must be added to this value. The message content may as well be a pointer to some bigger file to avoid RAM consumption.
XSL and XML performance
As XSL processor we use XT written by James Clark.
The XML engine is currently Crimson from Sun for JDK <= 1.4 and since JDK 1.5 the natively delivered XML parser
This is not one of the fastest combinations today, but there may be the option to switch to another parser in future xmlBlaster releases.
See the performance overview, copied from the XSL mailing list for coding hints.
Please visit XSLBench, the performance benchmark of XSLT processors for further informations.
This performance test from Kuznetsov and Dolph shows that XT is still superb performing. Java XML Benchmark Results Here is a comparison of SAX2 versus pull parser performance and here another interesting one.
The Java virtual machine
The used Java virtual machines have a high impact on the overall performance.
The Volano Report gives a good overview about current implementations, as a result we may run some tests with the IBM virtual machine in future.
See Suns comparison as well.
The Solaris tar is not compatible with our GNU tar. Solaris users should download the zip version or install a GNU tar on their machine.
Installation:
Unpack the distribution and follow these guidelines.
For more thorough installation informations please read the file xmlBlaster/INSTALL in the distribution.
SIP Server Framework is a powerful framework to build carrier-class reliable, scalable and feature-rich SIP applications. The FSS SSF comprises two components:
SIP Core Infrastructure Server
SIP Application Server
SIP Server Framework serves as a base for Proxy as well as any other SIP-based server entity. SSF therefore, radically reduces time-to-market by providing a hassle-free infrastructure that:
Implements all the core SIP functionality including state information automatically.
Provides a carrier class framework that easily allows new components to be added in and out dynamically as well as statically.
The SIP-SF is a powerful yet flexible solution. It provides tested and standards compliant core SIP functionalities like Call State Control Function (CSCF), Proxy, Registrar, Redirect, B2BUA, and Location Server. More importantly the framework allows application developers to build upon these core functionalities and deliver niche applications. The framework isolates the application developer from all SIP specific protocol and behavioral details. The application developer can focus on what services to provide and the framework can take care of how. FSS' carrier class, proven, interoperable solution thus helps the customers in reducing time and development costs. The FSS solution, one of the most proven and mature products in the industry, handles live traffic for the largest Service Providers' network and for one of the largest Internet Telephony Service Provider (ITSP) Network in Japan.
FSS (formerly HSS)has also introduced Centrex functionalities in its SIP-SF. The Centrex feature enables Equipment Manufacturers to build a hosted PBX solution in minimal time. The FSS SIP Server Framework with Centrex functionality is a powerful framework with a sophisticated dial plan, a hunt group, privileged profiling and intranet/extranet calling.
SIP-SF Architecture
FSS' award winning SIP Server Framework (SIP-SF) ("Internet Telephony" Product of the Year 2002 and "Communications Solutions" Product of the Year 2003) is an ideal platform for hosting SIP services. SIP-SF is a ready-to-deploy SIP Proxy, Registrar, Redirect, Presence and Location Server. FSS’ SIP-SF today provides several advanced features, including SIP Centrex (Hosted PBX) and Per-User Call Processing Language, all of which render tremendous value in using it as an underlying platform to build new services while significantly reducing time, risk, and cost to market. The SIP-SF is a ready-to-deploy platform with Virtual IP redundancy, SIP Load Balancing, SNMP Manageability, Congestion Control, Emergency Calling, and other real-life network requirements already addressed.
Targeted at OEMs, SIP-SF has been developed keeping in mind the flexibility and extensibility that OEMs so much need to be able to offer differentiated products to the market.
FSS' SIP server is a dual play architecture, positioned as both Core Infrastructure and Application Development Framework.
SIP-SF Core Infrastructure Element
OSA Application Server
FSS’ SIP Server can be positioned both as the SIP core infrastructure element to build basic infrastructure needed in a SIP Network or using its B2BUA feature set, as well as an application infrastructure to build applications, such as Collaboration, CTI, and Gaming. The SIP-SF thus enables one to easily integrate multiple call models, be it BCSM-based or RFC 3261, and to use any one of them depending on the kind of service being executed. Further, the SIP-SF can be made to interact with an SCN using a regular BCSM-based model and at the same time, perform forking functionality of proxy using the regular 3261 UAC/UAS model.
SIP-SF Features
Salient Features
Ready-to-deploy SIP Proxy, Registrar, and Redirect Server
Value-added features including SIP Centrex, Call Processing Language, and Presence Server
Integrated load balancing and high availability platform
Multi operating system portability
Easy management - SNMP, API, XML
Multiple database support - ODBC
Supports both IPv4 and IPv6.
TLS security and digest authentication
Support for emergency calls and priority routing
Implemented in C++ to offer complete object-oriented interface
Configuration through Number Translation Mark up Language (NTML)
Architectural Superiority
The key architectural features of the SIP Server Framework are:
High scalability - performance increases with increase in number of CPUs
Can support multiple CSMs (service logic) simultaneously
Support for user-defined service logic
Component-based architecture- can chain components as desired for future enhancements
Supports distributed operation across various nodes
Centralized configuration of all components
Message-based interfaces
Threaded model-thread pool management
Easy integration with third party modules- all functional modules implemented over APIs
Compliant to ISO C++ and EC++ standards to ensure maximum portability
Key Standards Compliance
'SIP: Session Initiation Protocol', RFC 3261
'HTTP Authentication: Basic and Digest Access Authentication', RFC 2617
'CPL: A Language for User Control of Internet Telephony Services', draft-ietf-iptel-cpl-06
'URLs for Telephone Calls', RFC 2806
'Management Information Base for Session Initiation Protocol', draft-ietf-sip-mib-04.txt
SIP Application Server Features
The SIP Application Server (B2BUA) provides a scalable, reliable, andfeature-rich environment for rapid service creation. FSS' B2BUA Serveris a framework that exposes a set of well-defined APIs to theapplication to develop various services, such as Prepaid, NatTraversal, Call Queuing, Click-to-Dial, and Call Pick-Up. These APIs aswell as their parameters are Open Service Architecture (OSA)-compliant.In addition, FSS' B2BUA Framework also supports additional APIs tocreate innovative applications.
Salient Features
RFC-compliant: RFC 3261-compliant B2BUA
Scalability: Highly scalable feature distribution
Availability: Reliable high availability support
Comprehensive support: Support for multi-party, multimedia call control
Flexible: Provides the applications complete access to SIP messages
Multiple deployment options: Single node or multi node deployment
SIP Interface to proxy/media servers
Multi operating system portability
Architectural Features
High availability APIs to allow the applications back up serialized critical data and reconstruct the state based on critical data
APIs to send SUBSCRIBE, NOTIFY, MESSAGE, and proprietary SIP messages in order to facilitate development of presence-based applications and chat applications
APIs to move call-legs from one call to another in order to facilitate development of applications, such as Call Pick-Up
In-built Load Monitor to protect against overload conditions
Event criteria filtering mechanisms
Key Standards Compliance
SIP Protocol Compliance
'SIP: Session Initiation Protocol', RFC 3261, June 2002, Rosenberg et al.
Session Description Protocol, RFC 2327
An Offer/Answer Model with the Session Description Protocol (SDP), RFC 3264, June 2002
Reliability of Provisional Responses in the Session Initiation Protocol (SIP), RFC 3262, June 2002
SIP INFO Method, RFC 2976, October 2000
Open Service Access (OSA) Compliance
3GPP TS 29.198-04-3-600 OSA API Part4-SubPart3-MPCC SCF
3GPP TS 29.198-04-3-600 OSA API Part4-SubPart4-MMCC SCF
FSS' Softswitch conforms to TIPHON distributed gateway architecture. Softswitch solution from FSS supports a wide variety of signaling protocols, like SS7, R1/R2 and ISDN and has a potential to incorporate GR-303 and V5.2. FSS Softswitch can control media remotely through MEGACO and MGCP.
Softswitch Framework Context in System
Softswitch Configuration
The design of FSS' Softswitch enables easy deployment in the network. FSS Softswitch provides the flexibility to configure all external network elements like Gatekeeper, Media Gateway, Signaling Gateway, Application Server, etc. Policies can be configured by customizing Routing, Service Control and Address Translation. Further, product related configurations for initialization, provisioning and redundancy are available through open APIs.
Softswitch Service Architecture
Services targeted – address translation, routing, IVR, Charging, Emergency, Network based, third party call handling, web based
Service Interface provides support for – CLASS services/supplementary services, IN services, SIP based
Architecture independent of signaling, but support for SIP, H.323, SS7, ISDN, R2, POTS ensured
FSS' Softswitch Framework : Functions
The FSS Softswitch is offered both as a product and a software framework with source license. FSS has already integrated the Softswitch into different product architectures and offers its services in integrating and porting the Softswitch solution onto the target.
Services
Low-level call management APIs for INAP interfaces
High-level call management APIs for Parlay adapter
SIP interface to Application server
CLASS services hosted natively
Legacy and Enhanced services supported
Softswitch Framework Functional Block
Interworking Call Control
IN CS2 – AIN 0.3 BCSM based call control
Signaling Adaptations Supporting diverse SCN and packet protocols
Enables easy integration of new signaling protocols
PSTN Interfaces
SS7 termination (ANSI or ITU-T) either through external SG or direct
Dual-seizure, reset, group blocking/unblocking supported
Supports third-party pause and re-routing
CAS R1/R2 supported on PSTN & H.323 v2 on packet network
ISDN Q.931 interface supported
Packet Interfaces
H.323 subscriber and trunk interface
SIP subscriber and SIP-T trunk interface
MGCP (RFC 2705) gateway interface
MEGACO/H.248 gateway interface
Bearer Control
H.248/MGCP based Gateway Control
Ability to manage multiple transactions
Enabling media control for packet-TDM inter-working
Ability to manage various gateway types (Access, Trunking and Residential)
Resource Management
Route Information maintained
SCN and PDN terminations and associated data maintained
Resource allocation, de-allocation and maintenance
Local and External Address Translations supported
Single point routing and distribution of messages to multiple MGs
Pdftohtml is a command-line tool that translates .pdf documents into html format. It offers several parameters, including options to create output with or without using HTML frames,ignore or include images, translate internal pdf links and more.
PDF to HTML - convert Adobe PDF document into html file with pdf to html converter
PDF2HTML (PDF to HTML) software product converts PDF files to HTML files while seeking to preserve the original page layout (as best as technically possible). PDF2HTML enables the conversion of layout originally designed for paper to be used on the Internet.
PDF2HTML (PDF to HTML) software is a standalone program and does not require Adobe Acrobat, or even Acrobat Reader.
Archisoft PDF2HTML - Pdf2html, PDF to HTML software converter
Pdf formatted documents are one of the most widely used electronic document formats on the internet and CD-ROM. Their advantage is that they can faithfully preserve the layout and appearance of the original in a ready-to-print format. They can only be searched however once the user opens them.
HTML files have the advantage of being able to be read by anyone with a web browser and can be found and searched by any major internet search engine. Use HTML to reach a wide audience.
){kind=small}
)
