JAX-WS Attachment – Enable MTOM

It all begins with the fact that SOAP is XML. And when you send anything other than text, for instance, an image – it has to be converted into a datatype that an XML processor can understand.

Without MTOM, your image will be converted to base64Binary and placed smack in the middle of your SOAP envelope. This conversion process makes the data fat.

<tns:data>A very looooooooooooooooooooooong base64Binary string</tns:data>

Here’s a simple illustration:

lXWep

With MTOM, the image will be transmitted outside the envelope as a MIME attachment – in short, it’s sent according to its original datatype: a jpg, png, or gif. Of course it’s still transmitted as binary data, but this time, there’s no XML-related conversion, avoiding the unnecessary overhead. XOP comes into the picture as it’s the one that gives the location of the externalized image.

<soap:Body><soap:Envelope>

<tns:data><xop:include href="SomeUniqueID-ThatLeadsToTheImage"/></tns:data>

</soap:Body></soap:Envelope>

Content-id: "SomeUniqueID"

Content-Type: image/png

image binary data here

What is MTOM?
MTOM (Message Transmission Optimization Mechanism) provides an efficient mechanism for transmitting binary data to and from web services over internet. MTOM uses XML binary Optimized Packaging or XOP to serialize and de-serialize binary part of an XML infoset.
MTOM is a standard that is developed by the World Wide Web Consortium (W3C) and it is a SOAP Version 1.2 feature (based on the Infoset). Even though SwA (SOAP with Attachments) and MTOM are theoretically similar, and both encode binary data as a MIME attachment in a MIME document, SwA could be replaced by the more powerful MTOM and XOP mechanisms because it solves some of the interoperability issues of SwA. MTOM uses XOP in the context of SOAP and MIME over HTTP to achieve performance improvement.

How Does XOP works?
As we know, the serialization of XML infoset is text based and uses BASE64 binary-to-text encoding scheme, where the binary data represented in an ASCII string format. This increases the size of the XML payload.
An MTOM-enabled web services engine detects the presence of Base64Binary data. XOP packaging process extracts the binary data out of the XML Infoset and the binary data serialized differently. XOP process extracts the binary part of the XML info-set and leaves the XML Infoset with the binary parts replaced by external references. This is called XOP infoset and the external reference is added as “xop:Include” element in XML. This makes MTOM actually a “by reference” method.
The raw bytes are appended to the SOAP Message and are separated by a MIME boundary.
The XOP package is created by serializing the XOP infoset and the binary data as a MIME attachment. Once the data is received at the other end, the XOP Package is de-serialized into the XOP Infoset plus the extracted content and the extracted content is placed back in the XML infoset where the corresponding external reference is present.
See and example SOAP response below which uses MTOM. We will see the complete working example as we move on.

<S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/"> <S:Body> <ns2:retrieveImageResponse xmlns:ns2="http://globinch.com"> <return> <xop:Include href="cid:40128994-d019-4c2c-a293-49c448772ea7@example.jaxws.sun.com" xmlns:xop="http://www.w3.org/2004/08/xop/include"/> </return> </ns2:retrieveImageResponse> </S:Body> </S:Envelope>

You can see the reference to the MIME attachment as

<xop:Include href="cid:40128994-d019-4c2c-a293-49c448772ea7@example.jaxws.sun.com" xmlns:xop="http://www.w3.org/2004/08/xop/include"/>

If you examine the SOAP header you will something like the below

	
Transfer-encoding  : chunked
Content-type            : multipart/related;start="&lt;rootpart*75292b03-7617-4261-a44f-ac8d9df23382@example.jaxws.sun.com&gt;";type="application/xop+xml";boundary="uuid:75292b03-7617-4261-a44f-ac8d9df23382";start-info="text/xml"
#status# : HTTP/1.1 200 OK

The attachment details are as below

Name: 40128994-d019-4c2c-a293-49c448772ea7@example.jaxws.sun.com	
Content type: image/png	
Size:431731	
Part: 40128994-d019-4c2c-a293-49c448772ea7@example.jaxws.sun.com	
Type: XOP	
ContentId: 40128994-d019-4c2c-a293-49c448772ea7@example.jaxws.sun.com

The contentId is same as the reference.

Enabling MTOM in JAX-WS :
In JAX-WS, it’s easy to enable MTOM for a web service endpoint by using either the @MTOM or @BindingType annotations. At the client side, MTOM can be enabled either by passing a new instance of MTOMFeature class when getting a reference to the web service endpoint (port), or by calling the SOAPBinding.setMTOMEnabled(true) method on the binding provider object. Here are the usages and examples in details.

  • Enabling MTOM for the web service endpoint
  • @MTOM annotation :

    The following example illustrates a web service endpoint is annotated with the @MTOM annotation:

    import javax.jws.WebMethod;
    import javax.jws.WebService;
    import javax.xml.ws.soap.MTOM;
    
    
    @WebService
    @MTOM
    public class MyWebService {
      
      @WebMethod
      public void upload(byte[] data) {
        // implementation details...	
      }
    }
    

    The @MTOM annotation has two optional parameters, enabled and threshold. The enabled parameter has a boolean value and indicates if MTOM is enabled for the JAX-WS endpoint. If an attachment is smaller than the size specified in threshold parameter, the runtime will inline the binary data as base64 binary instead of creating an attachment.

    @WebService
    @MTOM(threshold = 10240)
    public class MyWebService {
    }
    

    An alternative way is using the @BindingType annotation with an appropriate value for the SOAP version used. For example:

    Enabling MTOM with SOAP version 1.1:

    import javax.xml.ws.BindingType;
    import javax.xml.ws.soap.SOAPBinding;
    
    @WebService
    @BindingType(value = SOAPBinding.SOAP11HTTP_MTOM_BINDING)
    public class MyWebService {
    }
    

    Enabling MTOM with SOAP version 1.2:

    import javax.xml.ws.BindingType;
    import javax.xml.ws.soap.SOAPBinding;
    
    @WebService
    @BindingType(value = SOAPBinding.SOAP12HTTP_MTOM_BINDING)
    public class MyWebService {
    }
    

    From the above examples, we can see that using the @MTOM annotation is preferred as its succinct and flexibility (enabled/disabled and threshold).

    Enabling MTOM for the client :

    The following example shows how to enable MTOM at the client by passing a new instance of the MTOMFeature class when getting a proxy reference the web service endpoint:

    import javax.xml.ws.soap.MTOMFeature;
    
    MyWebServiceService service = new MyWebServiceService();
    MyWebService port = service.getMyWebServicePort(new MTOMFeature());
    

    Suppose that the MyWebServiceService and MyWebService classes are generated by the wsimport tool. And similar to the @MTOM annotation, we can also specify the enabled and threshold parameters in the MTOMFeature class’ constructor like this:

    boolean enabled = true;
    int threshold = 10240;
    MyWebService port = service.getMyWebServicePort(new MTOMFeature(enabled, threshold));
    

    And here’s an alternative way, calling the SOAPBinding.setMTOMEnabled(true) method:

    MyWebServiceService service = new MyWebServiceService();
    MyWebService port = service.getMyWebServicePort();
    
    BindingProvider provider = (BindingProvider) port;
    SOAPBinding soapBinding = (SOAPBinding) provider.getBinding();
    soapBinding.setMTOMEnabled(true);
    

    For more info :

    http://stackoverflow.com/questions/215741/how-does-mtom-work

    http://java.globinch.com/enterprise-java/web-services/jax-ws/jax-ws-attachment-enable-mtom-jax-ws-web-services/

    http://www.tuicool.com/articles/I3yEbu

    Be Stateless Be scalable

  • A stateful session bean can keep data between client calls. This means resources (memory, db connection, etc.) are held by the bean waiting for another call from the client.
  • By storing this state on the client and sending it with each request, you can have the same state, but with better scalability.
  • Stateless services make scaling out easier because it means that once a request has been processed, the next request from that web visitor does not necessarily have to come back to the same machine, which means you can (in theory) have as many machines as you want service the same kind of requests. If your traffic doubles in volume you just add the same number of machines and boom, you can now service twice as many requests.
  • SOAP Roles

    A node processing / forwarding a SOAP message is said to act in one or more SOAP roles. Here is a simple diagram showing 3 nodes (computers) involved in the processing of a SOAP message:

    soap-roles-1

    The first node is the sender. This role is not mentioned in the SOAP specification though.
    The second node is an intermediary node which forwards the SOAP message. Intermediary nodes may also alter the SOAP message. For instance, they may add, modify or remove header elements, or even change the body. Intermediary nodes are set to act in the next role.
    The last node in the diagram is the “ultimateReceiver” of the SOAP message. The ultimate receiver is the node that actually processes the SOAP message.

    Role :

    A SOAP message travels from the originator to the ultimate destination, potentially by passing through a set of SOAP intermediaries along the message path. A header can be targeted for a specific node or for the final node (i.e. SOAP 1.1 actor attribute or SOAP 1.2 role attribute), and when that happens the node must do something with the header. This can be either to use it or to ignore it.

    roles

    Note no role attribute present, so this header block is to be processed by the ultimate receiver of the message and no other node.

    A node processing / forwarding a SOAP message is said to act in one or more SOAP roles. Header blocks (elements) can be targeted at nodes acting in specific roles. In other words, if a header block is targeted for nodes acting in the “ultimateReceiver” role, then only nodes acting as ultimate receivers must process that header block. All other nodes should leave it unprocessed.
    Here is an example using the role attribute:

    <env:Header>
      <jj:maxTime value="10000" xmlns:jj="http://jenkov.com"
        role="http://www.w3.org/2003/05/soap-envelope/role/ultimateReceiver"
        />
    </env:Header>
    

    In this example the header element is only intended to be processed by the ultimate receiver of the SOAP message. Intermediary nodes should ignore this header element.
    When a SOAP Header child element contains a role attribute, only nodes acting in that role must process that element. All other nodes should leave it be.

    The mustUnderstand Attribute :

    The mustUnderstand attribute means that any node (computer) processing the SOAP message must understand the given header block. A “node” may not alway be the final receiver of the SOAP message. The message might be routed via intermediate nodes before ending up at the receiving / processing node (the final web service).
    In case an intermediate node does not understand the header block (element) containing the mustUnderstand attribute, it must return a SOAP fault.

    The mustUnderstand attribute indicates whether processing of the header is optional or mandatory. This basically translates to the node trying to find an appropriate handler that matches the header and proceed with processing the message in a manner consistent with its specification. If it can’t find an appropriate handler it must return an error and stop further processing. If mustUnderstand is true/1 the node is not allowed to ignore it.

    The mustUnderstand attribute should only appear on the root element of a SOAP header block. If it
    appears elsewhere, it should be ignored.
    The BP stipulates that the mustUnderstand attribute may only have the value “1” or “0”. The default
    value is “0”.

    Here is an example:

    <env:Header>
      <jj:maxTime value="10000" xmlns:jj="http://jenkov.com"
                   mustUnderstand="true"
        />
    </env:Header>
    

    It is not considered an error if the Ultimate Receiver receives a SOAP header block with the
    mustUnderstand attribute set to “1” and the role attribute specifying some role that the ultimate
    receiver does not take on.

    For more info :

    http://tutorials.jenkov.com/soap/roles.html

    http://tutorials.jenkov.com/soap/header.html

    OCWSD

    RESTful web service :

    @Path :

  • Paths are relative
  • Paths are relative. For an annotated class the base URI is the application path. For an annotated method the base URI is the effective URI of the containing class. For the purposes of absolutizing a path against the base URI , a leading ‘/’ in a path is ignored and base URIs are treated as if they ended in ‘/’. E.g.:

    @Path("widgets")
    public class WidgetsResource {
    
        @GET
        String getList() {...}
    
        @GET @Path("{id}")
        String getWidget(@PathParam("id") String id) {...}
    
    }
    

    In the above, if the application path is catalogue and the application is deployed at http://example.com/, then GET requests for http://example.com/catalogue/widgets will be handled by the getList() method while requests for http://example.com/catalogue/widgets/nnn (where nnn is some value) will be handled by the getWidget() method. The same would apply if the value of either @Path annotation started with ‘/’.

    A @Path value may or may not begin with a ‘/’, it makes no difference. Likewise, by default, a @Path value may or may not end in a ‘/’, it makes no difference, and thus request URLs that end or do not end in a ‘/’ will both be matched.

  • Regular expression in @Path
  • If it is required that a user name must only consist of lower and upper case alpha-numeric characters then it is possible to declare a particular regular expression, which overrides the default regular expression, “[^/]+?”, for example:

    @Path("users/{username: [a-zA-Z][a-zA-Z_0-9]*}")
    

    In this type of example the username variable will only match user names that begin with one upper or lower case letter and zero or more alpha numeric characters and the underscore character. If a user name does not match that a 404 (Not Found) response will occur.

    @Produces

    The @Produces annotation is used to specify the MIME media types of representations a resource can produce and send back to the client. In this example, the Java method will produce representations identified by the MIME media type “text/plain”.

    @Produces can be applied at both the class and method levels. Here’s an example:

    @Path("/myResource")
    @Produces("text/plain")
    public class SomeResource {
        @GET
        public String doGetAsPlainText() {
            ...
        }
    
        @GET
        @Produces("text/html")
        public String doGetAsHtml() {
            ...
        }
    }
    

    The doGetAsPlainText method defaults to the MIME type of the @Produces annotation at the class level. The doGetAsHtml method’s @Produces annotation overrides the class-level @Produces setting, and specifies that the method can produce HTML rather than plain text.

    If a resource class is capable of producing more that one MIME media type then the resource method chosen will correspond to the most acceptable media type as declared by the client. More specifically the Accept header of the HTTP request declared what is most acceptable. For example if the Accept header is:

    Accept: text/plain
    

    then the doGetAsPlainText method will be invoked.

    Alternatively if the Accept header is:

    Accept: text/plain; q=0.9, text/html
    

    which declares that the client can accept media types of “text/plain” and “text/html” but prefers the latter, then the doGetAsHtml method will be invoked.

    More than one media type may be declared in the same @Produces declaration, for example:

    @GET
    @Produces({"application/xml", "application/json"})
    public String doGetAsXmlOrJson() {
        ...
    }
    

    The doGetAsXmlOrJson method will get invoked if either of the media types “application/xml” and “application/json” are acceptable. If both are equally acceptable then the former will be chosen because it occurs first.

    The examples above refer explicitly to MIME media types for clarity. It is possible to refer to constant values, which may reduce typographical errors, see the constant field values of MediaType:

    APPLICATION_ATOM_XML          "application/atom+xml"
    APPLICATION_FORM_URLENCODED   "application/x-www-form-urlencoded"
    APPLICATION_JSON              "application/json"
    APPLICATION_OCTET_STREAM      "application/octet-stream"
    APPLICATION_SVG_XML           "application/svg+xml"
    APPLICATION_XHTML_XML         "application/xhtml+xml"
    APPLICATION_XML               "application/xml"
    MULTIPART_FORM_DATA           "multipart/form-data"
    TEXT_HTML                     "text/html"
    TEXT_PLAIN                    "text/plain"
    TEXT_XML                      "text/xml"
    WILDCARD                      "*/*"
    

    AngularJs UI-Router

    ui-router :
    uiRouter is an alternative router for AngularJS v1.0. Instead of configuring a list of routes, you configure states.
    Changing State
    There are three ways to change the state and thus change the UI

    click a link with a ui-sref attribute
    <a ui-sref="state-name">link text</a>
    call

    $state.go('state-name');

    must inject $state to use

    navigate to the URL of a state

    typically by calling

    $location.path(url)

    or typing it into the browser address bar

    state :

    To define a route, we use the .config method and set our states on the $stateProvider.

    var starter = angular.module('starter', ['ionic', 'controllerModule'])
    .config(function($stateProvider, $urlRouterProvider) {
      $stateProvider
        .state('addOrder', {
          url: '/AddNewOrder',
          template: "<h1>HELLO!</h1>"
        }
        });
    });
    
    <body ng-app="starter">
        <div id='content' ng-controller='mainController'> 
             <a ui-sref="addOrder"> Add New Order </a></li>
             <div ui-view="main"></div>      
      </div>
    </body>
    

    template, templateUrl, templateProvider :

    We can set up templates on each of our views using one of the three following options:

    template – A string of HTML content or a function that returns HTML
    templateUrl – A string URL path to a template or a function that returns a URL path string
    templateProvider – A function that returns an HTML content string

    $stateProvider.state('home', {
      template: '<h1>Hello {{ name }}</h1>'
    });
    

    URL :

    The url option will assign a URL that the application is at to a specific state inside our app.

    $stateProvider
      .state('inbox', {
        url: '/inbox',
        template: "<h1>Welcome to your inbox</h1>"
      });
    

    When the user navigates to /inbox, then the app will transition into the inbox state and fill the main ui-view directive with the contents of the template “Welcome to your inbox”.

    Views :

    We can set multiple named views inside of a state. This feature is a particularly powerful one in ui-router: Inside of a single view, we can define multiple views that we can reference inside of a single template.

    If we set the views parameter, then the state’s templateUrl, template, and templateProvider will be ignored. If we want to include a parent template in our routes, we’ll need to create an abstract template the contains a template.
    Let’s say we have a view that looks like:

    <div>
      <div ui-view="filters"></div>
      <div ui-view="mailbox"></div>
      <div ui-view="priority"></div>
    </div>
    

    We can now create named views that fill each of these individual templates. Each of the subviews can contain their own templates, controllers, and resolve data.

    $stateProvider
      .state('inbox', {
        views: {
          'filters': {
            template: '<h4>Filter inbox</h4>',
            controller: function($scope) {}
          },
          'mailbox': {
            templateUrl: 'partials/mailbox.html'
          },
          'priority': {
            template: '<h4>Priority inbox</h4>',
            resolve: {
              facebook: function() {
                return FB.messages();
              }
            }
          }
        }
      });
    

    Controller :

    Just like in ngRoute, we can either associate an already registered controller with a URL (via a string) or we can create a controller function that operates as the controller for the state.

    If there is no template defined (in one of the previous options), then the controller will not be created.

    Steps to use the ui-router :

    Download :

    download from https://github.com/angular-ui/ui-router
    just need one file from release folder… angular-ui-router.min.js

    Include :

    <script src="js/angular-ui-router.min.js"></script>
    

    Add module dependency :

    Add ui-router as a module dependency

    var app = angular.module('app-name', ['ui.router']);
    

    How to use :

  • use ui-view directive
  • When dealing with routes and states inside of ui-router, we’re mainly concerned with which state the application is in as well as at which route the web app currently stands.
    The templates we define at any given state will be placed inside of the

    <div ui-view></div>

    element of the route or state it was called. Each of these templates can include their own ui-view as well, which is how we can have nested views inside our routes.

    Wherever a view is desired use

    <div ui-view>initial content</div>

    When dealing with routes and states inside of ui-router, we’re mainly concerned with which state the application is in as well as at which route the web app currently stands.the templates we define at any given state will be placed inside of the

    <div ui-view></div>

    element.

    The ui-view directive tells $state where to place your templates. A view can be unnamed or named.

    <!-- Unnamed -->
    <div ui-view></div> 
    
    <!-- Named -->
    <div ui-view="viewName"></div>
    

    You can only have one unnamed view within any template (or root html). If you are only using a single view and it is unnamed then you can populate it like so:

    <div ui-view></div>
    
    $stateProvider.state("home", {
        template: "<h1>HELLO!</h1>"
    })
    

    The above is equivalent to specifying your view explicity, by name, in this case an empty name:

    $stateProvider.state("home", {
        views: {
            "": {
                template: "<h1>HELLO!</h1>"
            }
        }    
    })
    

    But typically you’ll only use the views property if you name your view or have more than one view in the same template. There’s not really a compelling reason to name a view if its the only one, but you could if you wanted, like so:

    <div ui-view="main"></div>
    
    $stateProvider.state("home", {
        views: {
            "main": {
                template: "<h1>HELLO!</h1>"
            }
        }    
    })
    

    Really though, you’ll use views to set up multiple views:

    <div ui-view></div>
    <div ui-view="chart"></div> 
    <div ui-view="data"></div> 
    
    $stateProvider.state("home", {
        views: {
            "": {
                template: "<h1>HELLO!</h1>"
            },
            "chart": {
                template: "<chart_thing/>"
            },
            "data": {
                template: "<data_thing/>"
            }
        }    
    })
    
  • use ui-sref directive
  • A directive that binds a link (“anchor(a)”) to a state. If the state has an associated URL, the directive will automatically generate & update the href attribute via the $state.href() method. Clicking the link will trigger a state transition with optional parameters. Also middle-clicking, right-clicking, and ctrl-clicking on the link will be handled natively by the browser.

    Usage:

    ui-sref=’stateName’ – Navigate to state, no params. ‘stateName’ can be any valid absolute or relative state, following the same syntax rules as $state.go()
    ui-sref=’stateName({param: value, param: value})’ – Navigate to state, with params.

    <!-- index.html -->
    <body>
        <div ui-view></div>
        <!-- We'll also add some navigation: -->
        <a ui-sref="state1">State 1</a>
    </body>
    

    Working Example :

    index.html
    <!DOCTYPE html>
    <html>
      <head>
        <meta charset="utf-8">
        <meta name="viewport" content="initial-scale=1, maximum-scale=1, user-scalable=no, width=device-width">
        <title></title>
        <link href="css/style.css" rel="stylesheet">
        <script src="lib/angular.min.js"></script>
        <script src="lib/angular-ui-router.js"></script>
        <!-- your app's js -->
        <script src="js/app.js"></script>
        <script src="js/controllers.js"></script>
      </head>
      <body ng-app="starter">
        <div id='content' ng-controller='mainController'>
                    <a ui-sref="addOrder"> Add New Order </a>
                    <div ui-view="addOrderView"></div> 
                    <button ng-click='showOrders()'>Show Orders</button>               
                    <div ui-view="showOrdersView"></div>                  
        </div>
      </body>
    </html>
    
    app.js
    var starter = angular.module('starter', ['ui.router','controllerModule'])
    .config(function($stateProvider, $urlRouterProvider) {
      $stateProvider
        .state('addOrder', {
          url: '/AddOrder',
          views: {
          'addOrderView': {
            template: '<h4>Add Order</h4>'
          }
        }
        })
         .state('showOrders', {
          url: '/ShowOrders',
          views: {
          'showOrdersView': {
            template: '<h4>Show Orders</h4>'
          }
        }
        });
    });
    
    controllers.js
    angular.module('controllerModule', [])
    
    .controller('mainController', function($rootScope, $state, $stateParams) {
    	$rootScope.showOrders = function(){
    		$state.go('showOrders');
    	 }
    });
    

    For more info :

    https://github.com/angular-ui/ui-router/wiki/Quick-Reference#stateproviderstatestatename-stateconfig

    http://www.ng-newsletter.com/posts/angular-ui-router.html

    http://java.ociweb.com/mark/other-presentations/AngularJS-ui-router.pdf

    http://cnpmjs.org/package/angular-ui-router

    https://github.com/angular-ui/ui-router/wiki/Quick-Reference#note-about-using-state-within-a-template

    Introduction of WSDL

    WSDL elements :
    ia2cf27cn-7123

  • Description of elements :
  • wsdl_1
    wsdl_2

    Relation between code and elements :

    If you are publishing this class using

    Endpoint.publish("http://testhost:9899/ws/helloexample", new sayHello());
    

    So your generated wsdl will be mapped like below.

    Interface or class name: PortType
    Method name: Operation
    Method name: input message (request)
    Method name+Response: output message (response)

    <portType name="sayHello">
        <operation name="helloWorld">
           <input message="tns:helloWorld"/>
           <output message="tns:helloWorldResponse"/>
        </operation>
    </portType>
    

    Endpoint.publish(“http://testhost:9899/ws/helloexample&#8221;,new sayHello())
    : address location

      <wsdl:service name="sayHelloService">
      <wsdl:port name="sayHelloPort" binding="tns:sayHelloPortBinding">
      <soap:address location="http://testhost:9899/ws/helloexample" />
      </wsdl:port>
    

    For more info http://stackoverflow.com/questions/20891198/details-on-wsdl-ports

    Relation between elements :

    WSDL_11vs20

    Structure-of-WSDL-Crunchify-Tutorials-Tips

    Define a service in WSDL :

  • Create an Empty Definition
  • The document element is called [wsdl:]definitions in the http://schemas.xmlsoap.org/wsdl/ namespace.

    We’ll use the ‘name’ attribute to give a common name for the tideinfo service:

    <wsdl:definitions name="tideinfo"
       xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
       targetNamespace="http://www.smallx.com/services/tideinfo/2005/wsdl"
       xmlns:service="http://www.smallx.com/services/tideinfo/2005/wsdl"
    >
       <wsdl:documentation xmlns="http://www.w3.org/1999/xhtml">
       <p>This service provides tide information by NOAA tide monitor location.</p>
       </wsdl:documentation>
    </wsdl:definitions>
    

    Inside this element is where all the descriptions of the messages/etc. go.

    The [wsdl:]documentation element is nice to use for descriptions of how to use the service or where to get more information.

  • Import the Schema
  • We can import the schema for the schema via the [wsdl:]import element:

    <wsdl:definitions ...>
    
    <wsdl:import namespace="http://www.smallx.com/services/tideinfo/2005" 
                 location="http://www.smallx.com/tideinfo-service/tideinfo.xsd"/>
    
    </wsdl:definitions>
    

    This makes the element declarations and types available to the WSDL definitions.

  • Define the Service
  • We have only one service:

    <wsdl:definitions ...>
    
    <wsdl:service name="tideinfo">
       <wsdl:port name="tideinfo-port" binding="service:tideinfo-binding"/>
    </wsdl:service>
    
    </wsdl:definitions>
    

    We’ve defined the port but referred to the [service:]tideinfo-binding binding.

    We need to define [service:]tideinfo-binding.

  • Define the Binding
  • The [service:]tideinfo-binding binding:

    <wsdl:definitions ...>
    
    <wsdl:binding name="tideinfo-binding">
       <wsdl:operation name="get-tides">
           <wsdl:input message="service:get-tides"/>
           <wsdl:output message="service:tides"/>
       </wsdl:operation>
    </wsdl:binding>
    
    </wsdl:definitions>
    

    We now need to define the messages.

  • Define the Messages
  • The messages:

    <wsdl:definitions ...>
    
    <wsdl:message name="get-tides">
       <part name="body" element="t:tideinfo"/>
    </wsdl:message>
    
    <wsdl:message name="tides">
       <part name="body" element="t:tideinfo"/>
    </wsdl:message>
    
    </wsdl:definitions>
    

    This service uses the same element for request and response.

  • The Whole Thing
  • <wsdl:definitions name="tideinfo"
       xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
       targetNamespace="http://www.smallx.com/services/tideinfo/2005/wsdl"
       xmlns:service="http://www.smallx.com/services/tideinfo/2005/wsdl"
       xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
    >
       <wsdl:documentation xmlns="http://www.w3.org/1999/xhtml">
       <p>This service provides tide information by NOAA tide monitor location.</p>
       </wsdl:documentation>
    
    <wsdl:import namespace="http://www.smallx.com/services/tideinfo/2005" 
                 location="http://www.smallx.com/tideinfo-service/tideinfo.xsd"/>
    
    <wsdl:message name="get-tides">
       <part name="body" element="t:tideinfo"/>
    </wsdl:message>
    
    <wsdl:message name="tides">
       <part name="body" element="t:tideinfo"/>
    </wsdl:message>
    
    <wsdl:binding name="tideinfo-binding">
       <soapbind:binding style="document"
                         transport="http://schemas.xmlsoap.org/soap/http"/>
       <wsdl:operation name="get-tides">
           <wsdl:input message="service:get-tides">
              <soap:body part="body" use="literal"/>
           </wsdl:input>
           <wsdl:output message="service:tides">
              <soap:body part="body" use="literal"/>
           </wsdl:output>
       </wsdl:operation>
    </wsdl:binding>
    
    <wsdl:service name="tideinfo">
       <wsdl:port name="tideinfo-port" binding="service:tideinfo-binding">
          <soap:address location="http://www.smallx.com/tideinfo-service/tideinfo.pd"/>
       </wsdl:port>
    </wsdl:service>
    
    </wsdl:definitions>
    

    For more info http://courses.ischool.berkeley.edu/i290-14/s05/lecture-22/allslides.html

    Learning AngularJS on Single Page Applications

    Single Page Application (SPA) :

    is an app that only requires a browser to load just a single page. The browser wont have the burden to reload the page anymore on every minimal interactions that the user makes and instead, focus only on the things that required changes.

    Modules :
    You can think of a module as a container for the different parts of your app – controllers, services, filters, directives, etc.

    Most applications have a main method that instantiates and wires together the different parts of the application.

    Angular apps don’t have a main method. Instead modules declaratively specify how an application should be bootstrapped. There are several advantages to this approach:

    • The declarative process is easier to understand.
    • You can package code as reusable modules.
    • The modules can be loaded in any order (or even in parallel) because modules delay execution.
    • Unit tests only have to load relevant modules, which keeps them fast.
    • End-to-end tests can use modules to override configuration.
  • Declairing a module :
  • // declare a module
    angular.module(‘module-name’,[dependencies]);
    
  • Important things to notice:
  • The reference to module “module-name” in

    <html ng-app="module-name">

    . This is what bootstraps the app using your module.
    Every module should have a name, which is specified in the first parameter. Second parameter to module function is an array, which may contain names of other modules or services. If the module doesn’t depend on anything, the array can be left blank.

  • Module Loading & Dependencies :
  • A module is a collection of configuration and run blocks which get applied to the application during the bootstrap process. In its simplest form the module consist of collection of two kinds of blocks:

  • Configuration blocks
  • get executed during the provider registrations and configuration phase. Only providers and constants can be injected into configuration blocks. This is to prevent accidental instantiation of services before they have been fully configured.

  • Run blocks
  • get executed after the injector is created and are used to kickstart the application. Only instances and constants can be injected into run blocks. This is to prevent further system configuration during application run time.

    angular.module('myModule', []).
      config(function(injectables) { // provider-injector
        // This is an example of config block.
        // You can have as many of these as you want.
        // You can only inject Providers (not instances)
        // into config blocks.
      }).
      run(function(injectables) { // instance-injector
        // This is an example of a run block.
        // You can have as many of these as you want.
        // You can only inject instances (not Providers)
        // into run blocks
      });
    
  • Configuration Blocks
  • There are some convenience methods on the module which are equivalent to the config block. For example:

    angular.module('myModule', []).
      value('a', 123).
      factory('a', function() { return 123; }).
      directive('directiveName', ...).
      filter('filterName', ...);
    
    // is same as
    
    angular.module('myModule', []).
      config(function($provide, $compileProvider, $filterProvider) {
        $provide.value('a', 123);
        $provide.factory('a', function() { return 123; });
        $compileProvider.directive('directiveName', ...);
        $filterProvider.register('filterName', ...);
      });
    

    When bootstrapping, first Angular applies all constant definitions. Then Angular applies configuration blocks in the same order they were registered.

  • Run Blocks
  • Run blocks are the closest thing in Angular to the main method. A run block is the code which needs to run to kickstart the application. It is executed after all of the service have been configured and the injector has been created. Run blocks typically contain code which is hard to unit-test, and for this reason should be declared in isolated modules, so that they can be ignored in the unit-tests.

  • Dependencies
  • Modules can list other modules as their dependencies. Depending on a module implies that required module needs to be loaded before the requiring module is loaded. In other words the configuration blocks of the required modules execute before the configuration blocks of the requiring module. The same is true for the run blocks. Each module can only be loaded once, even if multiple other modules require it.

    For more info https://docs.angularjs.org/guide/module

    Directives :

    Directives are attribute-like code in the html page that is only understandable by AngularJS.
    Various angular directives are ng-app, ng-controller, ng-click, ng-repeat etc. Using these we can build highly interactive and dynamic website.

  • ng-app
  • The first directive that we need to know is the ng-app. This directive tells the AngularJS compiler that the page is an angular module/application.
    We must put the directive “ng-app” to the parent tag. The best practice is to put the said directive in the root tag of the document which is . It is much readable and can be noticed easily if it’s placed there.

    ng-app defines the code block that is controlled by AngularJS. In most of the real time scenarios, we may need to write our own filters, define routing for our application or define new directive for our application. So we need to customize angular for our needs and ng-app is the place for that. Till now we have used parameterless ng-app directive, which bootstraps the default angular behavior on our application. We will look into ng-app with parameter, called application module A single page can have only one ng-app directive. (If we bootstrap manually, it is possible to have multiple ng-app, but it is not advised).

    //Only one ngApp directive can be used per HTML Document.
    
    //You can inject the second module as a dependency to the first module:
    
    var shoppingCartModule = angular.module("shoppingCart", ["namesList"]);
    
    //And in the HTML wrap the contents inside a single element with ng-app:
    
    <html>
    <body>
    <div ng-app="shoppingCart" ng-controller="ShoppingCartController">
        <h1>Your order</h1>
    </div>
    </body>
    </html>
    
  • ng-controller
  • This attribute defines a Controller to be bound with the view. In this case we defined a controller called ContactController in DIV using ng-controller attribute. Thus whatever we put inside that DIV, the ContactController will have its influence on it.

    <!DOCTYPE html>
    <html ng-app>
    <head>
    <title>Hello World, AngularJS</title>
    <script type="text/javascript"
        src="http://ajax.googleapis.com/ajax/libs/angularjs/1.0.7/angular.min.js"></script>
    </head>
    <body>
    <div ng-controller="ContactController"> 
    </div>
    </body>
    </html>
    

    ContactController is nothing but a plain vanilla JavaScript function. In the demo we defined it as function. Also see the definition of ContactController function. There is an object $scope which we pass as an argument. This object is used to bind the controller with view. When AngularJS initialize this controller, it automatically creates and injects the $scope object to this function using dependency injection (More on dependency injection in coming tutorials). For now just note that the $scope object is created by Angular and injected in this controller function.

    var myApplication=angular.module('myApp',[]);
    
    myApplication.controller('ContactController',
                             ['$scope', '$filter', function (s, f) {
                                s.name = 'manas';
                                s.nameUpper = f('uppercase')(s.name);
           }]);
    
  • ng-click
  • It is also possible to define functions on $scope inside controller and use the same in View. In our demo, we created a function add() on $scope and use it on Add button click:

    
    //in html file
    <!DOCTYPE html>
    <html>
      <head>
    <script src="js/app.js"></script>
        <script src="js/controllers.js"></script>
      </head>
      <body ng-app="starter">
        <div id='content' ng-controller='mainController'>
               <button ng-click='sayAlert("mate")'>Hello</button>
      </div>
    </body>
    </html>
    
    //in controllers.js
    angular.module('controllerModule', [])
    
    .controller('mainController', function($scope) {
    	$scope.understand = "I now understand how the scope works!";
    	$scope.sayAlert = function(helloString){
    		alert("hi "+helloString);
    	 }
    });
    

    The function add() is bound to Add button using an attribute ng-click. ng-click binds the click event on the button or link or any clickable element with the function that is defined within $scope. So in this case, whenever Add button is clicked, the add() method on $scope will be called.

    Scopes :

    Scope is nothing but an object that Glues the View with Controller. They hold the Model data that we need to pass to view. Scope uses Angular’s two-way data binding to bind model data to view.

    Imaging $scope as an object that links Controller to the View. It is controllers responsibility to initialize the data that the view needs to display. This is done by making changes to $scope.

    Let us see a small Hello World application to understand $scope.

    <!DOCTYPE html>
    <html ng-app>
    <head>
    <title>Hello World, AngularJS - ViralPatel.net</title>
    <script type="text/javascript"
        src="http://ajax.googleapis.com/ajax/libs/angularjs/1.0.7/angular.min.js"></script>
    </head>
    <body>
    <div ng-controller="ContactController">
         Email:<input type="text" ng-model="newcontact"/>
        <button ng-click="add()">Add</button>
        <h2>Contacts</h2>
     
        <ul>
            <li ng-repeat="contact in contacts"> {{ contact }} </li>
        </ul>
     
    </div>
    <script type="text/javascript">
        function ContactController($scope) {
            $scope.contacts = ["hi@email.com", "hello@email.com"];
     
            $scope.add = function() {
            $scope.contacts.push($scope.newcontact);
            $scope.newcontact = "";
            }
        }
    </script>
    </body>
    </html>
    

    Relation between all these :

    service