why service oriented architecture is hard

1. 1 Why Service Oriented Architecture is HARD June 6, 2006 Tom Dimock

2. 2

3. 3 What is SOA?

4. 4 No, really, what is SOA? A shift in focus away from �applications� towards business processes An architecture in which processes are constructed either in whole or in part by assembling reusable services

5. 5 What is it not? SOA is not SOAP, or .net, or DCOM SOA can be implemented with any of these technologies, but is fundamentally technology independent

6. 6 Managing Complexity Full-blown �applications� have become unmanageably complex Difficult to build, harder still to maintain Can SOA help?

7. 7 What is the Notification Project A common channel for notifying users Notification of tasks assigned by workflow systems Spam resistance a must Give users one �in box� which can be used by many applications Handle notification of other events of interest

8. 8 Notification Project Consists of the Notification Client, which will be implemented as a uPortal channel And the Notification Server, which will manage the notifications Intended from the start to be an open source project Initial concepts and architecture contributed by Cornell

9. 9 Notification and SOA Notification project is very service oriented Interfaces first Use external services wherever possible

10. 10 So Why is it Hard? The technology isn�t that hard, it�s the interface design that�s hard Designing an interface suitable for your current project is relatively easy Designing an interface for a reusable service is hard: It must be future-proof It must handle differing authorizations It must avoid institutional specifics

11. 11 How Do We Deal With This? Learn from existing examples Involve more people - open source Accept that you won�t get it right on the first try But having to upgrade a number of processes that all do something the same way is better than if they all do it different ways So track usage!

12. 12 Static Pluggability Frameworks such as Spring give static pluggability Configuration files specify the components to use and the �wiring� Allows decoupling of a distributed development effort Relies on dependency injection

13. 13 Dynamic Pluggability Manager class acts as factory, returning iterator over supported instances Allows multiple service implementations to be active simultaneously Allows seamless transition to new versions of services

14. 14 Kinds of Services Utility Institutional Application specific

15. 15 Utility Services Utility services provide functionality that is application independent Authentication Authorization Workflow Notification Utility services should be dynamically pluggable

16. 16 Institutional Services Institutional services expose data and functions to facilitate inter-application business processes Demographic data Account number lookup May be dynamically or statically pluggable Consider stability of the service provider

17. 17 Application Specific Services Services which are used only within a very specific application domain Are you sure? Probably statically pluggable

18. 18 Service Interface Standards Service interface standards unleash the power of dynamic pluggability Leverage code sharing amongst institutions Emerging area of interest

19. 19 OKI Open Knowledge Initiative www.okiproject.org The Open Knowledge Initiative (O.K.I) develops and promotes specifications that describe how the components of a software environment communicate with each other and with other enterprise systems. O.K.I. specifications enable sustainable interoperability and integration by defining standards for Service Oriented Architecture (SOA).

20. 20 OSIDs Open Service Interface Definitions Technology agnostic Main work product of OKI Version 2 available now, Version 3 is under development Great examples to learn from Let�s get Cornell involved!

21. 21 Questions