Service Oriented Architectures Semantics, Processes, Agents

1. Based of Book by: (Munindar P. Singh, Michael N. Huhns) Ben Snively EEL6938 Classroom: Eng I - 388 Class Hours: Tues, Thurs 10:30 - 11:45 Service Oriented Architectures Semantics, Processes, Agents

2. Outline • Breadth over SOA Technologies • Leveraging a SOA • Agents/Multi-agents • Agent integration into a SOA

3. Service Oriented ArchitectureBreadth Overview • SOA is an Architectural Approach of Designing, Implementing, and Deploying Services. • So what’s a Service… • Services are Course Grain, Loosely Coupled, and Distributed components. • More concrete definitions to follow…

4. Services • Services must have a well defined interface. • Understand parameters/complex types to the service. • Discoverable and Stateless entities. • Find a Service that matches my need. • Shared Communication Models • Understand how to call the service.

5. Services • Producer (Service Implementation) and Consumer (Caller of the Service) interact the well-defined interfaces. • Hiding the Implementation. • Service becomes independent of • Language, Platform, and Location. Consumer Producer

6. Service Review • Services are • Course Grain • Loosely Coupled • Distributed • Well Defined Interfaces • Discoverable • Shared communication Model • Independent of Implementation • Standards Based.

7. Services – Side note • Everything should not be made a service. • Service explosion occurs • So what should be a service: • Cost of doing job by client should be much greater than the cost of calling service + service doing it. • Why send a request to do 2+2, when overhead to send the request is more than calculating result. • Re-usable components.

8. Our Sample for Today - eBay • We’ll use eBay as an example that we can all relate to. • Candidates to be a Services: • eBay Services • Bid Service – User Bid on Item • Auction Item Search – User Search • Auction Item Description – Pull Description • PayPal Services • SendPayment – Send Payment

9. Web Services • Web Services is NOT Web Pages. • “Web” since it often operates over HTTP/HTTPS • Advantage: HTTP “naturally open” for firewall ports. • Type of Service Framework • Standardized ways for • Communication (providing Shared Communication Model) • SOAP • Interface Definition (providing Well Defined Interfaces) • WSDL – Web Service Definition Language • Discovery • UDDI

10. Web Service Model Registry (UDDI) • Registers/Publisha Service (WSDL) 2. Request Service for requirement. Consumer 3. Invoke/Bind to Service (SOAP) Producer

11. WSDL – Interface Definition • XML Document that defines • Parameters to the Service • Parameters are sent in the form of ASCII XML. • Binary sent either through: • Pointers • Attachments • BinaryASCII Encoding • Methods • Location/Port of the Service

12. Invoking the Service • Since it’s XML Document sent as the Message. • Sender responsible for transforming it’s data type into XML  Called Marshalling • Receiver responsible for transforming the XML back into the data type  Called Un/Demarshalling • Allows for heterogeneous environment (Java talking to C++, C, etc..)

13. Services and Agents Often times: Distributed Services are implemented using Distributed Reactive Agents (which need to be discovered/etc..) Reactive Agent Consumer Reactive Agent SOAP SOAP Reactive Agent SOAP Sensor KB SOAP Actions Goals Strategy Actuators

14. Now What • We have all the course grain services – how do we get anything done. • Services become “Building Blocks” for doing complex tasks and processing.

15. Achieving Business Goals • Processes execute series/parallel of services/agents. • Services used by multiple processes. • Manufacturing Example: Automobiles • Companies share components between different models (i.e. Engines, Frames, etc). • Multiple “Assembly Lines” reuse these components to product different products.

16. Types of Processes • Orchestration • Central composer organizes/controls flow and calls • Choreography • Control is shared between participants, having agreement ahead of time. • Collaboration • Choreography, with ability to enter relationships, such as contracts and obligations. Participants become Business Partners. • Workflow • Human-oriented tasks

17. Process Example eBay Example: • Automatic bid/purchase of auction item • Bid X number of dollars right before end of auction  WS CALL • IF (WON) • Complete eBay Checkout  WS CALL • Send PayPal Payment  WS CALL • Send Client notification of Won Item  WS CALL • ELSE • Send Client notification that Item not won. WS CALL

18. Issues with SOA • Web Service pattern does not work – Discovery issue. • Has become development time task of selecting correct service. • Standard simply define the syntax and means to communication. • Missing semantics of the service, parameters, contracts – which are required for machine to understand service.

19. Adding Semantics • Web Service Standards • An XML Schema document gives us syntactic details. • Doesn’t identify the content represented by a document. • User Schemas allow multiple representations for the same content • Example: CustomerID and Customer_ID in two schemas may refer to the same entity. • RDF expresses the content itself, adding meaning to the elements in the document. • OWL extends RDF to add richer meaning

20. OWL – Web Ontology Language • includes • Descriptions of classes • Class properties • Relationships between classes/instances • Restrictions and Axioms • OWL is designed for use by applications that need to process the content of information instead of just presenting information to humans.* (* from Wikipedia)

21. OWL Entities and Relationships

22. OWL Inference • Information from different sources references the same object (URI) are automatically combined. • We can declare • No Person can have more than one mother • Mary is John’s mother • Jane is John’s mother • Normal data constraints cause integrity violation • OWL reasoner infers Mary = Jane (John is referenced using ID/not Name)

23. Combing SOA and OWL • Web Ontology Language – Services (OWL-S) • OWL-S • Adds Semantics to the Web Service Framework, extended it’s syntactical standards. • Allowing for service selection and understanding by Computers/Programs Page 318 • Goal: • “MAKE WEB SERVICES AMBIGIOUSLY INTERPRETABLE BY A COMPUTER/AGENT”

24. OWL-S Explained • Describes • Declarative Properties and Capabilities (for Discovery) • Declarative APIs • Declarative Descriptions • Inputs, Outputs, Preconditions, Effects • ** Used for Composition and Interoperation. • Allows systems to programmatically use services.

25. OWL-S Service Ontology Service function, applicability, quality of service, preconditions communication protocol, message formats, port numbers use of service, semantic content of requests, outcome conditions, SERVICE REALLY WHAT MATCHES NEEDS

26. Agents for Service Oriented Computing Unlike Basic Services, agents • Know about themselves, and could know about their users and their competitors • Use and reconcile ontologies or other forms of Knowledge base • Extends the simple stateless service. • Learn • Are proactive (in some cases) • Form commitments and communicate • Can be cooperative

27. Multi-Agent Systems • Tradational thought: • 1 Server  1 Solution • Examples includes Services, Processes (which could be made up from other distributed services) • Collaboration Agents/Services • Retain identity, but more explicitly interacts with other services.

28. Collaboration Agents/Services • They must • Operate Asynchronously • Allow choice between services • Engage in negotiations • Describable through declarative means • NOT PROCEDURAL. • WebSem WebSrvcAgentsMulti-Agents

29. Combining Agents with Traditional Web Services

30. Service Composition as Planning • Service composition solved implemented as an automatic planning problem: • States of the world (current and desired or goal) can be represented formally through Ontology and Knowledge structures.

31. Actions • Actions are activated through Service calls – rather than actuators. • OWL-S allows for the agent to quickly • Find Services • Make sure they semantically implement what need to get done • Which define: Inputs, Outputs, Pre-conditions, Post-conditions, and other characteristics of the service. • Actions could have reward functions/etc

32. Planning • Plan becomes a set of services that are invoked. • Called under suitable constraints of control and data flow • Agent designs could be applied depending on situation. • Could use: • MDP, POMDP, Rules-based, Case-based, BDI, etc…

33. Two Patterns for Engineering Service Applications

34. eBay Example • Deal-finder Agent • Rather than saying – bid max on price on Item X, of type Product Y. • Give me the best price on Product Y • Start learning, acting, and re-acting it’s environment – through the set of composite services. • End up getting Product Y for a customer at the best price available. • Could build similar agent to buy, sell goods, with the goals to make a profit and operate on their own. • Get Auction Items would be used in both buying and selling agents.

35. Questions? • Questions?