De : [email protected]
[mailto:[email protected]] De la part de Steve
Jones
Envoyé : vendredi 15 janvier 2010 21:34
À : [email protected]
Objet : Re: [service-orientated-architecture] Steve on RPC
2010/1/15 Harm Smit < <mailto:[email protected]> [email protected]>
De : [email protected]
[mailto:[email protected]] De la part de Steve
Jones
Envoyé : jeudi 14 janvier 2010 21:12
À : [email protected]
Objet : Re: [service-orientated-architecture] Steve on RPC
Harm,
You are talking about technology implementation.
[HS] Nope. Im talking at the level of the model of your application,
independently of how you implement that model. Try using whatever modelling
language to express more rigorously what youre now expressing verbally and
you will see that the RPC paradigm alone doesnt fit the bill as soon as
event-driven interactions come into play. In my view, events are not just
implementation-level entities, they are an integral part of the conceptual
model.
Events are important but....
The point is that as an architect you can have the communication with the
business in an RPC language and then choose the most appropriate
implementation approach. RPC as a conceptual model effectively just says
"There are domains of control and you hand over requests to those domains"
[HS] Yes, but it doesnt allow you to say These domains of control may send
you unsolicited event notifications, be prepared to receive them at any time
and to process an event of type x within y minutes, otherwise the roof will
come down (or your boss will be fired, or a financial penalty is incurred,
etc.). BTW, I know a real-world example of this kind of situation: in case
a major failure event occurs in a car production plant, such that the entire
production line is stopped for more than 30 minutes, the car companys CEO
receives a phone call. All this is functional, not implementational, and has
obvious business level implications.
If we look at this in RPC style though that isn't really an event.
[HS] The event Im talking about is the failure that causes the production
line to be stopped. It is received by some sort of orchestrator (maybe
several of them), say a Manufacturing Execution System, which evaluates the
failure, correlates it with other failures, sends warning messages to
operators, attempts corrective action or a degraded mode of operation, etc.
After 30 minutes, if an overall error condition persists, it triggers a
phone call to the CEO.
Most events aren't purist "don't know who sent it" they are just the
smartest way to implement a "get this to X, Y, and Z".
[HS] Dont know who sent it is associated to request messages,whereas
events are of the type "dont know whom it is sent to. This is an important
characteristic that allows preserving autonomy and modularity. If the
machine that originates the failure event had to know the names of the
orchestrators that receive the event, then that machine would become
dedicated to those specific event sinks, hence would not be reusable in some
other environment in other words: would lose its autonomy. To me, autonomy
is a key attribute of SOA: a service should provide self-contained
functionality that makes sense even if used in a stand-alone manner. Hence,
a service should not know from whom it receives request messages and to whom
it sends event messages. Breaking this principle automatically results in
spaghetti structures.
So in this case what you are saying is that the manufacturing Service CALLS
the CEO Service and therefore the CEO Service has a "receive escalation
call" capability.
[HS] This isnt the point, see above. BTW, CALLing the CEO Service is a
misnomer, since no reply should be expected.
If an event doesn't have a receiver/consumer its pointless and its the act
of consumption that is the capability on the receiving service.
Lets put it this way. I've architected major manufacturing systems with
just the problem you talk about and we modeled it using an "RPC" style by
modeling the required consumption capabilities of services. This approach
clearly identified some current gaps where events were being sent but there
wasn't a clear reception process.
in other words it fits a departmental or value network view of the world.
Once you've agreed the interactions at a business level then as IT you can
choose the right implementation approach.
The business doesn't know or care about CORBA, Web Services, REST, Events,
MQ Series, FTP or any of the other plumbing approaches that IT uses and
replaces, so why surface all of that to them?
[HS] In this list, Events is a red herring. Some of the other elements in
the list support event notification (such as CORBA Notification Services,
WS-Eventing, WS-Notification), but Events is not an implementation
technology by itself.
Some people would disagree and claim that EDA (event driven architecture) is
a way to go.
[HS] EDA is about architecture, not about implementation.
Events is an implementation view that can be very easily represented using
textual descriptions in an RPC world.
[HS] We definitely disagree here. To me, events are at the same level as
requests and responses and in no way is this an implementation view, its
about design and modelling of interactions between services. As Eric
Newcomer stated it: We are modeling and designing services with various
message exchange patterns; request, response and event messages are the
constituents of these exchange patterns and the message is the primitive
element. RPC is a degenerate exchange pattern, in which a request message
and a response message are tied together in a synchronous manner.
Steve
Steve
2010/1/14 Harm Smit <[email protected]>
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 dont 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-any
thing.html
Gervas
