1 / 22

Social Enterprise Bringing Web 2.0 thinking to traditional IT

Social Enterprise Bringing Web 2.0 thinking to traditional IT. Paul Fremantle paul@wso2.com. Paul Fremantle . Co-founder, WSO2 Open source SOA middleware Chair, Apache Synapse PMC Co-Chair, OASIS WSRX TC Previously STSM at IBM Hursley Lab Lead, IBM WebServices Gateway, WSIF, etc.

kiara
Download Presentation

Social Enterprise Bringing Web 2.0 thinking to traditional IT

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Social Enterprise Bringing Web 2.0 thinking to traditional IT Paul Fremantle paul@wso2.com

  2. Paul Fremantle • Co-founder, WSO2 • Open source SOA middleware • Chair, Apache Synapse PMC • Co-Chair, OASIS WSRX TC • Previously STSM at IBM Hursley Lab • Lead, IBM WebServices Gateway, WSIF, etc

  3. What is the challenge with SOA?

  4. The “Its my baby” syndrome

  5. Trust Global benefit Cost savings Reliability Simple, uniform,least complex to do the job Not Invented Here Local benefit My budget If I run it, I know it works It must automatically grimble the fidget or I can’t use it Inhibitors to SOA success

  6. Web 2.0 • However much hype there is, the fact is that enabling users to: • publish their data and services in standard ways • manage the connections into and out of their network • control who can access what data and services • Utilize data and services from colleagues, friends or partners …. Has significant mileage

  7. SOA • However much hype there is, the fact is that enabling departments and business units to: • publish their data and services in standard ways • manage the connections into and out of their network • control who can access what data and services • Utilize data and services from other departments, business units or business partners …. Has significant mileage

  8. REST design • Everything is a Resource, identified by a URI • Everything has a Uniform Interface (PUT, POST, GET, DELETE) • The representation you get is based on Content-Type • e.g. text/xml, image/jpeg • Interactions are stateless • Links are key • “Hypermedia as the engine of application state”

  9. REST design (continued) • Ideally the “site” and the “api” are the same • Based on Accept headers each client gets the representation they like • In reality very few sites work like this • Sessions make life easy for people • But not so good for APIs • Navigational context is easy for people to figure out • No simple technical description of HATEOAS How to apply this to SOA metadata?

  10. WSO2 Registry An open source project that has tried to think about human and community issues as it tackles Enterprise SOA • http://wso2.org/projects/registry • Apache 2.0 license • Open mailing list, wiki, JIRA, etc

  11. Registry characteristics/requirements Business users feel happy to create and document ‘domains’ Developers can comment on what works and doesn’t, best practice, hints and tips Using my favourite blog reader I can subscribe to comments on my services SOA Developers can publish WSDLs and WS-Policies and search for service definitions The system shows dependencies between services, schemas and other dependent artifacts Using simple APIs, content handlers can be written to perform dependency analysis, extract useful data and validate against policies. Simple metadata properties allow the lifecycle of services to be managed. Standard APIs allow systems to publish and consume metadata without understanding complex standards Every change is versioned and I can rollback at any point to a previous revision Security controls allow me to configure exactly who can read, write, delete and manage authorization for each resource The system can be run in a highly-available load-balanced cluster

  12. Simple Atom Feed <?xml version="1.0" encoding="utf-8"?> <feed xmlns="http://www.w3.org/2005/Atom"> <title>Registry Blog</title> <link href="http://pzf.fremantle.org/registry/blog/"/> <updated>2008-02-07T15:15:02Z</updated> <author> <name>Paul Fremantle</name> </author> <id>blog-6003063374827736283.post-4039376056255567566</id> <entry> <title>Social Enterprise</title> <link href="http://pzf.fremantle.org/registry/blog/2"/> <id>blog-687987243798723.post-342798273498734</id> <updated>2008-02-07T15:15:02Z</updated> <content> <html>…</html> </content> </entry> </feed>

  13. Atom and AtomPub • Standard “feed” reading and writing capability • AtomPub (Atom Publishing Protocol) • RFC 5023 • Service (1..1) • Workspace (1..n) • Collection (1..n) • Entries / Media Entries (1..n) • Media Entries are “Anything You Want”

  14. More on AtomPub • Clear definition of behaviour of POST, GET, PUT, DELETE • For example, when you POST a resource to a collection • Specify a “Slug” header that defines the proposed name • The response 201 Created + Location header of new URI • Benefits • A well-defined protocol • With interoperability, multiple clients, tools • But also accessible with curl, wget, etc • Does exactly what we needed (almost) • Issues • There is some ambiguity about how to create a new collection • We decided to simply publish (POST) a new document which is itself an Atom Feed with the correct metadata, but no entries

  15. Lessons learnt • Even with a good headstart (Atom+AtomPub) it is hard to build a clean Human + REST application • We iterated on the design a lot • For example, • http://reg/atom/resource;comments • A collection of comments • http://reg/atom/resource;tags • The collection of tags applied to resource • http://reg/atom/tags/tag • The collection of resources tagged with tag • Searchability is key • (and difficult) • You can peruse the design here • http://wso2.org/wiki/display/registry/Registry+Protocol • We aren’t finished (by a long way!) • You can even help if you like! • We have two independent contributors so far

  16. Outcomes • Human outcomes • Because the protocol is understood by “human” systems (browsers/feed readers) anyone can subscribe to any aspect of the metadata • Everything is a resource, and by tracking dependencies between resources we can give people a good idea of their “enterprise” social network • Who relies on me? Who do I rely on? What will I break if I fiddle with this switch • Technical outcomes • Through well-defined content-specific handlers (driven from content-type) we can: • Import referenced Schemas from WSDL (and fix up links) • Validate WSDL against WS-I conformance, Validate Schemas • Through URL handlers we can define simple extensions • e.g. Lifecycle management • TESTPRE-PRODUCTIONPRODUCTIONEND_OF_LIF • The process is a new URI/Resource

  17. Human design • By defining the structure and permissions this registry is designed to operate at any scale • Local on your hard drive for personal versioned storage • Departmental or shared between colleagues • Enterprise wide • Internet scale • Running middleware systems directly from this metadata can offer the same scaling • http://mooshup.com example

  18. Another “Social Enterprise” example • http://magmasystems.blogspot.com/2008/01/cep-and-soa.html As all of the important data --- orders, risk, positions --- gets published out by the source systems and gets consumed by other applications, we need to have a global catalog that developers can browse where they can find out how to access data and what operations can be performed on the data."Where can I find real time flows of greeks for IBM, INTC, MSFT, and DELL options? The catalog service might respond:"You can get the US Equity Deriv Greek flows by subscribing to a Tibco EMS message bus. You need to subscribe to the Tibco broker at tcp://megacorpbroker:7001, using functional ID "foo" and password "baz". This service is publishing out each greek as a JMS MessageMap on the EMS topic equities.derivatives.greeks.us, and here is a list of properties that you can access in each message. Sorry, but we don't support XML.Furthermore, here are a list of request/response operations that the Greeks Web Service supports. If you want to generate the proxy code to use these operations, the URL of the WSDL for the Greeks Web Service is at http://greekserver:8042/webservice.wsdl.As an added bonus, if you send this XML string as a JMS TextMessage in the following format to this the EMS queue named equities.derivatives.greeks.services, then you will get a response on your private EMS temporary queue."This is like a super-charged UDDI, but knows about things like message buses and JMS queues and topics. For me, this is what we need out of SOA. Everyone publishing and consuming real-time flows. Everyone making services available, both as Web Services and as request/responses over a message bus.

  19. Bottom line • Middleware needs to be built with a much better concept of users • User interaction is not just for wasting time over lunch Twittering and updating Facebook… it actually has benefits for Enterprise IT • Getting those benefits while retaining the control, management and stability is the challenge

  20. Questions

More Related