Hi Guys. I need sugesstion about using webServie against remote invoke.

We have 2 Integration Server where Documents have to flow. I have to send Document from IS1 to IS2. TN is not available for IS2. Now we have two options.

1.) Call a service on IS2 from IS1 using Remote Invoke.

2.) Use a webService Connector on IS1 for IS2 WSDL File.

Which one of these methods is better as far as Processing power requirnment, load on IS, maintenance and Support is concerned?

I would really appriciate your help and ideas on that.

Thanks

Hi RC,
Interested to know which option did you find suitable and why?
Thanks
Shiv

please see the post I posted on advantage website

As with everything, there are tradeoffs. This keeps our jobs fun

1. Remote Invoke packed binary messages that are MUCH smaller than SOAP messages.
2. Remote Invoke still goes over HTTP, so just the same fire wall/router issues as a SOAP mesage.
3. Remote Invoke does not require input validation on the destination side (as SOAP RPC does). So if you KNOW your data will always be correct, then the called service does not have to perform input validation at all.
4. Remote Invoke ties you in to have an IS on both sides. You cannot move the destination service to another implementation without changes the calling service.
5. Remote Invoke destiniation is configured via a Remote Server Alias, so that changing where the destination service is or the account used on the destination service is not hardcoded in the Flow. This makes moving from Dev/QA/Prod nicer (This feature will be supported for Web Services Connectors in a future IS release).
6. The protocol on the wire Remote Invoke uses is the same as Developer (and any Java client using client.jar). This protocol still supports every client release since IS 2.0 and auto-switches to the best encoding supported by both sides.
7. Remote Invoke is not a “standard” and these days anything that is not a “standard” can’t be any good

I would put each Remote Invoke call in it’s own wrapper Flow, so I could change them to Web Service Connectors just by replacing those wrapper services. Also, it is a good idea to segregate all the services that call out of IS, because those have different testing environment requirements from the services that just do internal stuff, like mapping.

HTH,
Fred
Fred Thanks for your very valuable input. Keeping your commentd I think Are you favoring to use the remote invoke rather than webServices.

I would favour remote invoke, but I would isolate them into a place that I could change to a Web Service Connector if needed. Certainly, given there are Integration Servers on both sides, remote invoke would be faster and scale better unless there is a bug I don’t know about.

• With remote invoke, you can specify an alternate server in the alias which provides you with a failover capability. This can be very handy if you want to have high availability without going with reverse invoke or a loadbalancer.

• You may consider “plain” HTTP communication, which is pretty fast. For your information, Remote invoke sends at least 2 HTTP calls, one for “connect”, the other one for the query itself, and eventually another one for “disconnect”. So plain HTTP call has less overhead. Unless you want to maintain a session…

• For SOAP validation, I think there is a watt setting, which I never tried, but from its name, looks like it can disable SOAP message validation: watt.server.SOAP.validateSOAPMessage=false
  I would look to a third option of setting up territories and gateways ( and triggers)between the two IS’s. This setup would gaurantee your transaction in case of a failover as well as provide a performance balance.

Yap … I totally agree. The only thing I can think of that WebService is good is to allow communication with Non-webMethod servers. In the case of two IS, remote invoke is much better.

I actually favor Web Service over remote invokes personally. Though of course it really depends on what you’re trying to accomplish.

• Remote invoke (with guaranteed delivery) of course allow you do once-and-only-once execution. A good thing in most cases. GD is quite a bit more complicated than plain remote invoke – a compromise…

• Protocol: since remote invoke uses same protocol as Developer (WM-RPC?), access control is slightly more problematic. Not unsolvable, but requires more thought. Then again, depending on user requirements, it might not be a problem at all (i.e. intra-enterprise integration)

• Data volume: Remote invoke’s binary message is a plus, but… Since remote invoke passes the whole pipeline back and forth (by default) between the servers, a common problem for customers not proficient w/wM IS is that you’re passing a lot more junk than required. Not unusual to see junk-to-data ratio of 100’s… And remember the pipeline’s passed twice.

• Remote invoke’s input: $service – You have to type it. Need I say more?

• Input/Output parameters (1): Non-existent. IS’s Flow language uses a “black box” metaphor. This is the extreme case. You really are not sure what input/output of the called service was/is. Makes any changes to caller/callee dicey. At least WS functions much more like a regular called service.

• Input/Output parameters (2): Adding to the problem is tendency of inexperience developers to leave a lot of junks in the pipeline. That means calling someone else’s flow service by remote invoke could actually cause trouble with the calling service. But this is not a problem strictly with remote invokes – it just exacerbate it. These I/O parameters problems is why I avoid remote invokes myself.

• Session: I believe (about 90% sure) that the called service in remote invoke doesn’t have a session associated with it. There’s too much to go into, but in short it causes seemingly random errors/exceptions in the called service.

=====
To summarize: everybody bring up the advantages and disadvantages of remote invoke vs. WS, and it really is dependent on user requirement to say which is better. Both requires developers to have strict methodology for dealing with modifications in the caller/callee, and both present its own set of technical challenges. But the more information you have, the better decision you’ll make regarding which to use…

This is just an additional information with example,

Our project architecture is such a way that our (WM IS) are located inside the corporate firewall and none of the messages can not able to send/receive directly to/from outside partners. No firewalls configured to this IS. Assume this is server A.

There is another IS (WM) which exists in different network zone with all required firewalls are being configured to that IS. Assme this is server B

When an attempt to send any data to the trading partner, normally we use to call ‘remoteInvoke’ service (in ServerA) which in tern invokes the service (Server B) by passing pipeline data.

(We can see the usage of the ‘SCOPE’ flow service property which we rarely used)

Regards,
Shekhar