Tiago Pascoal's WebLog

Hello Good Evening and welcome to nothing much.

SOA can a service be really autonomous II ?

Rich Turner has posted a clarification to my initial quest to understand the Autonomy tenet of SOA.

I read the post, but i still have some problems understanding it. No biggie, i guess i have a few years to catch it. :-)

Let's go piece by piece,to help me understand it.

" Taking this into consideration, and with a little further discussion, it became a little clearer that that Autonomous systems do not stand alone without interaction with other parties. An Autonomous system is self-governed and whose resources are not directly controlled by an external entity. "

No questions here. This seems like a tipical fiefdom pattern.

" The value of a Service which is entirely stand-alone would somewhat questionable and in the real world, of course, never happens. Our applications are (usually) comprised of complex interrelationships between component parts, but this IS the problem! "

This was my point. :-) If we see it as a fractal, when it comes to being autonomous a service seems to fit this description, only at a larger level but seems exactly the same. Since we are at a larger level, the level of interrelationships are a lot smaller easing it our pains,but still there nonetheless. Part of my reasoning problem, is not only at the conceptual level but also at the operational one. If we depend on another service(s) if one of those services fails, we will also fail (assuming we aren't asynchrounous). How can we be autonomous if we fail when others fail? only because we are now loosely coupled the dependency is still there.

"Most of our applications today are a rat’s nests of inextricable parts which (method call) have hard-interrelationships resulting in fragile systems that do not encourage the efficiencies of re-use that most of us seek. "

Indeed. Life is a bitch.

" If instead, our systems were architected and implemented against different principles, whereby our systems are deliberately designed to be independent and autonomous, we’re far more likely to implement flexible, resilient solutions than before. "

No question here, life would be great. And SOA will certainly help us here a little, but that still doesn't help me understand how services are autonomous. Please continue. :-)

" But what about Service A that requires information inside Service B? Won’t these two Services therefore be inextricably bound? Well, not if they’ve been carefully designed according to our SO tenets! "

Yes. Only because service A depends on B, doesn't B is less of a fiefdom, nor it affects is autonomicity but what about service A is it really autonomous? I begin to think, that is somehow related to being loosely coupled.

" Why are these services Autonomous?

·         Either Service’s location can change at (almost) any time due to the fact that they’re dynamically addressable

·         The services communicate through dynamically negotiated communications channels that support the necessary formats and capabilities (security, reliability, etc)

·         Neither Service requires knowledge of each others’ internal workings in order to exchange data – they only need the published schemas & contracts

·         Neither party make demands on each other as to how the work is carried out

"

Ah. Know i think i get it. As long as the contract remains, as long i can find it's endpoint (in case it changes) as long as it is loosely coupled, then it's autonomous. I think i now get it.

I think i now understand it at a conceptual level.....

Rich, not to impose me or anything, can i ask you another question?

If service B starts misbehaving (performing poorly) at a point that service A stability is compromised, is A still autonomous? (assuming i didn't code for failure and for example haven't triggered my code to timeout if A doesn't respond in a timely manner?).

Anyway, thanks for the reply it helped me a lot. I'm not fully convinced but i think i now understand it.

 

Posted: Mar 17 2004, 11:30 PM by tspascoal | with 7 comment(s)

Comments

TrackBack said:

# March 17, 2004 1:34 PM

Rich Turner said:

Autonomy has a great deal to do with isolation and decoupling. Let’s assume for a moment that you have a decent SO platform at your disposal and you’re building Service A that calls Service B. Service B becomes erratic - it performs slowly, intermittently fails, sometimes doesn't return a call. In this case, all you need to do is modify the Policy for Service A to say that it requires the Services it calls to support reliable messaging. Subsequently, so long as Service B DOES support reliable messaging, when the Services negotiate a connection, they do so through a buffered comms channel that implements a reliable messaging handshake for each message recieved / sent ... something like this:

Service A: [Looks up address for Service B]
Service A: Hi Service B, I would like to attach to you ... what's your policy
Service B: Hi Service A - here's my policy ... what's yours?
Service A & B: [Exchange policies]
Service A & B: [Negotiate net policy]
Service A & B: [Each construct internal comms infrastructure that supports necessary policy protocols, etc]
Service A: [Posts message to own send buffer] Here's a message for you
Service A: [Buffered send to Service B]
Service B: [Doesn't respond - crashed again - in middle of reboot!]
Service A: “Oy, Service B - here's a message for you!”
Service B: [STILL not responding! Rebuilding comms channels]
Service A: “Oyyy, Service B - here's a message for you ... AGAIN!!”
Service B: [Receives message into buffer]
Service B: Got message, thanks Service A!
Service B: [Processes message and does some work]
Service B: [Posts message to internal buffer] “Here's your reply message, Service A!”
Service A: [Recieves message into buffer]
Service A: Got message, thanks Service B!

See the point here - none of this messaging negotiation made any demands on the code in the Services. Nowhere in the code was there any interdependency between the calling and recipient Services? Nowhere did one Service delve into the innards of another. All the communications was driven by policy and the underlying infrastructure!

The services remained autonomous, but the infrastructure engaged in a meaningful dialog in order to ensure reliable delivery of the messages.

What’s more, the infrastructure made no demands on the transport in order to negotiate policy and get messages delivered. These messages could all have been delivered over HTTP, TCP, IPC, SMTP, FTP, X500 or whatever.

This is why we’re so bought into SO and why we’re building Indigo – to deliver the platform of choice for implementing truly connected systems! :D
# March 18, 2004 1:23 PM

Tiago Pascoal said:

Great. I think i now understand.

Although it seems we still have a long path to go though. :-)

Infancy is hard.
# March 19, 2004 5:35 PM

Luke Stevens said:

I wonder about autonomy being necessarily an intrinsic quality of a service. Here is a nice negative example to chew on.

Service A writes a number to C:\foo.txt, then calls Service B. Service B reads the number from the file, calculates the prime factorization, and writes the result to C:\bar.txt. Service A afterwards reads that file and does something with the result.

What's wrong here with regard to autonomy is that resources (files) are not encapsulated within the service. The practical harm is that you can't, for example, move Service B off to a remote web server. The exchange of data should occur purely in messages between Service A and Service B.

So now wrap up C: in Service C. Service A gives a number to Service C, Service B asks Service C for the number, etc. Clearly autonomy has not been improved. But if autonomy is an intrinsic quality, who is it that fails to be autonomous?

You could say that Service A is naughty because it depends on knowledge of how Service B will use Service C. Or you could say that Service B is naughty for depending on Service C even though the latter is accessible from outside the former.

My head is spinning now, so someone else will have to finish my thought, and create or point out a clearer definition of autonomy for services.
# March 20, 2004 12:01 AM

Tiago Pascoal said:

How will try to tackle it.

I would say that they are autonomous (IF...).

At first sight your service doesn't allow concurrency (at the danger of losing information when file is overwrite), but then you say : but we can make it concurrent by defining something like. Every call
has a guid (simple identifier), i dont write anything to file. I allways append it. And i append a guid and the number i want to factor. When service B replies it identifies the response with this guid. Now the service can be used concurrently, how did we did it? by adding
some kind of contract between 2 services.

What we have done seems like classic message passing using shared memory (not very elegant but it works). The file is used as the message transport.

Now suppose like Rich said,that services can negotiate the transport? and there are 2 choices
A)file message passing
B) service C message passing transport.

So when services start comunicating then define (negotiate) among themselves the transport they will use.

It seems if the assumptions can be used, then services your services are indeed autonomous.

Rich did i get it right?

A bit convoluted and not very conventional but seems to pass the autonomy test.

What do you think?

# March 20, 2004 5:18 AM

Rich Turner said:

In response to Luke's scenario:

"What's wrong here with regard to autonomy is that resources (files) are not encapsulated within the service"

This is <b>purely an implementation detail</b>. In reality, each service should own their own data and not let anyone else delve into it without passing through an explicity boundary interface method.

Luke - in your scenario, ALL your services are naughty! None should look inside or share the resources owned by each other.

If service B wants some information, then it should ask Service A to hand it over, it should NOT go and read service A's file. This is a clear example of how to write non-autonomous systems and why we end up with systems that are inextricably bound.
# March 25, 2004 7:32 PM

Rich Turner said:

Pascal, you said "What we have done seems like classic message passing using shared memory (not very elegant but it works). The file is used as the message transport."

True to a point. Alas, not quite. What you're doing here is using an internal data storage mechanism to share data between services. Remember the other tenets - "Boundaries are Explicit" and "Services share schema not class". You're doing neither here - in fact, you're completely bypassing the whole boundaries concept.

If you wanted to use shared-resource-as-transport-mechanism, you could certainly do so, BUT you MUST expose this transport in a manner that does not change the internal implementation of the system, otherwise you're not autonomous.

If you wanted to use a file to pass calls between services, you could implement code that recieves file-change notifications from Windows and then reads files dropped into a folder, unpacks the file, extracts the content, and passes that data (SOAP/XML) to a given service through an existing interface.

You should <B>NEVER</B> write some data into a file in one Service and then read that file behind the scenes from another Service. If you want autonomous systems, that's just plain asking for trouble!
# March 25, 2004 7:39 PM
Leave a Comment

(required) 

(required) 

(optional)

(required)