Mashed Articles

AutoScan-Network is a network discovering and managing Tool. No Special configuration is required to scan your network.

Main Features:
•Multithreaded Scan
•Automatic network discovery
•Realtime detection of any connected equipment
•Supervision of any equipment /service (router, server, firewall, smtp, http, pop)
•Automatic detection of known operatic system (brand and version)
•Intruders detection (in intruders detection mode, all new equipments blacklisted) •
•Telnet Client •
•Vnc Client

How to install autoscan-network in ubuntu / Debian
Download the package from Here
Unzip the tar.gz file in a folder
Official site here
then execute the .bin file
( installation is very simple just double click on files)

EDIINT AS2 is a very popular B2B protocol. Apart from file transfer, I think this is currently the most popular B2B protocol. Although EDIINT was initially meant to replace EDI over VAN connections by EDI over the INTernet (EDIINT), the AS2 protocol can transport any data in an asynchronous manner.

AS2 provides:

• Firewall friendly as it uses HTTP(S) underneath
• Straightforward: adds a number of HTTP header field and MIME based message structure
• Reliable: send message until you get a 200, duplicates are filtered based on message-id
• Signing: based on S/MIME message structure and PKCS7 signing (self signed certificates are often used in practice)
• Encyption: also leveraging the S/MIME message structure
• Non-repudiation: signed acknowledgement or message receipt, called the Message Disposition Notification
• Any payload: EDI, XML, binary, text
• Many implementations: free commercial versions available at low price and one or two open source implementations

As is typical in B2B scenario’s, AS2 servers are mostly located behind firewalls that only allows inbound connections from well know IP addresses.

AS2 and its family
AS2 has some family: AS1, which goes over SMTP. And a younger brother AS3 which uses FTP as its transport. And now a 4th child joins the family: AS4! AS4 uses uses ebXML messaging v3 as its transport. But what the heck is ebXML?

ebXML
ebXML was an initiative to define *the* new B2B standard for the 21st century: new transport layer, new message definitions, XML schema building blocks, process layer, protocol profiles and so on. ebXML didn’t really take off, mostly because it was considered some sort of threat to the Web Services story. A pitty that the WS-* world and ebXML world weren’t able to come together in 2001. ebXML gained a bit of popularity in some European countries like the Netherlands and Denmark, where it is used on a limited scale.

Work continued very quiet and a new version of the transport layer was released in 2007: ebXML Messaging v3. ebXML Messaging v2 and v3 are actually SOAP over HTTP(s) with some extra whistles.

Conclusion
The feature of AS4 is pulling or polling. Polling is one of the reasons why file transfer is so popular: it is “asymmetric” and allows one side to stay behind a closed firewall. ebMS 3.0 supports polling and AS4 das well. Well done! WS-Polling was a similar initiative in the WS-* world to introduce polling.

But AS4 will not become that popular in my opinion. The spec is rather “heavy” and ebMS 3.0 has very little traction. I’m not aware of any implementation. I would have preferred an extension of AS2 with support for polling, completely independent of the ebMS and WS-* specs. And so we’ll simply continue using file transfer (SFTP, FTPS) as our most popular polling mechanism.

Notes:
- Brik, thanks for pointing me to AS4
- Pictures are from a talk I gave on AS2
- Interesting link for those speaking Dutch: ebXML en ebMS: veilig en betrouwbaar berichten uitwisselen

All existing messaging solutions (WebSphereMQ, JMS, …) use proprietary protocols. This is not a problem within a single organization. But between organizations, standard protocols are needed. Therefore, the B2B world uses protocols such as AS2, RNIF (RosettaNet) or good old (S)FTP(S).

AMQP is an initiative to bring a standard binary wire protocol to the messaging world. Just like POP3+SMTP allows you to retrieve and send emails using whatever email server, AMQP will allow any AMQP client to receive and send messages via any AMQP compliant server.

But when I read the spec, AMQP is focusing on the client-server protocol, contrary to SMTP that is (also) used for communication between mail servers. The AMQP spec states that a bridge should be used for server-2-server communication, but doesn’t provide any details. As such, AMQP is focusing on messaging within the corporate firewall.

AMQP can be used for unbalanced B2B scenario’s, where one side runs the AMQP broker. This is a setup similar to one big company or intermediary running an (S)FTP(S) server and smaller organizations putting and retrieving files from it. But for good decoupling, server-to-server communication is preferred. The server at the sending side will take care of delivering the message to the server at the opposite side. Like e.g. AS2 does: once an organization has an AS2 server in place, it becomes equal to all its AS2 counterparts.

With all this in mind, I was a bit puzzled by Paul Fremantle’s enthusiasm about AMQP. In particular because he is the WS-RM spec lead.

WS-ReliableMessaging should have brought reliable async messaging to the WS-world. But it didn’t. The WS-RM spec doesn’t mention message persistence and so (most) vendors have an in-memory implementation, which is not reliable.

I still remember going through the book “Programming Indigo” and learning about the ReliableSessionEnabled binding property. What a disappointment to learn that for real reliability, one had to use the MsmqIntegration Binding and thus the proprietary MSMQ transport layer.