Ashraf, I'm talking about styles not technology. Talking envelopes and applications isn't going to help with the business.
Sockets aren't going to help either. The point I'm making is that the STYLE of RPC is pretty neutral in that at a conceptual level you can match it to the implementation technology you want and conceptually its easy for people to handle (A calls B, C enables people to send it X) without pre-judging the implementation, Steve 2010/1/17 Ashraf Galal <[email protected]> > RPC is more technical than business, it emphasis the interface > semantic while what the business need is to understand the payload > semantic. > If we use RPC to discuss with business then we have to discuss with > getBalance(), returnBalance(), ..etc, which is more technical terms. > In the payload semantic, the business just needs to understand the > application A send a message or envelope to application B determines > what is requested. > We do not want to speak about technical operation names, we want to > speak about business services with the business. > Service is noun, operation is verb. > The abstraction is needed here. > From technical perspective, RPC is point-to-point and synchronous only, > RPC is not language independent but it allows sharing data and > functionality. > I don't think business can understand the concept of client and server > proxy. > If we want to use something with the business to speak about > connectivity, so socket will be easy for them to understand than RPC > concept or language. > > All the best > Ashraf Galal > > > > Harm Smit wrote: > > > > “*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.” > > > > I don’t buy this shortcut. Since Finance and Logistics only think in > > terms of RPC, they cannot be prepared to receive events; such a type > > of interaction is simply not part of their model of the world. > > > > Indeed, eventing interactions, such as pub/sub, cannot be covered by > > the simplistic RPC paradigm. Consequently, the idea of exclusively > > thinking in terms of RPC interactions is fundamentally flawed, both at > > the functional and at the implementation level. IMHO, the atomic > > interaction concept is that of sending and receiving messages: “the > > message is the message”. > > > > Harm. > > > > *De :* [email protected] > > [mailto:[email protected]] *De la part > > de* Gervas Douglas > > *Envoyé :* jeudi 14 janvier 2010 12:01 > > *À :* [email protected] > > *Objet :* [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* > > > > > > > > > ------------------------------------ > > Yahoo! Groups Links > > > >
