Design architecture to contact 3rd party Web Service -


Actually the code is structured as a first design. But I think it is not very readable

  • name space accountability
  • of each class Is it really useful for dividing between DAO and BLO? layer is such a small architecture? There is almost no logic.
  • Logic / liability of BLO is not identifiable by names of classes / methods / namespaces
  • What is UserType? Nameslot is not grouped with any other class .
  • The Config class is a good name for me because it recognizes a functionality
  • Get3rdPartyUrl and login (for that URL) everyone can be united in the same class, while InitializeConfigValue and ParseErrorMessage can be placed in some other help categories is.

Contact with a 3rdParty WS is reusable Everything should be entered with only one interface which defines logging.

The WS I contact will give callback to my infrastructure. Can I identify the session between these two calls? From my infrastructure and back to my infrastructure?

I look forward to your comments and offers!

Enter image details here

Edit

After the first refactoring, what is the result of you?

Enter image details here

I do not divide DAO and blow levels in small projects. I use all my questions in these things. You can put simple arguments (verification ef) in these questions.

The WS I contact will give callback to my infrastructure. Can I identify the session between this two calls? From my infrastructure and back into my> infrastructure?

You can use the wsa: MessageID and wsa: RelatesTo for the message correlation in the WS-addressing header and its Means MessageId and CorrelationId and wsa: ReplyTo / wsa: Address for the callback server address.

For example, the strong WS-addressing support in the Oracle SOA suite is out-of-the-box.


Comments

Post a Comment