Unbelievable: Tibco makes their latest product - ActiveMatrix - available for download! And some of the documentation is directly accessible. It is so much easier for independent consultants like me if vendors make such crucial information readily available.
Although both products have different backgrounds and different views, I recognize the same "distributed architecture" as in Fiorano. In particular the distributed execution with central configuration and management (most integration products are hub-and-spoke). And a strong JMS implementation underneath, TibcoEMS and FioranoMQ respectively. Obviously, Tibco ActiveMatrix focuses much more on (web) service mediation, policy enforcement and is a pretty advanced product.
But a more important player and competitor is BEA's AquaLogic Service Bus: ALSB also focuses on proxying web services, policy enforcement, service monitoring and management. But one difference between ActiveMatrix and AquaLogic is the hosting of business services: ActiveMatrix is a container for business services (even in .Net), while AquaLogic envisions services to be deployed in their WebLogic application server or 3rd party containers.
Looking forward to dive deeper into ActiveMatrix. And it is always interesting to see the architectural directions an important and independent vendor such as Tibco takes.
Tuesday, May 27, 2008
Monday, May 26, 2008
Reverse invoke / Reverse server
While browsing the latest SAP PI 7.1 documentation, I came across the latest doc of the SAP WebDispatcher. The WebDispatcher is a sort of reverse proxy that is very useful to restrict access to certain URLs of a web application server. The latest version of the WebDispatcher also supports "reverse invoke" or "reverse server".
A "reverse server" consists of 2 cooperating servers with a firewall blocking inbound connections. The server on the "inside" makes a number of connections to the server on the "outside". When the server on the outside receives a request, it forwards this request via one of these connections to the server at the "inside". The nice thing of this whole setup is that the firewall can remain closed.
"Reverse invoke" functionality is e.g. also available in WebMethods, where 2 integration servers cooperate. But is there any open source (Java) implementation that does something similar? Maybe a simple alternative is a small JMS server on the server at the "outside"?
A "reverse server" consists of 2 cooperating servers with a firewall blocking inbound connections. The server on the "inside" makes a number of connections to the server on the "outside". When the server on the outside receives a request, it forwards this request via one of these connections to the server at the "inside". The nice thing of this whole setup is that the firewall can remain closed.
"Reverse invoke" functionality is e.g. also available in WebMethods, where 2 integration servers cooperate. But is there any open source (Java) implementation that does something similar? Maybe a simple alternative is a small JMS server on the server at the "outside"?
Sunday, May 18, 2008
3 byte characters in 2 bytes?
Character encodings remain a challenge in many integration projects. Just had a customer asking: how can a 3 byte character (UTF-8) fit in a 2 byte (UTF-8) character?
Simple question I thought: (modern) programming languages and operating systems use 2 bytes to represent a single character. This gives room for 2^16 characters. Although not covering all characters, I was assuming that 2 bytes were sufficient.
Just learned that some characters in UTF-16 are encoded as 4 bytes (2 x 2 bytes). These are called surrogates. The first 2 bytes of such surrogate are in the range D800-DBFF, the last 2 bytes are in the range DC00-DFFF. As such, UTF-16 is developed to support little over a million characters.
For exchange of data in application integration scenario's, UTF-8 is recommended:
- No byte order, no need for a byte order marker
- No zero byte (making life easy for all those C-programmers
- ASCII represented unchanged
- Compact encoding of Western European characters
When diving into the Java doc of Char, the Char class is aware of surrogates (at least in 1.5). And I assume that some systems already use 4 bytes internally to represent characters, just to avoid the complexity of these surrogates (2 x 2 byte characters in UTF-16).
So another item for my totdo list: experiment a bit with conversion of text containing such surrogates from UTF-8 to UTF-16 and back. In particular in e.g. file adapters of integration solutions.
Simple question I thought: (modern) programming languages and operating systems use 2 bytes to represent a single character. This gives room for 2^16 characters. Although not covering all characters, I was assuming that 2 bytes were sufficient.
Just learned that some characters in UTF-16 are encoded as 4 bytes (2 x 2 bytes). These are called surrogates. The first 2 bytes of such surrogate are in the range D800-DBFF, the last 2 bytes are in the range DC00-DFFF. As such, UTF-16 is developed to support little over a million characters.
For exchange of data in application integration scenario's, UTF-8 is recommended:
- No byte order, no need for a byte order marker
- No zero byte (making life easy for all those C-programmers
- ASCII represented unchanged
- Compact encoding of Western European characters
When diving into the Java doc of Char, the Char class is aware of surrogates (at least in 1.5). And I assume that some systems already use 4 bytes internally to represent characters, just to avoid the complexity of these surrogates (2 x 2 byte characters in UTF-16).
So another item for my totdo list: experiment a bit with conversion of text containing such surrogates from UTF-8 to UTF-16 and back. In particular in e.g. file adapters of integration solutions.
Saturday, May 17, 2008
The future of XML - great article
Ran into a great article by Elliot Rusty Harold: "The future of XML". Good to be reminded that XML was meant for publishing. Its use for remote procedure calls and object serialization was indeed not envisioned at its design time. And very nice to get a view on the future evolution of XML.
To me personally, the lack of good XML building blocks to define messages remains an important challenge. With XML being the alphabet, now we need a language on top, or at least some consensus. Message standards such as GS1, RosettaNet or UBL don't seem to be strong enough.
Back in 2001, I gave the talk "Understanding SOAP" at XML DevCon in London. I remember being at the speakers table with Elliot. As I was only an XML beginner, I didn't do much of the talking ;-)
To me personally, the lack of good XML building blocks to define messages remains an important challenge. With XML being the alphabet, now we need a language on top, or at least some consensus. Message standards such as GS1, RosettaNet or UBL don't seem to be strong enough.
Back in 2001, I gave the talk "Understanding SOAP" at XML DevCon in London. I remember being at the speakers table with Elliot. As I was only an XML beginner, I didn't do much of the talking ;-)
Friday, May 16, 2008
Blog lift off
After more than 3 years at Apogado - company I co-founded - I decided to switch back and become an independent integration consultant and architect again. Please find below some older blog entries that I liked to keep.
Subscribe to:
Posts (Atom)