Comments on: Autonomous Services – a step beyond Service Orientation http://www.udidahan.com/2006/01/08/autonomous-services-a-step-beyond-service-orientation/ Enterprise Development Expert & SOA Specialist Sun, 14 Mar 2010 06:27:00 -0500 http://wordpress.org/?v=2.8.4 hourly 1 By: Chris Sterling http://www.udidahan.com/2006/01/08/autonomous-services-a-step-beyond-service-orientation/comment-page-1/#comment-270 Chris Sterling Mon, 16 Jan 2006 15:57:55 +0000 http://wp_630.weblogs.us/archives/245#comment-270 I am not always sure that the use of the network allows enough flexibility as when used in conjunction with client-side execution. If you look at JavaScript, it seems to never go away and I believe it is due to the basic principal of mobile code and it's perceived enhancement of the user experience. When speaking about server side code I think that mobile code must still be discussed to deal with SOA objectives. Jini is a great SOA and allows for mobility of code through JERI and the exporting smart proxies. A smart proxy may do all of the work and have no need to actually connect with a remote service. This architecture, or better yet "programming paradigm", allows for runtime configuration of your proxy communication. Therefore you can communicate via a web service using XML/SOAP/REST, Hessian/Burlap from Coucho, JERI (an RMI implementation which is much improved containing transaction and security capabilities), or your own binary protocol of choice. I believe that XML and web services along with business process management is a powerful tool but is not a silver bullet. Many organizations have internal processes which are being service-oriented using an XML strategy without noticing the binary alternative. I hope that web services and XML are used more carefully and closer to the edge in the near future or we may see another fall from grace similar to that of EJB and CORBA. I am not always sure that the use of the network allows enough flexibility as when used in conjunction with client-side execution. If you look at JavaScript, it seems to never go away and I believe it is due to the basic principal of mobile code and it’s perceived enhancement of the user experience.

When speaking about server side code I think that mobile code must still be discussed to deal with SOA objectives. Jini is a great SOA and allows for mobility of code through JERI and the exporting smart proxies. A smart proxy may do all of the work and have no need to actually connect with a remote service. This architecture, or better yet “programming paradigm”, allows for runtime configuration of your proxy communication. Therefore you can communicate via a web service using XML/SOAP/REST, Hessian/Burlap from Coucho, JERI (an RMI implementation which is much improved containing transaction and security capabilities), or your own binary protocol of choice.

I believe that XML and web services along with business process management is a powerful tool but is not a silver bullet. Many organizations have internal processes which are being service-oriented using an XML strategy without noticing the binary alternative. I hope that web services and XML are used more carefully and closer to the edge in the near future or we may see another fall from grace similar to that of EJB and CORBA.

]]> By: Arnon Rotem-Gal-Oz http://www.udidahan.com/2006/01/08/autonomous-services-a-step-beyond-service-orientation/comment-page-1/#comment-269 Arnon Rotem-Gal-Oz Wed, 11 Jan 2006 02:08:29 +0000 http://wp_630.weblogs.us/archives/245#comment-269 Hi Ralf, While I am with Udi on the notion that implementation of request/reply is not an SOA practice as it increases coupling and prevents autonomy. I still believe a service can manifest itself in a request/reply fashion as long as it is actually implemented as a request/reaction, meaning, that there is no direct synchronous handling of the incoming message (request). Furthermore I expect the request/reply behavior to be policy driven (sort of a QOS property) - based on the knowledge and testing that the reaction time for the service can be perform fast-enough to be considered as a request/reply. Still, if you write a service and you bound yourself to another service, building on its request/reply manifestation - then you have a problem with the autonomy of your service Arnon Hi Ralf,
While I am with Udi on the notion that implementation of request/reply is not an SOA practice as it increases coupling and prevents autonomy.
I still believe a service can manifest itself in a request/reply fashion as long as it is actually implemented as a request/reaction, meaning, that there is no direct synchronous handling of the incoming message (request). Furthermore I expect the request/reply behavior to be policy driven (sort of a QOS property) – based on the knowledge and testing that the reaction time for the service can be perform fast-enough to be considered as a request/reply.

Still, if you write a service and you bound yourself to another service, building on its request/reply manifestation – then you have a problem with the autonomy of your service

Arnon

]]> By: Ralf http://www.udidahan.com/2006/01/08/autonomous-services-a-step-beyond-service-orientation/comment-page-1/#comment-268 Ralf Mon, 09 Jan 2006 15:00:47 +0000 http://wp_630.weblogs.us/archives/245#comment-268 To take you up on "If you have two software entities that between them you just HAVE to have req/resp communication, then they should be in the same service.": This means, what Amazon and Google are offering, are no real services, because requesting some book information is a sync req/resp operation? Hm... As much as I would like your guideline, I think it´s somewhat limiting. Amazon´s service is pretty autonomous, but still req/resp style. Is this really wront? To take you up on “If you have two software entities that between them you just HAVE to have req/resp communication, then they should be in the same service.”: This means, what Amazon and Google are offering, are no real services, because requesting some book information is a sync req/resp operation? Hm… As much as I would like your guideline, I think it´s somewhat limiting. Amazon´s service is pretty autonomous, but still req/resp style. Is this really wront?

]]>