2010/1/14 Eric Newcomer <[email protected]> > > > 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 <[email protected] <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 > >> <[email protected]<gervas.douglas%40gmail.com> > > > >> *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< > http://service-architecture.blogspot.com/2010/01/think-in-rpc-develop-in-anything.html > > > >> > >> Gervas* > >> > >> > >> > >> > > >
