Hi,

Any one could you please tell me how can we can send an object to an Java Application from wM.

Which service should be used?(Any built in service?)
If any sample code please send me the same.

And How Java application can invoke our service to get the Object from wM? Do they need to install any wM jar files?
(Any sample code pls)

Regards,
Sam

By object, do you mean Java object? If so, I’d strongly advise against doing this.

If you mean a document, like an XML document, then you can use HTTP facilities on either side. Refer to the documentation for details.

Hi Rob,

Thanks for your reply.

Any issue in sending the data as object to java application, if both JAVA application and wM application were with in same client network?

Using doc or XML it will take time since the JAVA application needs to map from our doc or XML to their variable. If we send in object(as bean) they(JAVA application) performance will be much faster, that’s why. Please provide your suggestion.

BTW, how can JAVA application can interact with wM (how can they call our service directly? apart from calling our webServices)

Regards,
Sam

If the object is streamable, you can use the usual Java facilities.

Worrying about speed this early may be premature. Do you know that this particular interaction needs to be speedy? Or that using an XML over HTTP interface won’t be fast enough? I ask because sending Java objects over the wire introduces tight coupling between your integration and the Java app.

The Java app can use the IS Java API to invoke services. Developer can be used to create the Java client code stub. Refer to the docs and the Javadoc for IS.

If the tight coupling between the two components is necessary/acceptable then these will be the facilities to use. Otherwise, I’d stick with XML over HTTP.

Side question: Why are you creating Java objects/beans in IS? Typically, integrations do not need to do so.

Hi Rob,

Actually there was an JAVA application which already present in client system. But as per client requirement they need webMethods to fetch the data from DataBase for lookup which sends the data to JAVA application. Here we are thinking the possibilities which is the best, whether,
a. Through FTP(By placing files)
b. Calling the webMethods services as webServices
c. Else calling directly (other than above a & b option)

Here if we use option b(using webServices) wM will send the data in XML format, it’s difficult for JAVA application to convert into their understandable format. So they need wM to send the data as objects(so we thought of going option ‘c’) which send the data as IData Objects. By this JAVA application will be much faster than by using option ‘b’.
Suggest me is this option ‘c’ is the best one than ‘a’ & ‘b’? else do we have any other option?

Regards,
Sam

As mentioned above: “The Java app can use the IS Java API to invoke services. Developer can be used to create the Java client code stub. Refer to the docs and the Javadoc for IS.”

Here are your options:

1. Inoke IS services via FTP or HTTP. You’d define a data structure acceptable to both sides. Could be XML, CSV, fixed-length. Note that if FTP is used, no real files are involved unless you or they do something to write the data to a file.

2. Invoke IS services using SOAP (doc/literal is preferred). You’d define the XML payload within the SOAP envelope.

3. Invoke IS services using the IS Java API. The Java application would use the supplied objects/methods to create an IData object, invoke the service, then retreive the returned data from the IData object.

These are in the order in which I’d consider the options. Speed would not be a consideration for me in any of these. Using the IS Java API would be my last choice. IMO, it is the least desirable.

Others may have other alternatives to consider.

This is probably the best option assuming the data set is not enormous.

Don’t understand this comment. The Java application doesn’t need to know XML or webMethods Java API. Whatever Web Services library you are using on the Java side will handle the serialization/de-deserialization of the XML for you. Your Java client developers will just be using what appears to java classes to them. It just becomes a getter/setter exercise for them.

“Best” is a subjective term but I’d offer that SOAP may not be the best. Generally, I try to avoid it when I can as it doesn’t add much of anything to the interaction except extra tags. There are definitely times when it is useful but for most basic integrations I think POX over HTTP is sufficient.

Yep pretty much everything in the IT space could be describe as “subjective”. There is always more than one way to skin the cat with pros and cons for all. :lol:

POX over HTTP is not my personal favorite but that doesn’t really mean anything. I prefer not interacting with XML directly other than as the underlying glue for service interfaces.

Dealing with typed data in the context of classes/objects in the native language allows me to bring in and out different providers of the data without the developer really having to being concern about the underlying data provider. They program to the interface relying on the model rather than the underlying providers view of what the data should be whether it be XML, Ralational or some other format. New providers can be injected without changing the underlying code base.

You can do the same thing with POX over HTTP assuming you inject a services layer in there but then you end up with what I was describing early which would be perfectly fine. Using SOAP generally gets you into most tools capability to auto generate and interpret your XML as native objects. Some tools can do that with POX over HTTP but support of that is hit or miss depending on the tool set.

Does that make sense in all cases? Probably not but it really doesn’t hurt anything either. It does require some extra up front work so depending on the requirements, timing etc. you may want something quick and easy.

Haven’t really seen that be an issue but that is just my experience with it. Mileage may vary with others.

“They program to the interface relying on the model rather than the underlying providers view of what the data should be whether it be XML, …”

Isn’t this another way of saying “I want to use my format (native objects), not theirs.”?

I agree that abstracting away the underlying representation can be beneficial in some cases. In most cases, the “data provider” will never change (or if it does, the model will likely change as well) so the abstraction doesn’t really help much. (Testing seems to be the biggest benefactor. Dependency injection is all the rage–but how often is it used for something other than to support unit testing?)

As you say, but I only inferred in my post, what’s best will depend on the specifics of the need. Having tools that gen Java classes and stubs from WSDL can be a definite time saver.

WRT the “extra tags” of SOAP being an issue, I agree that it isn’t much of an issue. But consider the differences in supporting SOAP vs. POX on IS. It’s a bit more involved with SOAP with arguably marginal benefit.

Yep that’s it. I was just trying to use fancy IT speak.

That is really a very good question. I’ve been having that debate with myself for a little while now. I think in a lot of cases that is probably true. And there is definitely more upfront programming to get all of that wired together correctly.

I think for larger more volatile systems you would potentially see more of a payback for the extra upfront time, although it’s not a huge amount of extra time unless you start putting in a lot of frameworks to manage it. :eek:

I’m also exploring the concept of a hybrid approach to Dependency Injection/IOC and a Service Locator Pattern for use within the webMethods IS. It’s a little much to get into here but I hope to post more about it to get thoughts on it something soon. The question for me is where to do the injection, in the message, xml config files like some of the frameworks do, or other places? Still tossing that around a bit as well as whether the whole thing is useful or not on the IS side.

Sam, what you should take out of all this is don’t do RPC calls.

Mark, this would be a great new topic I would think. I’ve been mulling over how to approach this sort of thing. There have been cases where I’d like to pass a service that has a particular interface (perhaps defined by an interface specification within Developer) to another service and have that service invoked. I’ve done using the Java API to do a doInvoke but that has a variety of issues–parameter visibility, debugging, etc.

This sort of thing has gone by various names over the years (callbacks, user exits, etc.) and it’d be cool if there would be a good way for FLOW to support something like this.