|
I'm going to step this thread all the way to the beginning
again; there was a flawed message in this thread that suggested that FDS was
only of interest for real-time data; while it's certainly true that when we're
demonstrating the power of FDS, we'll leverage real-time/collaborative examples,
let's not forget here that the FDS value proposition is much more than real-time
dashboards.
Christophe Coenraets articulated very clearly during MAX
last year, the concept of a data-oriented versus a service-oriented architecture
(I think credit is due to Matt Chotin here too); I think that is the starting
point for discussion as to whether you are going to leverage benefit from FDS in
your application architecture.
RPC services are most appropriate in an SOA
environment. You have an existing infrastructure with which you wish to
integrate, and that infrastructure presents a set of services that can be
invoked from your RIA client. That's where you'd likely make a decision to
use RPC services:
OnlineBankingService.java
+schedulePayment( payment, date
)
+openAccount( account )
+requestCurrency( fromAccount, amount, currency
)
+generatePrintableStatement( account, fromDate,
toDate )
...etc
If however, your service tier starts to look a lot
like:
PatientRecordService.java
+createRecord( patient )
+readRecord() : patient
+updateRecord( patient )
+deleteRecord( patient )
AppointmentService.java
+createAppointment( appointment
)
...etc
Then you're services are really just defining CRUD
operations on your data-tier, and it would suggest that you have a data-oriented
architecture. You're probably also having to do a great deal of
heavy-lifting on the client, to manage relationships, to manage the fact that
you have state on the client (your client model) that has to be replicated on
the server, and you will need strategies in place to manage synchronisation and
conflict resolution between these 2 models. If you then have multiple
clients that can all access patients/appointments/etc, then you're also going to
start having to think about locking/concurrency policies, and suddenly your
services have a great deal of infrastructure work associated with them.
And I haven't even started talking about clustering, and failover, and such
enterprise requirements for a mission-critical system as you
describe.
In these scenarios, where you have a data-oriented
architecture, but where there is no real-time requirements, no
push-requirements, no collaboration (per-se - screen-sharing/etc) requirements,
there is still *tremendous* value being offered by an application architecture
that leverages data services. Flex Data Services is going to do ALL that
heavy-lifting for you. Quickly. With code written by people smarter
than me (cheap shot, don't take it).
To define the problem that was originally
stated:
"Currently our thinking is to connect
to the data through web services sending XML data to a JSO file that then will
communicate with a JAVA based API back to the MySQL backend. What, if anythign
would FDS bring to the table? Still not sure how it is better than XML
based solution." When I look at that problem, I see a number of moving parts
and infrastructure work that is required - yet you are in the business of
building a large-mission critical application for healthcare. FDS is going
to remove a great deal of these moving parts, and potentially offer you an
elegant architectural solution that allows you to focus on delivering a truly
effective user-experience. You can focus on creating a useful, usable and
desirable application, and you can focus on delivering a scalable, maintainable
and performant application, you can focus on delivering feature and value to the
user (and the business) rather than focus on delivering
infrastructure.
Let FDS manage your CRUD operations for you. Let FDS
manage relationships. Let FDS manage synchronisation between your client
and server models. Let FDS manage concurrency, and locking and conflict
resolution. Let FDS manage how all that jazz works in a clustered app
server environment. Let FDS make your integration to your MySQL database a
walk in the park.
I'd seriously recommend that you (the general you here)
spend some time understanding in it's entierity, the value proposition that
we're making with Flex Data Services; there is a great deal of misconception
that FDS is a solution for real-time, for push, and for collaboration
only.
Not so. When you are building enterprise n-tier RIA
(buzzword bingo - Webster wins) that have a significant reliance upon EIS such
as database integration or message-queue integration, FDS is going to give you
bet-the-business assurance on your technical robustness, and let you focus on
delivering the kind of user-experiences that no-doubt were the reason Flex
caught your attention in the first place.
Do you think we need to do more work in helping you
understand the ways in which you can deliver better apps smarter and faster with
FDS ? Let us know what would help you here - because FDS is helping
us.
In the meantime, let a take-away from this simply be that
FDS is about more than "real-time-update-in-front-of-your-eyes-charts".
Those are just the demos we build in a few minutes at conferences to show you
how all the bits hang together.
Does this offer any pause for thought ?
Best wishes,
Steven
-- Flexcoders Mailing List FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt Search Archives: http://www.mail-archive.com/flexcoders%40yahoogroups.com
SPONSORED LINKS
YAHOO! GROUPS LINKS
|
- RE: [flexcoders] Re: FDS question Steven Webster
- Re: [flexcoders] Re: FDS question Jeremy Lu
- Re: [flexcoders] Re: FDS question Rob Rusher
- Re: [flexcoders] Re: FDS question Tom Chiverton
- [flexcoders] Re: FDS question shottonmark
- RE: [flexcoders] Re: FDS question David Mendels
