locked
Suggestion needed - Query on communication between Two Apps... RRS feed

  • Question

  •  

    Hi All,

    Looking for a suggestion on the case below:
    We have a .NET app with Oracle DB, say APP A.  Another app built on WSS and sql server,say APP B.

    These apps need to communicate as follows :
        APP A  shuld be send docs (word, xls, pdf, etc) to APP B; where as APP B shuld also be able to communicate back by sending some acknowledgemnts or statuses.


    I am also looking at the option of whether there is a way to save the file(from APP A) in some central location; and let the APP B access it from there based on some simple 'go ahead' status recieved from APP A..!!    This way we can do away with the amount of data being transferred thru the network. Again, just thought and not sure what are the implications with this approach.

    Pls lemme know of any suggestions..

    thanks..
    r m


     
    Thursday, November 13, 2008 9:19 PM

Answers

  • Yup. You can make AppB associate the key of a document in the central doc mgmt system with its workflow steps in the AppB database. Then when a specific even happens for a document or whenever you desire you can drop a message to the queue for AppA to pick up. AppA will have a component monitoring the queue and receives the message.

     

    This should work good.

     

    Also, remember that with WCF you can implement MSMQ, remoting etc using WCF service. However, having a service will always have the "delegation of responsibility" impact. We use a service when it is needed, meaning when a "service" is actually provided for someone to use i.e. outbound and not as a hack for inbound information. Hence, I recommend MSMQ.

     

    Hope this helps

     

    --Pavan

    Tuesday, November 18, 2008 7:45 PM

All replies

  • I would suggest you detach your requirements. As I understand you, you have two requirements

     

    1) Uploading documents

    2) Notifying an application that the document is uploaded.

     

    I guess your solution is pretty good. But the only problem I see in this is that multiple applications manipulating the same file system may become messy as your document store grows. So let's alter it a bit:

     

    1) What you can do is build a web service that you can use to upload a document (you have a reusable component here which can also be used by, say App C and App D). This web service can store the document to any data store, file system as you want or to a database. After upload the web service returns the path or an unique ID. 

     

    2) Now comes the part of communicating to App B. This you can do by using any messaging mechanisms like MSMQ. App A would pass the return value that it got from the web service as part of the message. App B would use this identifier to fetch the document using the same web service above.

     

    This gives you the following advantages:

    1.  You have a reusable functionality (document upload & download web service)

    2.  Your upload/download functionality implementation is decoupled from the clients. Client apps don't have to be aware of where the file is getting stored. Should you change your mind from file system to database, there would be no changes to client apps.

    3.  You are working towards a central document management system making your life lot less messier.

     

    But on the downside, you will have to take the hit of a network roundtrip. However, even if you put documents to some central location, both the apps have to do network trips to save and fetch info.

     

    Hope this helps

     

    --Pavan

     

    Thursday, November 13, 2008 10:00 PM
  •  

    Sounds good... but multiple hops might always be dangerous... say, the doc is saved in the central rep but the messaging to APP B is failed..!!  Data is falling thru the cracks..!  May be i am wrong or there is a fix for this...lemme know..

     

    Also, here is another way ->

     

    Save the doc on the App A side (APP A database, Oracle).

    Expose a websvc on App B which will be called from APP A. This is how the doc would get transferred and an ackowledgement is recieved to App A upon sucessful doc transfer..!!

     

    This basically reduces the Hops..! But, i) the doc is being saved at multiple locations..! and ii) the doc tranfer via a websvc could be a Perf hit or might bring in some implications(but this is the case even if we have the central repo for the files)...!

     

    .... any opinions/suggestions/inputs..!!

     

    thanks

    r m

    Thursday, November 13, 2008 11:19 PM
  •  rich micro wrote:

    Sounds good... but multiple hops might always be dangerous...

     

    Depends where your solution will be deployed. Intranet or Internet. Depends on what network bandwidth you have. It's always a trade-off: in this case it's between a reusable centralized solution against network hop. However, I don't understand what is meant by "dangerous".

     

     rich micro wrote:

    say, the doc is saved in the central rep but the messaging to APP B is failed..!!  Data is falling thru the cracks..!  May be i am wrong or there is a fix for this...lemme know..

     

    No data is falling through anything. The document is successfully uploaded. So first of all the message is very light. It doesn't have the document in it. So it it fails, it can be resent.

     

     rich micro wrote:

    Also, here is another way ->

    Expose a websvc on App B which will be called from APP A. This is how the doc would get transferred and an ackowledgement is recieved to App A upon sucessful doc transfer..!!

     

    This basically reduces the Hops..! But, i) the doc is being saved at multiple locations..! and ii) the doc tranfer via a websvc could be a Perf hit or might bring in some implications(but this is the case even if we have the central repo for the files)...!

     

    By introducing a service on B you are delegating the responsibility of the update completely to B. To explain further, let's say the web serv on B is down. What will A do? Will A retry sending the whole document? How many times will it retry? What will happen to the message and the doc if the service is down for all the retries? Will A monitor all the failed messages and keep resending them at specified intervals? I hope you realize what you are proposing here. You will end up building a whole messaging feature in A if you do this. And all the while the responsibility of receiving the message will completely be thrust upon B as B has to make sure that its service is up and running for receiving messages. And you will be forced to build the logic of resending messages unendingly in A. Does A require to have this functionality?

     

    If you use messaging infrastructure (like MSMQ), the responsibility is split and A doesn't have to do any additional work. A pushes a message to the queue. It's job is done. It doesn't pass any document. If B is down it will pick the messages from queue after it starts up. So it's now B's responsibility to pick up the message and pull the document and messages are not lost even if it is down. A doesnt have to worry about implementing anything additional.

     

    Your notion that doc transfer via web serv will be a perf hit doesn't seem to be correct. We do so many uploads and downloads using web service and we are always in our SLAs. So what makes you think it's always a perf hit? Do you have documents that go beyond 100s of MBs or into GBs?

     

    Hope this helps

     

    --Pavan

    Friday, November 14, 2008 8:25 PM
  • Totally agreed...!! makes sense.. but i've forgot to mention one thing....

     

    Apart from the doc tranfer from APP A to APP B;   APP B shuld be able to send the WF status of this doc to the APP A. Based on the status from APP B the editable properties of the Doc would change in APP A.

     

    Even this can be achived by just adding addl logic to make APP B feed the status to the queue and make APP A pick them.  Would that suffice..? Lemm know of any implications with this..

     

    This way we are still having the stand-alone functionality of doc upload intact.

     

     

    thanks for all the suggestions...and sorry for missing out the above part..!!

     

    awating some suggestions on this..

     

    thanks

    r m

    Tuesday, November 18, 2008 3:58 PM
  • Yup. You can make AppB associate the key of a document in the central doc mgmt system with its workflow steps in the AppB database. Then when a specific even happens for a document or whenever you desire you can drop a message to the queue for AppA to pick up. AppA will have a component monitoring the queue and receives the message.

     

    This should work good.

     

    Also, remember that with WCF you can implement MSMQ, remoting etc using WCF service. However, having a service will always have the "delegation of responsibility" impact. We use a service when it is needed, meaning when a "service" is actually provided for someone to use i.e. outbound and not as a hack for inbound information. Hence, I recommend MSMQ.

     

    Hope this helps

     

    --Pavan

    Tuesday, November 18, 2008 7:45 PM
  • it does help buddy. thank you.

     

    r m

     

    Tuesday, November 18, 2008 7:53 PM