Building Service-Oriented Architectures with Java and Web ...

  • 476 views
Uploaded on

 

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
476
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
12
Comments
0
Likes
1

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide
  • This is an example of where IT integration was before service oriented architecture. IT has gone through successive generations of integration strategy for the last 30 years starting from extract, transform and load with tapes up to the current generation of EAI. Which usually involves a MOM infrastructure with asynchronous message exchange. Installing one of these infrastructure that allows you to connect systems together. Mostly for shipping data. If you talked to an IT person today who is integrating applications, he typically has stovepipe applications that he's trying to keep to some level of consistency. He's got data flowing into them all and is trying to shuffle this data around through data pipes. Data pipes are typically point to point things that are created. They are typically called an “integration”. You go to do an integration with WebMethods, first you have to suck the data out of something. So you use some sort of adapter that they provide, which uses whatever proprietary mechanism is required to get the data out of the source system. You bring it into the infrastructure where you typically do some data conversion and then send it to the other system through another adapter. Typically don't canonicalize the data. The deployment ends up being a multi-tiered system with an integration server in the middle. Even the integration server might be multi-tiered. Get data on one tier, pump it into a MOM system, convert in another tier, and then pump it out the other side. Term “ESB”, sort of a cheaper or lower end integration server solution. WebMethods can cost several million bucks whereas some of the ESB are less expensive. The result is that you have all of these point-to-point data pipes where you're moving data around your IT infrastructure to keep things in sync. Sometimes logic in the data pipes to do some translation and maybe a bit of orchestration, but not much. Then came along app servers where you can deploy more logic. Typically trying to composite data from several places. Again, specialized connectors are used to get at the data. e.g. JDBC driver for Oracle or SAP connector for SAP. In all of these forms of integration, you rely on specialized libraries to achieve the actual integration. You're not doing it through any standard service delivery mechanism. Spend a huge amount of time just getting one set of plumbing to talk to another set of plumbing. This is where the IT industry was until we got to SOA.
  • With Service Oriented Architecture, the model has changed. The assumption is that there is no shared infrastructure or no specialized protocols connecting the systems together. Only the Internet exists between them. Whether connecting them to ship data between them or to provide a composite function. Look at the boundaries of this picture. First, the Internet: What functionality is in the Internet? What is it that Web Services today rely on? TCP/IP, HTTP, proxies, reverse proxies, firewalls and infrastructure. There's a fair amount of communications and integration functions available there. What does the boundary look like between S1 and the SOA Infrastructure and the SOA Infrastructure and the Internet? Around S1: If you look at the various platform facilities people are providing, it's a number of different things. If you look at JAX-RPC, you see a particular set of Java APIs which you use in combination with XML APIs. If you look at BPEL as a technology, it has a way of producing and consuming XML messages within its own infrastructure. But there's this basic assumption that there is some business logic and that business logic is producing and consuming messages thru some message exchange patterns. It's not really discussed a lot in the industry, but there's an assumption that if you're developing code in this S1 system or wrapping some existing code that doesn't know about the Internet, the boundary between whatever function you're adding and the infrastructure you're using has to do with you constructing messages typically XML messages potentially with attachments and that you're shipping them through message exchange patterns. Which is a big word for some simple primitives for producing and consuming messages. In WSDL 2.0 there are 8 primitives whereas in WSDL 1.1 there are about 4 of them described. They provide some basic ways in which you directly interact with another system. In the SOA infrastructure, you're trying to take that application abstraction, which is focused on the content of the messages and the sequence of those interchanges, and you're trying to add support to get them out on the Internet. Some people talk about this... there's protocol, policy, security, in this infrastructure. There's a number of things the developer would not want to deal with at least from an implementation standpoint. Look at web sites, you have web site developers and you have web servers. Web Server fills the infrastructure gap to get the function of the web site out on the internet. In fact, there's a lot of function in a web server. If you look at a web app in J2ee, there's a lot that's not there when you get ready to put it on the Net. You need a web container and either a web or app server to present it to the net. If you're using BPEL, you need a BPEL engine – more SOA infrastructure. When people talk about policy and policy support, there's an implication that it's declarative that the app developer describes and then gets supported by the infrastructure. We think of policy more around security policy. At the protocol level, there are policies about what you need to to do secure the information on the wire for privacy and integrity, but there's also policy at the application level, where it's independent of the protocol There's authorization policy, which has nothing to do with the protocol. If you look at Sarbanes-Oxeye and you are trying to see who has seen what information when, you've got to look at privacy at not just a protocol level, but at an application level as well. A lot of confusion about over focusing policy at the protocol level and ignoring policy at the application level. In this picture, we're trying to give you a feeling that the middleware is still in this picture. Web Services and SOA don't get away from need for middleware. Middleware is different in SOA in that it does not extend from one service or system to another. It's not one big shared library. It's not even like the PDF reader situation. These systems don't share code. They never want to share their code from a security perspective. They need to expose their function. They need to have a logical boundary between themselves and their infrastructure which can be platform or integration technology specific. And the boundary between the infrastructure and the Internet must be extremely well defined or you can't get these systems to talk to each other. The core point about SOA is that you're not sharing libraries, but you are actually sharing exposing a service using Web computing standards primarily for shipping data around and creating conversations. The concept is that the IT organization is now starting to bet on Web computing just like they bet on web computing for web sites. Extending their dependence on web computing as the next generation of their integration architecture. The problem is this takes some work, that when people first started saying why don't we use web sites for a travel tool. Seems like a no brainer today, but it took a lot of work, but you had to get browsers out all over the place and web infrastructure deployed. The CIO looks at this and says “We already spent 3M on WebMethods, why do we need to spend money on this other model?”. There will be a tension there for a long time to come. To put a SOA model in place, you have to build up this infrastructure, you have to think about canonicalizing your information because you're not trying to connect SAP to PSFT. You're trying to offer a service that, just like with a web site, you don't know who's going to use a web site. The power is that it's a generic capability that is broadly accessible and broadly composable, but you have to have a business case to put it there. The thing that pushes the IT organization over the bar, by aligning their architecture with the Internet, they begin to get a payoff, that they don't have to use this proprietary middleware. Begin to connect these systems in a more open ended, more composable way.
  • Use this slide to point out how a message would be passed through this diagram. The complete picture – with extensible framework for engines, bindings that we haven't even imagined yet. Can use this framework to build simple, enterprise solutions, build ESB (highlight WS-I profile, BPEL and Transformation engines, or complex integration platforms with expansive protocol bindings, generalized workflow, partner management, legacy interaction machines, etc. Speak to vendor community, the greater availability of system framework components, choice – operating at an even higher level of useful abstraction. JBI Gives you choice at the architectural level as well as at the platform level, and finally at the component selection and vendor level.
  • Use this slide to point out how a message would be passed through this diagram. The complete picture – with extensible framework for engines, bindings that we haven't even imagined yet. Can use this framework to build simple, enterprise solutions, build ESB (highlight WS-I profile, BPEL and Transformation engines, or complex integration platforms with expansive protocol bindings, generalized workflow, partner management, legacy interaction machines, etc. Speak to vendor community, the greater availability of system framework components, choice – operating at an even higher level of useful abstraction. JBI Gives you choice at the architectural level as well as at the platform level, and finally at the component selection and vendor level.
  • Use this slide to point out how a message would be passed through this diagram. The complete picture – with extensible framework for engines, bindings that we haven't even imagined yet. Can use this framework to build simple, enterprise solutions, build ESB (highlight WS-I profile, BPEL and Transformation engines, or complex integration platforms with expansive protocol bindings, generalized workflow, partner management, legacy interaction machines, etc. Speak to vendor community, the greater availability of system framework components, choice – operating at an even higher level of useful abstraction. JBI Gives you choice at the architectural level as well as at the platform level, and finally at the component selection and vendor level.

Transcript

  • 1. Building Service Oriented Architectures with Java and Web Services NY Java SIG Meeting – Feb 1st, 2005
    • Ashutosh Kulkarni, Group Mktg Manager
  • 2.
      • SOA
      • v/s
      • Web services
  • 3. The Solution is SOA
    • Service Oriented Architecture (SOA) is an integrated software infrastructure and design approach, leveraging Web computing standards, for delivering business functions as shared services.
  • 4. SOA vs. Web Services
    • Web Services
      • Business logic exposed as self-describing, loosely coupled, reusable services
      • Uses low level protocols and infrastructure
    • Service Oriented Architecture
      • Integrates web services architecture with legacy systems in a loosely coupled way.
      • Enables higher level IT functionality, such as Identity, Security, Management, BP modeling
  • 5. Before SOA S1 S2 Traditional EAI Middleware MOM Integration Broker Suites
  • 6. SOA Architecture Computing Approach SOA Middleware S1 SOA Middleware S2 Web Computing Standards (Internet)
  • 7.
      • Service Integration
  • 8. A Service as a Component
  • 9. A Composite Application
  • 10. Service Integration – many Technologies and artifacts
  • 11. JSR 208: New Container for Service Integration
  • 12.
      • JSR 208: Java Business Integration
  • 13. JSR 208 Architecture JBI Core Services Normalized Message Service Installation Deployment Management Component Registry System Management Admin. Console Logger Discovery & Deployment Orchestration (BPEL) WSDL Transformation (XSLT) WSDL J2EE WSDL Filesystem WSDL JMS WSDL WS-I Basic + Basic Security WSDL Other Bindings WSDL Other Service Engines WSDL Service 1 Service 2 Service 3 SOAP SOAP JMS WSDL WSDL WSDL J2SE/J2EE
  • 14. Composite Application Descriptor SOA Composite App Descriptor JBI Core Services Normalized Message Service Installation Deployment Management Component Registry System Management Admin. Console Logger Discovery & Deployment Orchestration (BPEL) WSDL Transformation (XSLT) WSDL J2EE WSDL Filesystem WSDL JMS WSDL WS-I Basic + Basic Security WSDL Other Bindings WSDL Other Service Engines WSDL Service 1 Service 2 Service 3 SOAP SOAP JMS WSDL WSDL WSDL J2SE/J2EE
  • 15. Deploying a Composite Application JBI Core Services Installation Deployment Management Component Registry Service 1 Service 2 Service 3 SOAP SOAP JMS WSDL WSDL WSDL J2SE/J2EE System Management Admin. Console Logger Discovery & Deployment Orchestration (BPEL) WSDL Transformation (XSLT) WSDL J2EE WSDL Filesystem WSDL JMS WSDL WS-I Basic + Basic Security WSDL Other Bindings WSDL Other Service Engines WSDL
  • 16.
      • Optimizing Service Integration
  • 17. Why XML? And why not?
    • Advantages
      • Ubiquity and momentum
      • Transparency
        • One syntax (unicode with <>)
        • Human readable
      • Enables loosely coupled robust (infoset) systems
    • Disadvantages
      • Verbose
        • Redundancy
        • Data as characters
      • More processing
        • Parsing and binding
    Advantages and disadvantages
  • 18. Why & Who “Binary XML”?
    • Expand range of use of WS
      • Limited bandwidth
      • Large docs/images
      • Fast response
      • Many requests, ...
    • With the cost-benefits of XML tools!
    • Standarization Is Critical!
      • W3C Workshop @ Sun
      • ISO/ITU-T Effort
        • Fast Infoset, Fast Schema, Fast WebServices
      • W3C XML Binary Characterization WG
        • Sun is co-editor, 41 participants, 25 organizations
  • 19. Standards for Interoperability Joint ITU-T | ISO/IEC standards Fast Web Services Fast Infoset Fast Schema Fast SOAP X.finf X.694 X.fws Self-describing or structured content SOAP message with content Schema-based content
  • 20. The Set of Technologies
    • Fast Infoset
      • For efficient XML Infoset processing
      • Binary encoding of XML Infosets
      • Substantial improvements (x3-x4 for JAX-RPC)
    • Fast Schema
      • For efficient schema-based processing
      • Binary encoding utilizing schema
      • Even better improvement than FI (another x2)
    • Fast Web Services
      • Combines Fast Infoset and Fast Schema
      • Fast SOAP - Binary encoding of SOAP 1.2
      • Use of protocol negotiation to adjust encoding
  • 21. Fast and APIs
    • Fast Infoset
      • Easy under JAX-RPC 1.x, StAX, SAX, DOM
      • Easy to use with intermediaries
      • Available as Open Source at Java.Net
    • FWS
      • Limited under 172
      • New APIs being refined
        • JAX-RPC 2.0 (JSR-224)
        • JAXB 2.0 (JSR-222)
      • New integrated stack implementation
  • 22. In a Nutshell
    • There is a need – today – for optimized Service Integration
    • Sun leads in Interop Standards
      • WS-I BP, WSS, Liberty, ebRegistry, WSRP
    • Sun leads Java specifications and specifications
      • JSR 208, Binary XML (Fast Infoset, etc.)
    • Sun will continue to lead the industry in helping developers build and deploy Service Oriented Architectures on the Java platform
  • 23. For More Information
    • JSR 208 EG Page
      • http://www.jcp.org/en/jsr/detail?id=208
    • WSDL 2.0
      • http://www.w3.org/TR/wsdl20/
    • Fast Web Services
      • http://jwsdp.dev.java.net
      • http://fi.dev.java.net (Open Source)
    • W3C XML Binary Characterization WG
      • http://www.w3c.org/XML/Binary
    • Oasis BPEL TC
      • http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsbpel
  • 24. THANK YOU
    • [email_address]