need help on chosing integration strategy

, , ,
1

hi,
i want to integrate a j2ee application with .net application using web methods integration server. can i use web methods broker? wat kind of adapter should i use?

2

Here’s one approach:

The J2EE and .Net apps expose web services
IS is used to interact with those web services
IS hosts mapping/translation logic to account for syntactic and semantic differences.

It is unlikely that Broker will add value to the integration, though additional information about the integration may indicate otherwise.

3

To say in simple,you dont need Broker pass thru in this scenario IS logic would be enough for web service interaction/processing as a consumer…

HTH,
RMG

4

so can i use webMethods Glue to convert the j2ee objects to webservice? is there any other option to publish a java object as webservice?

5

You don’t need Glue. All modern J2EE app servers support exposing POJO or EJB methods as web service operations. My current project is using the SpringWS open source project to expose POJOs running in Weblogic as web services, but there are literally dozens of approaches (including Glue) that will do the same thing.

If you need or want to use IntegrationServer instead of having to modify the J2EE app, you could use the EJB adapter to build Flow services and then expose those Flow services as web services.

Mark

6

Hi Renu,

If all you need to do is to exchange data between these two applications then you can use Broker APIs (JAVA and COM). In this way, you need not to expose your applications as web services. Integrate them through wm broker.

Create the publishable document types in IS (source and target) and then using JAVA Broker API, publish that source document from J2EE application. If you need any translation/mapping then create a trigger in IS and a flow service. Do the mapping from source to target document types in the flow service and publish to broker.

Using COM Broker API, make your .NET application to subscribe to the target document type. Either retrieve the documents manually from broker or automate the process and your applications are integrated now.

If there is no translation needed then only one publishable document is enough.
If you need further help, pls let me know.

Cheers:)
Guna

7

hi friends,
the info u have provided is very useful… thanks… but i have some doubts still.
1)if we are using webservices, what is the maximum size limit of records transferred thru XML?
2)does IS provide ftp services?
3)if we are using brokers as Guna has said, .NET and Java APIs for broker are incompatible. Will the idea of writing flow services help in integrating messages from these incompatible APIs ?

please correct me if my questions are incorrect…

8

Hi Renu,
What do you really mean by ‘In compatible APIs?’

Cheers:)
Guna

9

Using the Broker API wouldn’t be an approach I would recommend. I won’t get into the details here, but there are many reasons why other approaches are preferrable.

10

  1. There is no specified limit. The largest document you will be able to process will be determined by server memory, how you process the data and more.

  2. IS supports the FTP protocol.

  3. Unless you have a reason to use Broker (nothing you’ve mentioned so far indicates a need) then you can probably drop that from consideration. As an aside, the .Net and Java APIs for Broker are not “incompatible”. Those APIs are intended for their respective development environments. A message published via the .Net Broker API can be subscribed by a Java program that uses the Java Broker API and vice versa.

I recommend you use Integration Server (no Broker) and write FLOW services as needed to communicate between your two applications.