Type is a metadata about the chunk of memory that classifies the kind of data stored there.This is important to determine the kind of operation that can be performed on the data.
- Simple/Primitive Types , Container types(list/arrays, dictionaries/hashes), Use Defined types (Classes)
Strong/Weak typing vs Static/Dynamic typing
About content models in XML
1. Closed Content Model: A content model defined by a DTD can be described as "closed": it describes all and only what may appear in the content of the element.
2.Open Content Model: In an open content model, all required elements must be present, but it is not an error for additional elements to also be present.
3.Refined content Model: A refined content model is the middle ground: additional elements may be present, but only if the schema defines what they are. Consider a schema that extends another: it might refine the content model of some element type to add new elements.One standard schema and one or more extensions to that schema that will need.
Evolution of SOA
The main concern was making teh software development process easy, flexible in terms of writing, maintaining it's functionality and deployment. The initial concern was just on writing and so came the concept reusability for functionality which are used again and again in code.
1.Modular Designing - Writing functions and Subroutines for pieces of code called repeatedly. But still it required cutting and pasting these modules in various application and had problems in maintenance cause a functionality update required tracking back all the applications where that module was used.
It was followed by OOP model
2. Object Oriented Programming was great in software development but still it didn't solve problems and one wanted a way to reuse and maintain the functionality and not just the code.
3. Component - Based Software : which focussed on building large software systems by integrating previously existing components.It was a good solution to reuse and maintenance but opened room for otehr issues like distributed software, application integration, varying platforms, protocols, devices; internet etc.
4. Finally came SOA which ansered all teh above problems of protocols and platform and made application integration easy.
SOA and its Components
- Service
- Message
- Dynamic Discovery
- Web Services
Service- It is an exposed piece of functionality with the following properties:
1. The interface contract to the service is platform -independent which implies that a client from anywhere, on any OS, and any language, can consume the service.
2. The service can be dynamically located and invoked which implies the availability of a discovery service. It enables a look up mechanism where consumers can go to find a service based on some criteria.
3. Service is self contained. i.e it maintains its own state.
Message
Service providers and consumers communicate via messages. Service expose an interface contract which defines the behaviour of the servive and teh messages they accept in return. BEcause the interface is platform independent, the technology used to define message is also platform independent. So messages are constructed using XMLthat conform teh XML Schema. Because service providers and consumers interact only via messages, the structure and design is very important. It should also be scalable at the same time.
Dynamic Discovery
The directory service is an intermediary between providers and consumers. Providers register with teh directory service and consumers query the directory service to find service providers. Directory Services with SOA provcides:
- Scalability of services
- Decouples consumers from providers
- Allows updates of services
- Look up service for consumers
- Allows consumers to choose between providers at runtime rather than hard coding a single provider
Web Service
Web Services are built on a similar architecture. The platform independent protocols include HTTP, XML, UDDI, WSDL and SOAP.
Dynamic discovery and invocation handled by UDDI, WSDL and SOAP
Platform independent interface contract - XML
Interoperability - HTTP
SOAP is a new protocol that uses XML as an encoding scheme for request and response parameters using HTTP as a transport. A SOAP endpoint is simply an HTTP based URL that identifies a target for method invocation. It does not tie a psecific object to a given endpoint.It is up to the implementor to decide how to map the object endpoint identifier onto a server side object.
- SOAP is an HTTP POST request
- It must use the text/xml content type
- It must contain a RequestURI. How this is interpreted by the server is implementation specific for example it could be mapped either to a class or an object
- IT contains the method name to eb invoked in te SOAPMethod Name Header.
- The HHP payload of a SOAP request is an XML document that contains values of the parameters of teh method (XML is euqivalent to NDR in DCOM)
- The namepsace URI that scopes the method name in SOAP is equivalent to the interface ID that scopes a method name in DCOM or IIOP.
- The SOAPMethod Name header must match teh first child element under the body element, otherwise teh acll is rejected.
POST/ objectURI HTTP/1.1 -------------- Object EndpointID
SoapMEthodName---------------------Interface Identifier and Method Identifier
Soap Envelope and Header -------------- Extension HEader
Soap Body ---------------- Parameter Data
FAult Responses ---------HRESULTin COM
How does the SOAP server uses the request header to dispatch the request; is left as an implementation detail.SOAP servers can map Request-URIs to class names, dispatching the call to static or instances of class which is alive for teh duration of the request. Or the object to stay alive over the time and can be located on teh server by means of some key or teh SOAP servers could use HTTOP cookies to store teh state of teh object which could be recovered at each method request.
SOAP Payload
XML provides an encoding scheme for serializing instances of datatypes to XML.IN SOAP request and responses are actually instances of types. the parameters are serialized to a request object prior to to sending the request message. Parameters are then deserialized from the response object recived by the response message.
Once a TCP connection is established between teh client and the server. The client can send request messages to the server and teh server can send the response after processing teh requests. standard port used for HTTP requests is 80 but anything could be used.
POST /foobar HTTP/1.1 (HTTP method, Request URI and Protocaol version )
Host: IP address
Content-Type: text/ plain (MIME type) (type of the request payload)
Content-Length: Size of the payload (size of teh paylaod)
Message
Two methods of HTTP are GET(to surf the web) and POST (allows to send data from client to server)
Request URI is used by the HTTP server software to locate the target of the request.
Advantages of HTTP version 1.1 over version 1 is that it allows chunked data transfer and also support for keeping TCP conncetions alive across HTTP requests. There is an extra blank line taht separated teh HTTP headers from the payload.
A HTTP response
200 OK (Status of the request)
Content-Type:
Content-Length:
200 is for OK
400 is for BAD request
307 is for redirect
Header connection: could be used in teh request and response messages to keep the TCP connection alive for a continous request response pairs between client and teh server.
|
COM |
CORBA |
|
1. Explicit interface ID |
The interface ID is implicit as a CORBA object only implements one interface |
|
2.Format of the parameter values in the payload is Network Data Representation (NDR) |
Format of the parameter values in the payload is Common Data Representation (NDR) |
|
3.Transmissible representation (to communicate object references around the network) of the ORPC endpoint is called OBJREF |
Transmissible representation (to communicate object references around the network) of the ORPC endpoint is called IOR-Interoperable object reference |
Problems with COM and CORBA
- The NDR and CDR format were incompatible.
- the industry did not shift to either one and there was lack of convergence
- DCOM and CORBA had a decent performance for server to server interaction but it failed for server to client interaction in a network.
- DCOM and CORBA were vendor specific solutions. Proper deployment of the technology required the use of single-vendor implementation. DCOM was Windows NT mainly and CORBA was every machine ran the same ORB product.
- DCOM and CORBA worked well in a closely knit environment.
- Both required high tech runtime environments. Both had very rigid specifications to follow for a successful implementation.
- Both were unable to work in internet scenarios.
Distributed applications fail work across the Internet when firewalls get in the way. Since most firewalls block all but a few ports, such as the standard HTTP port 80, all of distributed object protocols like DCOM suffer because they rely on dynamically assigned ports for remote method invocations. Since SOAP relies on HTTP as the transport mechanism, and most firewalls allow HTTP to pass through, you'll have no problem invoking SOAP endpoints from either side of a firewall
DCOM and CORBA worked ok for server to server interaction but failed for client to server inteaction because the DCOM packets would fail to be transported successfully because of the HTTP biased internet connectivity technology.
So for connecting a server from a client HTTP would be the best RPC like protocol (request and response). DCOM, CORBA and HTTP layers the requesta nd response communications over TCP/IP.
Scalable, distributed applications and systems is the way where the world is moving today. Going back to the history of RPC, there were two communication models
1. Messaging - any party could send a message anytime and it was more like communicating with external processes concurrently.
2. Request/response Protocols- parties could interact in request and response pairs which resembled like communication within a single process. Application that sent a request had to wait for the response before it could do anything which was similar to the RPC mechanism.
Then came the era when people combined the object oriented languages with RPC and lead to the birth of object RPC protocols. the primary difference between the ORPC and normal RPC protocols was that ORPC mapped the communication endpoint to a language level object.
The request would contain parameters like Object endpoint ID (to locate teh object in the server process), InterfaceID and method ID (to locate which method exactly has to be called from the object), parameter data and extra headers foir additional information.
The request would contain the status code, headers and parameter data to return output parameters.
Two dominant ORPC protocols are 1. DCOM and 2. CORBA's Internet Inter-ORB Protocol (IIOP)
- COM is all about objects and getting them to communicate with each other. Within COM, objects take on one or both of the following roles:client and the server. A server can itself be a client, since it might get another server to perform a task. COM is a system which allows a client to create a server (if no such server currently exists) and then allows these to communicate together. The client and server can be on the same machine or even on different machines. It is a distributed object system which provide the infrastructure for supporting remote object invocation and remote method invocation.
Every communication with a COM object is via an interface which is simply a grouping of methods and properties. A COM object can support one or more interfaces.
A COM object is like a building block -- some blocks offer more functionality than others, and new blocks can be created from joining other blocks together.
- Interface
The idea of an interface is fundamental to COM. An interface is simply a suite of methods and properties (that represent one functionality) owned by the object. An object can have multiple such interfaces. Any COM interface inherits the IUknown interface which consists QueryInterface()-navigating between interfaces of the same object, AddRef(), Release()
-
Object Class and Object Instance: Object class is basically what the object can do. All teh information within a class is held within its collection of interfaces. Object Instance is an instantiation of object class.
-
InterfaceID: Each interface of an object represents a different view of taht object and is identified by a GUID called interfaceID.
-
ClassID: The object server contains multiple object instances from different classes easch of which is identified by a GUID called the classID
Serialization is the process of converting an object into a form that can be readily transported.The central class in XML serialization is the XmlSerializer class, and its most important methods are the Serialize and Deserialize methods. The XML stream generated by the XmlSerializer is compliant with the World Wide Web Consortium (www.w3.org) XML Schema definition language (XSD) 1.0 recommendation. The data in the objects is described using programming language constructs like classes, fields, properties, primitive types, arrays, and even embedded XML in the form of XmlElement or XmlAttribute objects.
Attributes can be used to control the XML serialization of an object, or to create an alternate XML stream from the same set of classes. By default, an XML element name is determined by the class or member name.This default behavior can be changed if you want to give the element a new name.
Also, XML serialization can take care of public fields and properties only and it does not serialise methods, private fields and read only fields. Type identity and assembly information are not included.
A class must have a default constructor to be serialized by XmlSerializer. XmlSerializer can process classes that implement IEnumerable or ICollection differently if they meet certain requirements. The various attributes which can used to customize the behaviour of the serialization of object are shown in the table below.
| Attribute |
Applies to |
Specifies |
| XmlAnyAttributeAttribute |
Public field, property, parameter, or return value that returns an array of XmlAttribute objects. |
When deserializing, the array will be filled with XmlAttribute objects that represent all XML attributes unknown to the schema. |
| XmlAnyElementAttribute |
Public field, property, parameter, or return value that returns an array of XmlElement objects. |
When deserializing, the array is filled with XmlElement objects that represent all XML elements unknown to the schema. |
| XmlArrayAttribute |
Public field, property, parameter, or return value that returns an array of complex objects. |
The members of the array will be generated as members of an XML array. |
| XmlArrayItemAttribute |
Public field, property, parameter, or return value that returns an array of complex objects. |
The derived types that can be inserted into an array. Usually applied in conjunction with an XmlArrayAttribute. |
| XmlAttributeAttribute |
Public field, property, parameter, or return value. |
The member will be serialized as an XML attribute. |
| XmlChoiceIdentifierAttribute |
Public field, property, parameter, or return value. |
The member can be further disambiguated by using an enumeration. |
| XmlElementAttribute |
Public field, property, parameter, or return value. |
The field or property will be serialized as an XML element. |
| XmlEnumAttribute |
Public field that is an enumeration identifier. |
The element name of an enumeration member. |
| XmlIgnoreAttribute |
Public properties and fields. |
The property or field should be ignored when the containing class is serialized. |
| XmlIncludeAttribute |
Public derived class declarations, and return values of public methods (for Web Services Description Language (WSDL) documents). |
The class should be included when generating schemas (to be recognized when serialized). |
| XmlRootAttribute |
Public class declarations. |
Controls XML serialization of the attribute target as an XML root element. Use the attribute to further specify the namespace and element name. |
| XmlTextAttribute |
Public properties and fields. |
The property or field should be serialized as XML text. |
| XmlTypeAttribute |
Public class declarations. |
The name and namespace of the XML type. |
Today was reading an article abt Http Handlers and Modules. Actually was able to undertsand it much better after doing ISAPI. Http Handlers correspond to ISAPI Extensions i.e. they are target to Http requests whereas ISAPI filters correspond to Http Modules. One thing to be noted was you can have a number of Http Modules at the same time but can just have one handler.
One thing that was good to know was the entire ASP.NET works with this logic only. It has different handlers for handling .aspx, .asmx, .SOAP etc..If you really wanna have a feel for that best would be to open the machine.config and see for your self and you can see these handlers registered over there.
I donno what exactly but want to implement sthg in Web Services or look for a Problem Definition which uses it extensibly. Suggested fields in this area could be
1. Transactions and Coordination
2. Security
3. Writing your own handlers for consuming the web service by the client
Also the business aspect of this field can be attacked..Still reading to narrow down my thinking. Everything is vague and in the air right now:((
Suggestions are welcome
Today tried going through the code of setting up your own server. Found some good articles in Code Project and also Abel helped me with a sample.
It was pretty neat to see your own server running. You don't need to stop the IIS or anything. You can just set up everything on a different port.
I was writing a redirect ISAPI filter. It will help us get rid of the nasty urls which we have. You can just have pretty urls and what this filter does is catches the url before it hits the webserver and gets the url and matches that to a corresponding url in the databases which in turn becomes the url that hits the web server.
Some background abt ISAPI filter. Its is one way to change teh default behaviour of IIS and affect how the HTTP requests are handled. With ISAPI filters, you write code that is executed by teh server. For example, if you don't like the way IIS maps a requested URL to a physical drive location , you can write a filter to change how it's mapped.
Every step of the process of how the server caters to the clients request can be customized. Filters are implemented as Dll's and registered with the IIS and they are loaded once the server starts. The loaded filter tells the IIS which steps in the server request processing it needs to be notified of. It is really interesting to see how it notifies the dll for everything.
Though the entire concept is very interesting and challenging but it is really painful when it comes to code it as the language is really nasty especially after coding in C# with all intellisense. Quoting Abel for this “ Every generation says it for the previous generation that it is baaaaad;-)“.
The problem was the redirect thing should kick off before the request hits the IIS so coding in C# was not a much feasible solution so ended up writing an ISAPI filter in C++ which was a herculian task for me.
Abel had already written a redirect ISAPI filter and I had to figure out the how to do the data access in C++. So few tips abt that..In the stdfx.h file you need to add the following code:
#import
"c:\program files\common files\system\ado\msado15.dll" rename("EOF","ADOEOF") no_namespace
This line basically says, use ADO, but no name spaces and change EOF to adoEOF to prevent some nasty conflicts.This is basically a COM interface which enables data access.
Things would be more clear once you see the code ..
In short it uses teh ConnectionPtr, CommandPtr and the RecordsetPtr which corresponds to connection, command and recordset for ADO access. The logic seems to be pretty simple the harder end was to make the logic working.
The main problem was testing the code while building it cause the filter was a dll.. so everytime you need to put the dll and restart your IIS. This is achieved by typing iisreset at the command line. Also the project used MFC. Datatypes were all screwed up and couple of times Hai had to sit and help me with my code.
The best way is to write console applications and test each part of code and then fit it in the real code.things become realatively easy but then logics which work there at times didn't work here:-( But still it helps quite a lot. Even some conditional statements took me hours.
I have some really good articles collected on this during the entire project. But don't have the links. I have the hard copies so you can reach me if youw ant some more details on that.
Can't see where to upload the zip file. Let me figure it out and then would do that.
This zip contains the entire project of the dll which is a C++ ISAPI dll project using MFC. You need to attach teh database to the SQL
and put teh dll at this location.
Control Panel->Administrative Tools->Internet Information Services->Websites->Default web Site and then right click and go to properties and then click the ISAPI tab over tehre and add the dll.
Interested ppl can pick up the presentations and the sample code from Becky's Blog.
The url is http://blogs.gotdotnet.com/rdias/
Might just be helpful for some:-)
Posting my first message in my Blog World!!!!