--- In [email protected], "Ashley at Metamaxim" <[EMAIL PROTECTED]> wrote: > > Todd said > > It's also true that a single bank could provide multiple services. Typically, those services will be associated with a separate account, however. > > > For example, a home equity loan or line of credit will have a different set of operations than a checking account. > > Exactly. > > > Well put Ashley! > > Thanks. The idea of thinking about service scope in terms of dependencies is my invention. But anyone is welcome to use it, provided proper attribution is made :-) >
It's true that the issue with the banking service here is not purely about modelling, it's one of dependencies. But the dependency is not on the *provider*, it's on the account *data*, that is the shared state. I would quite happily use an "international transfer" service/operation from provider X if that provider could safely deposit the money in my account managed by provider Y. I see these kinds of dependencies on data stores as one of the major problems in implementing SOA today. Typically, enterprises delegate the storage of business transaction data to a small number of [relational] databases with legible schemas, tightly controlled by a packaged application. This packaged application may also offer a number of services/operations. There is obviously a dependency between every service that needs to access this data and the database itself. And these dependencies constrain the service consumer's choice of provider. Consider an invoicing system, let's say SAP R/3. A service for a company's suppliers called "SubmitInvoice" will typically store the invoice details in the database and kick off a series of internal processes/workflow to process the invoice and pay the supplier. To be useful, an information retrieval service called "GetInvoiceDetails" must also be able to access the data previously created by "SubmitInvoice". That is, both services are dependent on the shared SAP R/3 database. Of course you could solve this by factoring out all of the data access operations into separate services, but this is going to be incredibly difficult and expensive for most enterprises, and therefore extremely unlikely to happen. In the meantime, it will be the responsibility of the architect to identify and manage these dependencies as part of their "SOA governance" (gosh, do I hate that term!) strategy. As we move into the domain of system operations, we find another set of dependencies between services and the physical infrastructure on which they are hosted. These also constrain a service consumer's choice of [service] provider. For example, which services and service consumers are affected if I need to modify the service or replace/upgrade/shutdown a particular application server or computer system? As well as dependency issues like these, for true service substitution we need a better, more abstract naming (and name resolution) system for services. A system of URLs is too tightly coupled to physical infrastructure (through DNS names and TCP port numbers, for example) to be practical. But that's another story. I remember discussing all of these kinds of dependency issues early last year with a well-known provider of SOA registry software and governance tools. It was met with a fairly blank response. I haven't checked back recently, but I would expect that we still don't really have any good methods and tool support for managing these kinds of dependencies. It would be nice to hear otherwise, though... -Mike Glendinning. ------------------------ Yahoo! Groups Sponsor --------------------~--> Something is new at Yahoo! Groups. Check out the enhanced email design. http://us.click.yahoo.com/SISQkA/gOaOAA/yQLSAA/NhFolB/TM --------------------------------------------------------------------~-> Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/service-orientated-architecture/ <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
