1

I'm not entirely sure how to phrase my question, so I'm going to give an example.

Say you work on payment processing software. You implemented Service Oriented architecture and you have 3 main phases of an event

  1. Intake, where you get a new payment
  2. Verification, where you verify.
  3. Payment, where you settle up the accounts.

So, in this scenario you have 3 services(processor) an intake processor, a verification processor, and a payment processor.

My question is, whose job is it to pass the event from the intake processor, to the verification processor. How does the verification processor know when to get the event from the intake processor. Does the intake processor "give" the event to the verification processor, or does the verification processor look at the intake event and say hey this ones done, im taking it now?

2
  • I think having a payment service and an operation called MakePayment(PaymentInformatoin paymentInfomation) would be sufficient instead of 3 separate processors.
    – Jon Raynor
    Apr 20 '16 at 18:25
  • sure, for this example. But this was just a basic example everyone could relate to I thought Nov 19 '16 at 21:38
1

There's not a lot of information provide in the question, such as the responsibilities of the various phases, in terms of contract or artifacts/events maintained.

However, you have two choices, polling and notification.

Polling is inefficient at high frequencies, but sometimes a good option if you need/want to do things on a batch basis, say daily or weekly.

Notification sends a message from service 1 to service 2 immediately upon change. The degree of coupling between service 1 and service 2 is of interest, and can vary.

You can have service 1 know about service 2, which is relatively tight coupling, because it is not necessarily service 1's responsibility to know what service 2 needs.

You can have service 2 know about service 1, in which is requests a subscription for changes (of certain type and nature), which is looser coupling, because service 2 is downstream from service 1 and thus is already aware of some dependency.

If you use an intermediary message bus, you can decouple further as service 1 and service 2 know only about events and event types, one publishing and the other subscribing, rather than knowing about each other.

Which is the most appropriate for you depends on information not presented in the question, as is an evaluation of whether those are the right services or not.

When I'm looking at what services to have, I'm thinking about considerations such as what service is the authority of record for this or that information (or computation or decision). How are long running processes accomplished? Usually with one service responsible for the state of the long running processes, and other services interacting around changes to the long running state (doing something on state change, and then updating the state, which triggers something else to happen).

But before I even try to define services, I like to understand the business context of the ecosystem, which goes to the externally interacting roles (along with their responsibilities) of the business entities & customers involved.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.