It seems most objections to using "RPC style" for the top level have been "RPC is a bad technology approach" -- but Steve has repeatedly said this is not about the technology used, it is about describing the top level conceptually. Alas, RPC obviously has much baggage and so its use in a different context isn't being seen.
Now if we just had a firm definition of ARCHITECTURE and how it really differs from DESIGN, we'd be set. :-) -Rob --- In [email protected], Steve Jones <jones.ste...@...> wrote: > > Michael, > > I've not yet seen a good top-down model using EDA, REST or other > implementation "styles" whereas in the last week I've seen some good RPC > "style" things which the business understood but which will not be > implemented in RPC. > > Being clear I'm not talking about the DESIGN of the services I'm talking > about the ARCHITECTURE of the services. I agree that RPC is just one > approach in Design, what I'm saying is that at the conceptual level there > are benefits from just using RPC. > > Steve > > > 2010/1/17 Michael Poulin <m3pou...@...> > > > > > > > Steve, > > > > I would agree with your statement with one small addition: > > > > "the RPC "style" as ONE OF OTHER'styles' "makes good looking models not > > that RPC as a technology is the way to go" > > > > I argue against exclusive use of RPC in the design of the services. I argue > > that top-down design of services defines and dictates the _style_ of the > > service development, not the technology used for the development. > > > > - Michael > > > > ------------------------------ > > *From:* Steve Jones <jones.ste...@...> > > *To:* [email protected] > > *Sent:* Fri, January 15, 2010 8:34:37 PM > > > > *Subject:* Re: [service-orientated-architecture] Steve on RPC > > > > > > > > > > > > 2010/1/15 Michael Poulin <m3pou...@yahoo. com <m3pou...@...>> > > > >> > >> > >> I agree with "the conceptual architecture using a single consistent style" > >> but I disagree that this style is RPC. Relationships and corresponding > >> interactions between architectural entities are the part of the > >> architecture, it is not a technology; I can send a message via MOM or via > >> FedEx, this is immaterial at the architecture level. > >> > > > > Michael so what is your consistent "style" at this level. I'm explicitly > > saying that the RPC "style" makes good looking models not that RPC as a > > technology is the way to go. > > > > Steve > > > > > >> > >> - Michael > >> > >> ------------------------------ > >> *From:* Steve Jones <jones.steveg@ gmail.com <jones.ste...@...>> > >> > >> *To:* service-orientated- architecture@ yahoogroups. > >> com<[email protected]> > >> *Sent:* Fri, January 15, 2010 10:08:07 AM > >> *Subject:* Re: [service-orientated -architecture] Steve on RPC > >> > >> > >> > >> > >> > >> 2010/1/14 Eric Newcomer <e_newco...@yahoo. com <e_newco...@...>> > >> > >>> > >>> > >>> I don't think this is correct. We are modeling and designing services > >>> with various message exchange patterns, both synchronous and asynchronous > >>> and we consider this to be consistent with SOA based designs. > >>> > >> > >> At the IMPLEMENTATION and TECHNOLOGY levels I completely 100% agree that > >> this is what we do. What I'm saying (and Gregg pointed out) is that you > >> are > >> often better off doing the conceptual architecture using a single > >> consistent > >> style (RPC) and then making the implementation (design) decision > >> afterwards. > >> The alternative is having a high-level architecture which exposes > >> technical > >> implementation styles. > >> > >> Steve > >> > >> > >>> > >>> Eric > >>> > >>> On Thu Jan 14th, 2010 5:50 PM EST Steve Jones wrote: > >>> > >>> >Fight ;-o > >>> > > >>> >2010/1/15 Michael Poulin <m3pou...@yahoo. com <m3poulin%40yahoo.com>> > >>> > > >>> >> > >>> >> > >>> >> 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 > >>> >> > >>> > > >>> >How do you work that out? > >>> > > >>> >To obtain a delivery status for an order is a core capability that an > >>> order > >>> >management service must have. To get that status it might have to query > >>> >external systems as well as doing internal work. > >>> > > >>> >A Forecast is even more of a business capability, creating a forecast > >>> >involves potentially millions of calculations and feeds from massive > >>> number > >>> >of other systems. If its a real-time forecast then the amount of work > >>> can > >>> >be stratospheric. > >>> > > >>> >A Capability is a thing that delivers the real world effect. Getting the > >>> >Delivery status or getting a forecast results in a real world effect and > >>> >undertakes a constrained piece of business functionality. > >>> > > >>> > > >>> > > >>> >> . 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. > >>> >> > >>> > > >>> >I can't really see it as an attack when you haven't explained, beyond a > >>> >statement how neither retrieving delivery status or a forecast result in > >>> a > >>> >real-world effect. > >>> > > >>> > > >>> > > >>> >> > >>> >> "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. > >>> >> > >>> > > >>> >I am NOT saying that the implementation should be RPC but that the > >>> >ARCHITECTURE is conceptually RPC. Having a consistent conceptual model > >>> and > >>> >allowing multiple implementation models is the under-pinning strength of > >>> a > >>> >business SOA approach. > >>> > > >>> > > >>> >> > >>> >> "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. > >>> >> > >>> > > >>> >Eh? I'm not saying that RPC at the conceptual level = RPC at the > >>> >implementation level. > >>> > > >>> > > >>> > > >>> >> > >>> >> > >>> >> 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. > >>> >> > >>> > > >>> >Nope, its nothing of the sort. Its proving the point that RPC as a > >>> >conceptual framework can be used and then mapped to multiple > >>> implementation > >>> >approaches. The Business folks don't need to worry about the exact > >>> >implementation approach (see Christmas SOA) but the validity of the > >>> >conceptual model. > >>> > > >>> > > >>> >> > >>> >> 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. > >>> >> > >>> > > >>> >I'm not even going there... > >>> > > >>> > > >>> >> > >>> >> 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. > >>> >> > >>> > > >>> >Nope I don't think you have. What you've demonstrated is that at the > >>> >implementation level you can use lots of approaches (which is what I've > >>> >said). Having a conceptual architecture which surfaces EDA, GDA, REST, > >>> RPC, > >>> >MOM and all the other implementation approaches to the business is just > >>> >wrong and not (IMO) SOA. > >>> > > >>> >SOA means that you have services and they have capabilities which can be > >>> >exercised > >>> >RPC means that you have interfaces and they have operations which can be > >>> >exercised > >>> > > >>> >This is why the two go well together at a *conceptual level* and you > >>> then > >>> >choose the right *implementation approach* as you move into design. > >>> > > >>> >Steve > >>> > > >>> > > >>> > > >>> > > >>> >> > >>> >> - Michael > >>> >> > >>> >> ------------ --------- --------- > >>> >> *From:* Gervas Douglas <gervas.douglas@ > >>> >> gmail.com<gervas.douglas%40gmail.com> > >>> > > >>> >> *To:* service-orientated- architecture@ yahoogroups. > >>> >> com<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<http://service- > >>> architecture. blogspot. com/2010/ 01/think- in-rpc-develop- in-anything. > >>> html<http://service-architecture.blogspot.com/2010/01/think-in-rpc-develop-in-anything.html> > >>> > > >>> >> > >>> >> Gervas* > >>> >> > >>> >> > >>> >> > >>> >> > >>> > >>> > >> > >> > > > > > > >
