Tut tut not putting your name on stuff ;) Steve
2010/1/15 Gervas <[email protected]> > > > Michael, some confusion here which looks like my fault. I was merely > quoting Steve's blog but failed to put the opening brackets, <<, in place. > > Gervas > > --- In > [email protected]<service-orientated-architecture%40yahoogroups.com>, > Michael Poulin <m3pou...@...> wrote: > > > > [Michael, there is a misunderstanding here which is my fault - I seem to > have forgotten to include my initial quote brackets, "<<". What I quoted > verbatim was Steve's blog. Gervas] > > > > > > > > > Gervas, > > > > let's start with that "Get Delivery Status" is not really a capability as > well as "Get Forecast", they are operations of the interface as the most. > That is, we have clearly distinguish between service capabilities and > service interface operations. This is the first 'attack' on the RPC as a > high level of 'a consistent view' - what is consistent from RPC perspective > may be inconsistent from service perspective. > > > > "When we call "Make Forecast" on the Finance Service it needs to ask the > Sales Service for its Forecast and therefore does a "Get Forecast" call on > the Sales Service. We need the Forecast to be updated daily" - from the > service consumer perspective (the only correct viewpoint for analysing > services), the Finance Service is responsible for the Forecast irrespective > to whether it gets it from the Sales Service or not. From architectural > viewpoint, > > the Finance Service has to interact with the Sales Service, and this is > not necessary to an RPC call (may be MOM-based request); this depends on the > Finance Service's Service Description. If "we need the Forecast to be > updated daily", this is another reason for NOT using RPC between the Finance > Service and the Sales Service. > > > > "Now when we start working through this at a systems level ..." > utilisation of legacy systems in Mainframes and FTP/ETL is fine but this is > not dictated by the RPC style (as you confirmed: "...but instead of making > an RPC call to get that information we have decided...". That is, RPC is > good but not really universal to become the Development Solution #1. This is > the second 'attack' on the RPC. > > > > > > Provided description of "RPC into Events" calls for messaging solution > bypassing anything related to RPC. Given event-driven scenario is typical > 'push' scenario, which operates in contra-RPC model. This is the third > 'attack' on the RPC. > > > > REST=RPC via special transport protocol, no doubts. But REST can play > only the interface role for the service. REST is technology not a separate > concept, and this concept is RPC. > > > > Finally, I totally disagree with the "Conceptual v Delivery" and, I hope, > I have demonstrated on your examples limited usability of RPC for service > design. This is why I repeat - service must be designed as service and its > implementation must respect and preserve service constraints and boundaries. > The horse pools the cart; the cart, does not matter if it is a phaeton or a > royal carriage, does not push the horse. > > > > - Michael > > > > > > > > ________________________________ > > From: Gervas Douglas <gervas.doug...@...> > > > To: > > [email protected]<service-orientated-architecture%40yahoogroups.com> > > Sent: Thu, January 14, 2010 11:01:08 AM > > Subject: [service-orientated-architecture] Steve on RPC > > > > > > Gregg Wonderly made a good comment on the Yahoo SOA list the other day > > > > I > > >think one of the still, largely unrecognized issues is that developers > > >really should be designing services as RPC interfaces, always. Then, > > >different service interface schemes, such as SOAP, HTTP (Rest et.al.), > > >Jini, etc., can be more easily become a "deployment" technology > > >introduction instead of a "foundation" technology implementation that > > >greatly limits how and under what circumstances a service can be used. > > >Programming Language/platform IDEs make it too easy to "just use" a > > >single technology, and then everything melds into a pile of > > >'technology' instead of a 'service'. > > > > The point here is that conceptually RPC is very easy for everyone to > understand and at the highest levels > > it provides a consistent view. Now before people shriek that "But > > RPC sucks" I'll go through how it will work. > > > > First off lets take a simple three service system where from an "RPC" > > perspective we have the following: > > > > The Sales Service which has capabilities for "Buy > > Product" and "Get Forecast" > > > > The Finance Service which has capabilities for "Report > > Sale" and "Make Forecast" > > > > The Logistics Service which has capabilities for "Ship > > Product" and "Get Delivery Status" > > > > There is also a customer who can "Receive Invoice" > > > > Now > > we get into the conceptual design stage and we want to start talking > > through how these various services work and we use an "RPC language" to > > start working out how things happen. > > > > RPC into Push > > When > > we call "Make Forecast" on the Finance Service it needs to ask the > > Sales Service for its Forecast and therefore does a "Get Forecast" call > > on the Sales Service. We need the Forecast to be updated daily. > > > > Now > > when we start working through this at a systems level we see that the > > mainframe solution of the Finance team is really old and creaky but it > > handles batch processing really well. Therefore given our requirement > > for a daily forecast what we do is take a nightly batch out of the CRM > > solution and Push it into the Mainframe. Conceptually we are still > > doing exactly what the RPC language says in that the data that the > > mainframe is processing has been obtained from the Sales area, but > > instead of making an RPC call to get that information we have decided > > in implementation to do it via Batch, FTP and ETL. > > > > RPC into Events > > The > > next piece that is looked at is the sales to invoice process Here the > > challenge is that historically there has been a real delay in getting > > invoices out to customers and it needs to be tightened up much more. > > Previously a batch has been sent at the end of each day to the > > logistics and finance departments and they've run their own processing. > > This has led to problems with customers being invoiced for products > > that aren't shipped and a 48 hour delay in getting invoices out. > > > > The > > solution is to run an event based system where Sales sends out an event > > on a new Sale, this is received by both Finance and the Logistics > > department . The Logistics department then Ships the Product (Ship > > Product) after which it sends a "Product Shipped" event which results > > in the Finance department sending the invoice. > > > > So while we have the conceptual view in RPC speak we have an > > implementation that is in Event Speak. > > > > RPC into REST > > The > > final piece is buying the products and getting the delivery status > > against an order. The decision was made to do this via REST on a shiny > > new website. Products are resources (of course), you add them to a > > shopping basket (by POSTing the URI of the product into the basket) > > this shopping basket then gets paid for and becomes an Order. The Order > > has a URI and you just simply GET to have the status. > > > > So conceptually its RPC but we've implemented it using REST. > > > > Conceptual v Delivery > > > > The > > point here is that we can extend this approach of thinking about things > > in RPC terms through an architecture and people can talk to each other > > in this RPC language without having to worry about the specific > > implementation approach. By thinking of simply "Services" and > > "Capabilities" and mentally placing them as "Remote" calls from one > > service to another we can construct a consistent architectural model. > > > > Once we've agreed on this model, that this is what we want to deliver, > > we are then able to design the services using the most > > appropriate technology approach. I'd contend that there really aren't any > other conceptual > > models that work consistently. A Process Model assumes steps, a Data > > Model assumes some sort of entity relationship a REST model assumes its > > all resources and an Event model assumes its all events. Translating > > between these different conceptual models is much harder than jumping > > from a conceptual RPC model that just assumes Services and Capabilities > > with the Services "containing" the capabilities. > > > > So the basic > > point is that architecture, and particularly business architecture, > > should always be RPC in flavour. Its conceptually easier to understand > > and its the easiest method to transcribe into different implementation > > approaches.>> > > > > You can read Steven's blog at: http://service- architecture. blogspot. > com/2010/ 01/think- in-rpc-develop- in-anything. html > > > > Gervas > > > > >
