hello we have several internal systems that are within the same lan and want to communicate with several external systems that may be in the other buildings by using the release line.i am now considering the architecture for the project,and have got an immature blueprint,please help me to make it more perfect by give me your opinions,the scenario as:
within the lan,there are several systems that are developed by using different languages,let's suppose they are two(named internal1 and internal2),the two systems need to communicate with other two external systems(named external1 and external2) that are also developed by using different languages.all of the communications are bi-direction.there are several combinations: 1 internal1 <--> internal2 2 internal1 <--> external1 or external2 3 internal2 <--> external1 or external2 in my project,the timelimit is critical,as short as possible. according to the mentioned requirements,i decide to develop a infomation exchanging platform by using java which sit in the MIDDLE of the internal and external systems and WITHIN the lan,act as information dispatcher or coordinator,both of the internal system and external system communicate with it only.considering the multi-language and time-critical feature,i choose the way of socket communication among the systems and design a set of xml format internal protocol.otherwise,i think the message middleware are also needed within my project as message buffer.when i deepen into the detailed designing,i get some confusions,let us discuss them as followiing:
1 if is the socket the good solution for my project?how can i assign the ports?because of the introduction of the information exchanging platform into my project,the communication combination is simplified to "internal system<-->info exchange platform" and "external system<-->info exchange platform",the crucial point for the port designing is how to assign the port in the info exchange platform,that is SERVER socket port.in my designing,i plan to assign different port for each subsystem.thus,the devleopment to the info exchange platform is simplified,that is:when the message comes,i don't need to analyse the xml message to check which system it comes from.but some people suggest me to open ONE port to all the internal systems,and ANOTHER port to all the external sysetms.i don't know which solution is better?if are there some regulations that concern about the socket port assigning?
2 if is the information exchanging platform needed?some one suggest that subsystems can communicate with each other directly, the coordinating platform is not needed.but i think,from the EAI point of view,there should be a adapter between the internal system and external system.
3 where should i put the message queue server?and if is the mom needed?i plan to use the mq between the exchange platform and external systems ONLY,and it is also within the lan,in my designing,i config two queue for EACH external system,one for incoming message and other for outgoing message,to each queue,i assign a message listener to execute different operations on its "onMessage" method,that is:when the message come from internal system,the exchange platform send them to the exact OUTGOING queue according to the destination of the message,then the listener of the queue call the socket of the according external system and send the message to it.otherwise,when the external system need to send the message to internal system,it call the exact socket port in the exchange platform that is assigned to it as mentioned above,the platform accept the msg,and send them to the exact incoming queue,then the listener deal with the msg and send them to the internal destination.in this solution,i put the mq behind the socket,but someone give me another suggestion,that is i directly put the message queue between the exchange platform and the external systems instead of using the socket as the front-end,all of them send the message to the queue and listen the queue,but i think,in such solution,the external system must listen the queue REMOTELY,is it a good way?
also,somebody tell me that the exchange platform and remote external system can communicate each other DIRECTLY by socket,the message queue is not needed,i don't make sure if the mq is necessary in my situation?and what is the benefit and disadvantage?
as for the communication between the internal system and info exchange platform,i think the mq is NOT needed,they can communicate each other directly by socket,furthermore,in my designing,i make them connect to each other FOREVER,that is i don't close the socket after each message transferation,as mentioned above in the issue of the socket assigning,every port in the exchange platform is DEDICATED,that means the port is specific to each system,so that they don't need to create and close socket connection frequently,that will make the program more performant,but if i use one port to listen all the internal system,then the socket must be closed by the end of each transferation because of the block problem,that is just another reason why i use dedicated port connection to each of the internal system.
4 the another question is the secure issue accompanying by the socket,i think i needn't consider such problem in the internal connection,but to the connection between the platform and external system,the issue become preeminent,that is i must open the socket port in the firewall.but i think the connection between the lan and the external system use special line,not by internet,i wonder if the secure probem is critical in such situation?otherwise,i remember that some kinds of product from visibroker company can solve the firewall socket problem by using the http channel protocol,but i don't remember its name for sure,it seem like is called something gateway.who used such kind thing?and tell me how does it work?
This is a largish problem that would be nice to solve once for the company. Do you have middleware support or enterprise archtiecture groups? Can you make this their problem? This is in the "integration hub" space and there are plenty of good products. It would be great if somebody else would own the solution.
For a middleware plumbing only solution, we use IBM's MQ-Series. There are client libraries for many platforms and languages. We've done connectivity within the company network, outside to web application hosts and way outside to other companies. It's not often on the list of first choices for synchronous, real-time messaging, but it goes like crazy for us.
WebMethods is an integration platform tool. I read the manual but haven't actually run the tool. It looks pretty slick for all XML in and out, plus you can code in Java to do anything else you like.
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Joined: Jan 14, 2002
thanks for answer
Originally posted by Stan James: This is a largish problem that would be nice to solve once for the company. Do you have middleware support or enterprise archtiecture groups? Can you make this their problem? This is in the "integration hub" space and there are plenty of good products. It would be great if somebody else would own the solution.
i am not very clear about your meaning in the quoted part,maybe because my poor english.what means by "It would be great if somebody else would own the solution."? and "Do you have middleware support or enterprise archtiecture groups?"? i guess that the middle support should be technique support from the middleware vender,we can BUY it.what's enterprise architecture groups?we have the group of programmer,developer and system analyser.do you mean that i need another group called "enterprise architecture groups"?why?
otherwise,i hear that you have use the ibm mq in your project to integrate the several system.could you tell me more detailed about how you design you system.as you can see from my previous post,i plan use it to integrate internal system and external system,but i DON'T use it to integrate my several internal systems that are within the same lan?could you agree me?
Joined: Jan 29, 2003
Hi, sorry about making a big leap into unfamiliar terms.
Big companies often carve up responsibilities so different people take care of different parts of the infrastructure. My company has a middleware group that takes care of messaging (and more.) They are the only people who directly touch MQ-Series installation, tuning, configuration, etc. When I want to send messages over MQ-Series I talk about the number and size of messages that I'll be sending over their pipelines and they give me client libraries. They are very good with MQ and very responsive to application needs, so it's a great way to divide the work.
Enterprise architecture is another group you'll find in many large companies. They help select products that we all use and give design guidance. The original decision to use MQ-Series went through them for approvlal. Now that MQ is up and running, they keep an eye on how it is used. They look for consistency, robustness, etc.
"Integration hub" is a buzzword from a couple years ago. You'll also hear "Enterprise Application Integration" tossed around. It's all about making it easier for different systems to talk to each other. One design uses a hub - all requests go to the hub and then back out to some other system. Another concept is a ring or bus - all requests go onto the bus and around the ring until they reach a destination. These are mostly conceptual things - it's best to know as little about the real implementation as possible.
One thing we try to avoid is "point to point" communication, where you have to know all the details about the partner you want to communicate with - IP address, port, operating system, language, character set, protocols, etc. The system I work on communicates with 30-40 other systems. If we had to know all the details about every one we'd be buried in configuration.
With a hub, you only have to know how to call the hub - the hub knows how to contact the other party you need. With a message bus you only have to know an abstract name for the partner - the bus delivers the message to a physical machine and running process somewhere.
Any of that make sense? For your own situation, it would be cool if you can get corporate resources involved to make decisions that will help everyone for years to come. If you solve this problem just in your own project scope, somebody else may have to solve it again tomorrow.