SOA for Developers

Service Oriented Architecture is a structure that requires a number of specialized employees working in positions such as Object Librarian, Configuration Management, and Information Architect. Junior developers or individuals who prefer dealing with web development, focus exclusively on the presentation tier. Such individuals are very productive, as the vast majority of the business services and rules will be available to be assembled into the UI’s. Individuals who enjoy writing code can dwell in the business rules tier, where important services and components may be developed.

More experienced developers will be able to construct enterprise wide services and components, such as authentication, encryption, and error handling. Other individuals working in development are required to focus on specific application services and components, like printing invoices, the creation of orders, and a whole lot more.

Java SOA Development

The next generation of development standards is going to focus on two main areas:

1. Providing of a common model for control of relationships among services;
2. Allowing developers to implement robust web services utilizing familiar Java objects.

JAX WS is a standard that is defined in Java community process that is descriptive of how Java developers may go about creating Web services. Like a lot of newer Java EE specifications, JAX WS eliminates much of the complexity that is associated with the development of web services. For instance, JAX WS provides a very simple model for the implementation of business logic, while exploding the contract as a WSDL interface via the use of annotations on the code of implementation. Through the leveraging of JAX WS, developers are then able to build portable services by utilizing skills that can be applied widely across many different products.

Java ME SOA Development

A lot of mobile applications currently necessitate the utilization of one or more applications on the server side. Such applications are not able to function – at least not fully – unless they are helped by one or several external applications. Such mobile applications hence transform into distributed applications. Java ME developers construct distributed applications quite often utilizing custom protocols that are tunneled via HTTP.

Whenever end-to-end Java is possible – meaning the endpoints of the communication path are both Java applications – then it is quite common for the applications to exchange information in the form of custom serialized Java objects. A major problem with distributed architectures is the tight coupling among the various segments of the distributed application. The utilization of custom object serialization for the purpose of data transfers is a common sufferer of this problem. While it may seem easy and convenient, programmers often fail to keep in mind that connections tend to be restricted to the particular servers that have an understanding of the protocol.

Any changes that have to be made to that protocol necessitate server reconfiguration. When code is written for extremely constrained programming environments, quite often there is little choice for the creation of such a tight coupling of server and client. As constraints to processor and memory are removed, however, the switch to a more flexible model of SOA becomes a possibility. SOA can be thought of as a style of distributed computing that allows for a loose coupling among various components belonging to an application.

In SOA model, services are provided that are independent of platforms. It is exchanged through the use of both extensible and portable formats. There are numerous ways to manage various services. Applications utilizing the services offered under a SOA are not dependent on the means that those services are implemented by.

This is comparable to the process whereby Java interfaces are utilized within an application as a means of decoupling abstractions from their implementation. Such loose coupling both allows and even encourages the utilization of services from a variety of providers.

This offers application developers a lot more flexibility in the construction of applications through combining services in novel ways. Already a marketplace has developed among service providers, with companies such as Amazon.com offering pay-as-you-go services for the storage of data. Web services tend to be employed as the foundation for Service Oriented Architecture.

They take advantage of the almost universal support available these days for HTTP as a means of creating services that are accessible on nearly any device that is connected to the Internet, whether that device be wireless or wired. Usually REST, SOAP, or some other abstraction layer on top of HTTP is utilized as a means of invoking services and the exchange of data among clients and servers.

In SOA, Java ME is especially well suited for client application development. This is because device constraints tend to be very limiting when compared with desktop situations. Thus, it is a lot harder to offload pricey operations to external systems. This is why a need arises to communicate with such systems through web services.

As it often happens, HTTP support can be visible on nearly any Java ME environment. The device’s Connected Limited Device Configuration includes it as part of the Mobile Information Device Profile as well as the Information Module Profile. The Connected Device Configuration also includes it as one of the main configuration features. HTTP support, however, is only the first step.

Usually, an XML parser will be required as a means of parsing data that has been returned by web service invocations. As opposed to HTTP, Java ME support for XML is not totally universal. Parsers are available, however, for inclusion on all Java ME environments, either through open source projects such as kXML or through the optional package J2ME Web Services Specification.

Services that are REST based are loosely defined. They require custom coding as a means of marshalling data, invoking services, and un-marshalling responses. SOAP based services, on the other hand, tend to have much more complicated semantics. SOAP based services will require support beyond XML parsing and HTTP communication.