4

How can I tell if a system is built upon a service oriented architecture when reading its source code?

yannis
  • 39,597
Zain
  • 41
  • 2

3 Answers3

5

SOA is an architecture style, and so, the intend is more important than the code. Who says, the code you think is SOA-Style does not get refactored the next iteration? Generally, i would expect, it's easier just to ask the architect.

That said, ideally (i.e., when intend and source match), the following apply:

  • The Source Code of the whole Project is split into very independend units that can be deployed 'standalone', i.e, without the rest beeing deployed. These are the services.

  • Such a service would have an Interface to the external world, as a means of communication with other services. For Examle, a Date Service could answer under the url http://example.com/current_date something like {"year": 2011, "month": 8, "day": 29}.

  • Except for it's interface, a service is a 'black box' to the other services. All communication is done over these interfaces. In particular, there is no shared database.

  • When designed as SOA from the start, one would expect the same technology to be used for most of the interfaces. 'SOAP' and 'RPC over HTTP/JSON' would be examples for such technologies.

(EDIT: cleaned the answer a little)

keppla
  • 5,220
  • 24
  • 32
  • Thanks for your answer Keppla, If it possible I would go to the system architect and ask him/her directly. But what if you have 100 independent systems, and not able to contact the architects, and the only input you have is the source code of those running systems???

    Another Q: what you meant by saying: most of these Services use the same technology for their "Interfaces". What is service Interface? How to determine one?

    Thanks in advance,

     – Zain Aug 31 '11 at 09:29
  • @Zain: Sounds like you inherited a big legacy. Why is it, you want to know if it's SOA? I mean, regardless of the architect's intend, you have to deal with it anyways :). If it's your job now, and the intend of the design is not clear, do as you think, don't think of the original architect as smarter. after all: if his design would be so good, you would not ask what it is :) – keppla Aug 31 '11 at 10:02
  • @Zain: I cleaned the answer a little to fit your follow-up question. When you design Services, you would not reinvent how they communicate for each service. For example: if you have a service, that provides the date via HTTP/Json, and another that provides your Articles via HTTP/Json, you would not use XML via TCP out of the blue to provide, say, User comments. That is something i would expect to see, when you glued together some existing peices of software, that already have interfaces, but are not from the start planned as Services. – keppla Aug 31 '11 at 10:03
1

Normally, unless you are the person responsible for it you are not required to know it. You may not see anything in the "code" but rather in configuration files. If you spot configuration files on how to communicate with remote services, for example with an ESB, or as @keppla said via RPC, SOAP, then there are chances that some form of SOA-architecture is used - at least - between these two components.

But if you really want to know though, you may ask the architect, or the IT manager, they should know.

Jalayn
  • 9,807
1

If the system makes numerous calls to services which encapsulate their own logic and are defined only by their contract (parameter types and operations), then it is likely a service oriented system.

If the system doesn't make any calls to external services, then it's not a service oriented design.

Kirk Broadhurst
  • 4,209