-
Notifications
You must be signed in to change notification settings - Fork 2
My CORBA & middleware blog
I'm glad to announce that 6.5.X and upper versions of TIDorb (both Java and C++ ORB) are just now able to use IPv6 protocol [1].
Not only now TIDorb is able to use IPv6 sockets, moreover is able to use corbalocs which contains network address in IPv6 format and generate IORs with network address in IPv6 format.
IPv6 is now ready to replace IPv4, enabling point to point communications across Internet, as the original design of the network.
Examples of corbaloc for IPv6
corbaloc:iiop:1.2@[fe80::218:8bff:fee5:6f91]:2809/NameService
Some new ORB parameters have been added to TIDorb ORB:
-ORB_prefer_ipv6 / es.tid.TIDorbj.iiop.ipv6
(Enable use of ipv6 by default / false)
-ORB_iface / es.tid.TIDorbj.iiop.iface
(Default network interface /eth0)
TIDorbJ 6.5 is available to download in github.com
[1] IPv6 in Wikipedia https://secure.wikimedia.org/wikipedia/en/wiki/IPv6
Both Java and C++ versions of TIDorb have been ported to Android platform, using Google Android SDK and NDK.
CORBA is a very efficient protocol which can be used to communicate an Android mobile device with a back-end server. For example, with TIDorb for Android you can use a protocol such as SSLIOP as a easy way to securize communications between an device application and an Internet server.
6.4 versions of TIDorb for Android platform can be downloaded from github links: java and cpp
Sometimes the movies show us how a hacker breaks a high security network and gets access to a data base. Then our intrepid hacker retrieves some relevant information related with the plot of the movie. But in spite of the fact that in cinema all is possible, this is not so easy; but this is not impossible at all.
In the extreme of the paranoia, since a laptop provided with a wireless card could be connected to our LAN, our LAN is potentially under risk to be attacked by an external source, specially if the laptop was compromised before.
Returning to our field, middleware technologies, lets take a look to the following scenario. Considering the next CORBA IDL:
// IDL
interface CreditCard {
bool pay(string card_user, string card_ping,
long amount, string change_account);
}
Lets think that a client (the source[] of the communication) makes a call to a remote server (the target[] of the communication) using the following personal information:
card_user: 12341234123
card_ping: 1234
charge_account: 20382342342
The source code needed to invoke "pay" method of "CreditCard" interface could be:
// C++ client invocation
test_ref2->pay("12341234123", "1234", 300, "20382342342")This call could be intercepted across the network (WAN or LAN) where the source and the target are connected
The next capture could be taken with a sniffer tool like wireshark[] or tcpdump[]
47 49 4f 50 01 02 01 00 78 00 00 00 05 00 00 00 GIOP....x.......
03 00 00 00 00 00 00 00 24 00 00 00 01 00 00 00 ........$.......
00 00 00 00 c5 9e 91 e4 24 01 00 00 10 00 00 00 ........$.......
00 00 01 24 e4 91 9e c5 00 00 00 00 00 00 00 01 ...$............
04 00 00 00 70 61 79 00 00 00 00 00 00 00 00 00 ....pay.........
0c 00 00 00 31 32 33 34 31 32 33 34 31 32 33 00 ....12341234123.
05 00 00 00 31 32 33 34 00 00 00 00 2c 01 00 00 ....1234....,...
0c 00 00 00 32 30 33 38 32 33 34 32 33 34 32 00 ....20382342342.
00 00 00 00 ....
As a result one part of the information which composes the CORBA request is send in plain text and could be easily read by a potential attacker.
Firstly, a potential attacker has obtained a very useful information without having our consent.
Secondly, a potential attacker could reply to this message composing a response which could be accepted by the source without suspicion.
So, the previous scenario focuses on the two main risks in network communication through middleware:
- Deep packet inspection
- Man in the middle attacks
With the aim to avoid these kinds of attacks, the CORBA Security Service and the Secure Interoperability chapter of CORBA core specification define some mechanisms to provide security in some basic aspects like:
Authentication
Confidentiality
Integrity
Delegation
Non-repudiation
Access control
Auditing
Authentication, Integrity and Confidentiality are commonly adopted by the software industry, and recently have been implemented in the latest version of TIDorb. Concretely have been implemented: SSLIOP protocol (SSL over IIOP), CSIv2 support, GSSUP User/Password authentication protocol and SAS management.
These new security mechanisms could be used easily by a CORBA Service, like TIDNaming[] and TIDNotif[].
However there is not a standard specification about how provide these security requirements using MIOP protocol, specially authentication in a multicast communication. So there is work to be done in this middleware security area.
Sometimes the addition of two ways for resolve different problems generates another solution for another kind of problem. Think about these relatively new CORBA technologies: ZIOP [1] and MIOP [2]. Basically, ZIOP enables compression at message level and MIOP enables distribution of CORBA Messages in a multicast network. MIOP runs in the top of UDP protocol, which is not reliable. But in spite of large packets can be send through a multicast network (as can do MIOP protocol), the best way to reduce disadvantages of multicast network (packet loss) is to reduce the size of the packets sent.
Let's have a look at the following example, which implements a publisher-subscriber scheme:
// IDL
interface Consumer {
oneway void receiveData(in Package data);
};
The publisher invokes a consumer method named "receiveData" which receives a "Package" structure.
In this example "Consumer" entity will work as a CORBA server. It will create a POA where it will register the implementation of the consumer servant. Some ZIOP policies related with ZIOP Consumer capabilities (as kind of compressors supported) will be register in that POA, named GOA.
policies[0] = orb->create_policy(ZIOP::COMPRESSION_ENABLING_POLICY_ID,
compression_enabling_any);
policies[1] = orb->create_policy(ZIOP::COMPRESSOR_ID_LEVEL_LIST_POLICY_ID,
compressor_id_any);
my_compress_poa = root_poa->create_POA("My_Compress_Poa", NULL, policies);
PortableGroup::GOA_var my_compress_goa =
PortableGroup::GOA::_narrow (my_compress_poa.in());
CORBA::Object_var group =
orb->string_to_object ("corbaloc:miop:[email protected]/224.168.0.1:15984")
ConsumerImpl consumer_impl;
PortableServer::ObjectId_var id = my_compress_goa->create_id_for_reference(group.in());
my_compress_goa->activate_object_with_id (id.in(), &consumer_impl);In the other side, Publisher will work as the CORBA client. From a MIOP corbaloc it will obtain a remote object reference to the consumer, which will be used to invoke Consumer methods. In order to enable ZIOP capabilities, some ZIOP policies (as kind of compressors supported, compression limits, etc) will be established in the object reference.
policies[0] = orb->create_policy(ZIOP::COMPRESSION_ENABLING_POLICY_ID,
compression_enabling_any);
policies[1] = orb->create_policy(ZIOP::COMPRESSOR_ID_LEVEL_LIST_POLICY_ID,
compressor_id_any);
policies[2] = orb->create_policy(ZIOP::COMPRESSION_LOW_VALUE_POLICY_ID,
low_value_any);
policies[3] = orb->create_policy(ZIOP::COMPRESSION_MIN_RATIO_POLICY_ID,
min_ratio_any);
CORBA::Object_var obj =
orb->string_to_object("corbaloc:miop:[email protected]/224.168.0.1:15984");
obj2 = obj->_set_policy_overrides(policies, CORBA::ADD_OVERRIDE);
Test::Consumer_var consumer =
Test::Consumer::_unchecked_narrow(obj2.in ());
Test::Package pkg;
consumer->receiveData(pkg); Some UDP packages are sent from publisher to consumer:
4d 49 4f 50 10 03 96 0a 00 00 00 00 01 00 00 00 MIOP............
0c 00 00 00 0e 04 00 00 00 00 00 00 00 00 00 00 ................
5a 49 4f 50 01 02 01 00 8a 0a 00 00 04 00 00 00 ZIOP............
3c 10 00 00 78 da 45 97 39 8e 74 49 15 85 ab a1 <...x.E.9.tI....
1d 30 00 83 25 80 f0 50 77 3b 78 38 b4 84 10 06 .0..%..Pw;x8....
88 1d fc 31 cf e3 8d 39 62 2f 38 ec 85 7d b0 08 ...1...9b/8..}..
5c 6e b5 40 64 e9 e9 65 e5 53 46 46 dc e1 3b e7 \[email protected]..;.
fe f1 4f 7f f9 eb 57 3f fa ea e3 9b 5f 7c 7c fc ..O...W?...._||.
ec eb 8f 1f 5e 5f e1 f5 63 bc be ff 7c 8f ff fc ....^_..c...|...
14 ef df 7e f7 bb df 7e 83 7f df 7e a4 df 7f 3e ...~...~...~...>
ff 0d 5e bf fa ef f3 9f e0 fd 0f 31 d4 e6 79 f9 ..^........1..y.
f8 f8 ff 1a ff 7b fd 12 af c2 29 d7 9d ff 8d 3b .....{....)....;
fd 85 38 fe fd 17 f8 f2 c3 b3 6f bf fb f8 f8 27 ..8.......o....'
de 7f fd b9 e6 bf ff f5 67 fd 8f af 3f fe fe f3 ........g...?...
8f 8f 6e bb 3c 0d 74 62 7a 37 c6 5d 29 60 86 b1 ..n.<.tbz7.])`..
The complete source code of this example, aka "ZIOP over MIOP test", can be downloaded here from github
It needs run with TIDorb C++ version 6.4.3 or upper and you make sure that size of MIOP packet must be always greater than ZIOP message size. This kind of technology can be very usefully, in example, for a source which gets large data from a radar device and must send it to a remote server.
[1] http://www.omg.org/spec/ZIOP/1.0 [2] http://www.omg.org/cgi-bin/doc?ptc/03-01-11.pdf
Telefónica I+D has contributed with Wireshark community developing two new dissectors for both CORBA protocols: ZIOP and MIOP.
Wireshark is the world's foremost and award-winning network protocol analyzed. Wireshark is a free software project developed by an international team of experts and broadly used by many industries and educational institutions.
MIOP (Unreliable Multicast Inter-ORB Protocol), as describes OMG specification [1], provides a common way to deliver GIOP request and fragment messages via multicast over UDP/IP. MIOP is implemented by some ORBs like TAO, TIDorb, JacORB, etc.
ZIOP (Zipped Inter-ORB Protocol) is a new protocol which compresses GIOP Messages. Currently is a "OMG recommended for adoption" specification[2], that is, is under standardization by the hand of RemedyIT (TAO), TID (TIDorb) and IONA (Orbix).
Both dissector protocols are based and uses the previous GIOP dissector, which was developed by Frank Singleton.
ZIOP and MIOP dissectors were committed to Wireshark subversion trunk at revision 27589, accessible at http://anonsvn.wireshark.org/wireshark/trunk
More details, screenshots and examples could be also find at Wireshark Wiki http://wiki.wireshark.org/CORBA
that currently are in the Wireshark distribution (SVN trunk) and was developed by Frank Singleton.
Nevertheless it has need to make some minor changes in this current giop dissector to allow MIOP and ZIOP dissectors uses it for dissect the CORBA GIOP messages which are encapsulated by these protocols. These changes are transparent to the current behavior of the giop dissector.
[1] http://www.omg.org/cgi-bin/apps/doc?ptc/03-01-11.pdf [2] http://www.omg.org/cgi-bin/apps/doc?ptc/09-01-03.pdf
Usually in distributed applications it is necessary to put under control some variables such as execution time.
Time requirements are strongly related with application data in some way: the value or data utility is related or depends on the time in which data was processed or created.
In distributed applications which follows a RPC (remote procedure call) scheme application data are transmitted to remote nodes into requests and replies.
Some of these time requirements can be: time to start a remote send, time to start a application delivery, time to wait for a response until raise a application timeout. These kind of constraints are commonly known as Quality of Service (QoS) requirements.
In order to allow coordination between the several nodes of the system they must use a correct and coordinated clock time, represented generally in UTC (Universal Time Coordinate) format.
CORBA Messaging chapter introduced QoS policies with the aim to provide a way to control some of the issues, specially timing policies.
CORBA QoS messaging policies can applied in server side or in client side. In server side the policies are incorporated to a POA at the creation stage. In client side, policies could be incorporated in one of the following ways:
- Using PolicyManager (ORB level) through set_policy_overrides PolicyManager operation
- Directly to reference (object level) through _set_policy_overrides Object operation
- Via Current object (thread level) through set_policy_overrides Current object operation
In this sense, RequestStartTimePolicy and RequestEndTimePolicy controls respectively when a CORBA Request must be sent to server and must be delivered to the application. If the time is overdue, then the request is not sent or delivered to nobody. ReplyStartTimePolicy and ReplyEndTimePolicy has the same behavior but are applied to the CORBA replies.
For example an application could need to send events but it wants that remote application only would process the latest events generated. To perform this, a C++ client can do:
CORBA::Any request_end_time_any;
request_end_time_any <<= (TimeBase::UtcT) get_end_time_in_utc();
my_policy_list[0] = orb->create_policy(Messaging::REQUEST_END_TIME_POLICY_TYPE,
request_end_time_any);
object_reference->_set_policy_overrides(my_policy_list, CORBA::ADD_OVERRIDE);There are other QoS timing policies aimed to control the time to wait for a response such as RelativeRequestTimeoutPolicy and RelativeRoundTripTimeoutPolicy, relevant in client side. These policies establishes how time a client must wait for a response until notify application level that request is performed.
One of the improvements added in CORBA Notification Service respect CORBA Event Service was the QoS properties. These properties could be defined per channel, per consumer and supplier entities (proxys and admins) through set_qos operation, as well as in header of structured events at variable header field. Basically, Notification QoS Properties (such as StartTime, StopTime, StartTimeSupported, StopTimeSupported and Timeout) allow to define when an event must be sent, processed or discarded depending on the time when was generated.
The QoS management of CORBA Notification Service is similar in power to QoS of Data Distribution Service (DDS) and Advanced Messaging Queuing Protocol (AMQP).
Sometimes in distributed systems is necessary separate the way to deliver messages between two peers, specially in applications where a huge number of messages are interchanged between remote nodes and/or the time of processing these messages by server is considerable. In these cases the client can not wait to get a response from server in order to send it another message. In other cases originator does not know who is going to be the message addressee.
CORBA defines some approaches to perform this explicitly, like AMI and Event Service, and implicitly through combining one-way calls to local objects and two-way calls.
The AMI is a way to allow callback mechanisms between clients and servers. Basically the client side must provide a handler to manage the response of the invocation which is going to managed following AMI. Firstly the IDL file must be compiled to generate special stubs for the handlers. Secondly, the user must provide a implementation of the handler, which basically will be a servant object provided by the client side. The handler will attend the callbacks from server side. During execution, the client will invoke to "send_cMETHOD" call in AMI mode instead traditional twoway "METHOD" call. The response will be obtained in the handler by the corresponding "METHOD" handler operation. If there is an exception "METHOD_excep" handler operation will be invoked.
Typically client side ORB attends callbacks for handlers using a thread pool. From the point of view of server developer there is not changes to introduce. The ORB at server side will detect automatically that the response must be send to the provided handler.
TIDorbJ [1] ORB and TIDIdlc [2] IDL compiler are full compatible with CORBA specification about AMI callbacks, and here is an example.
Event service is another way to decouple client a server message delivering, but it is more sophisticated. The complexity of CORBA Event Service lies in deploytment of some objects like proxies and admins. CORBA Event Service allows decoupling client and server roles introducing a Channel where events messages are send by the publisher and obtained by subscriber. Client works as the publisher of messages and Server as subscriber of these messages. In both cases client and server must implement some IDL interfaces. In this publish/subscribe paradigm there is not communication directly between publisher and subscriber because all communications are performed through the event channel. Moreover there is not a way to notify a response from the server side to the client, since client does not know if there are any server listen at the channel and vice-versa. TIDNotifJ [3] implements CORBA Event Service, as well as CORBA Notification Service.
The oneway call is the most simple way to provide decoupling between client and server when client invokes remote method of the server. The main constraint is that server can not return a request response to the client.
A client performs local oneway invocations to a local object whose servant invokes a remote object through a twoway call with another node. This trick is specially useful using ORB ThreadPool model and sending weight message requests. In this approach the local servant at client side can catch remote errors and exceptions while client message originator can work (creating more requests) without take care about these issues.