As I'm working out SOAP + Langauge du jour problems I continue to be impressed with the utility embedded in the JVM.
Rarely do you get to develop software in a completely greenfield project. Most of us have to integrate our software with other systems and that often means dealing with SOAP. I asked about what people are doing with Groovy + SOAP over at Google+ and had a few side conversations with folks.
It turns out that when forced to deal with the abject insanity that is SOAP, most Groovy users drop back and pick up those Java tools like JAX-WS. It's tools like these that keep developers coming back to the JVM and that Java to Groovy integration story is still one of the best stories going for Groovy.
In part, you have to wonder if ... in order to understand SOAP's madness you don't need a little madness to get the job done. This insanity might have to continue to exist in practical long-lived projects for quite some time. Keeping that madness bottled up in some pre-baked libraries is honestly the best thing you can do for your own continued sanity and the sanity of your own projects.
Showing posts with label soap. Show all posts
Showing posts with label soap. Show all posts
2013-01-10
2008-07-07
API is API, but so is table structure...
It's sometimes hard for developers to remember that table structure is also an API. Yes, it should be considered an internal API for the application you are developing, but it is still part of a system that must be carefully constructed to reflect the reality in which it operates. It is not enough to just normalize data following the rules of database normalization... not anymore anyway... it is important to consider how you will mash-up and add onto a database schema.
Consider RESTful webservices as a unique opportunity to add data into an enterprise system. You have a URI for a resource exposed by a restful API. That URI can then be bookmarked and annotated in a system like del.icio.us for your internal users.
That kind of annotation is powerful. It means you can add tags, wiki, and annotated information to CRM pages, BOM, or other data independent of the underlying system implementation. And, not surprizingly, Grails is well situated for this. Grails projects with Content Negotation can be viewed as amazing polymorphic services that display web pages to browsers, XML to services, and JSON to ajax clients.
That flexibility means you can "bookmark" ala social bookmarking in multiple contexts ... these bookmarks can carry meta data about a linked URI. That meta-data can be anything from contact notes to wiki entries. That could mean a new era of business applications that provide semantic inter-sections of web URI based on simple RESTful principles.
Imagine a BOM bookmarked and annotated in a del.icio.us type interface by different departments. A kitting department links the BOM to a history list that represents activities of kitting. Billing annotates accounting activity by bookmarking and logging the original BOM. The accounting system could be .NET, the kitting in PHP... it wouldn't matter. And you wouldn't need SOAP or known WSDL. The core system would be simpler and concerned with just web-page functions... and (using Grails) a scant few lines for context sensitivity to what the controller renders (XML, HTML, Ajax, JSON, etc.) ...meaning you can develop supporting systems each orthogonal to the data source system.
Think of it as meta-Aspect Oriented Programming if that makes you feel better about it. But, really, it's all about using REST and the web for what they are good at and leveraging the power of the browser as a broker platform. I've heard it called Browser As A Broker (BAAB) and also Enterprise Service Browser (ESB). I think I'll call it... simple and to the point.
Consider RESTful webservices as a unique opportunity to add data into an enterprise system. You have a URI for a resource exposed by a restful API. That URI can then be bookmarked and annotated in a system like del.icio.us for your internal users.
That kind of annotation is powerful. It means you can add tags, wiki, and annotated information to CRM pages, BOM, or other data independent of the underlying system implementation. And, not surprizingly, Grails is well situated for this. Grails projects with Content Negotation can be viewed as amazing polymorphic services that display web pages to browsers, XML to services, and JSON to ajax clients.
That flexibility means you can "bookmark" ala social bookmarking in multiple contexts ... these bookmarks can carry meta data about a linked URI. That meta-data can be anything from contact notes to wiki entries. That could mean a new era of business applications that provide semantic inter-sections of web URI based on simple RESTful principles.
Imagine a BOM bookmarked and annotated in a del.icio.us type interface by different departments. A kitting department links the BOM to a history list that represents activities of kitting. Billing annotates accounting activity by bookmarking and logging the original BOM. The accounting system could be .NET, the kitting in PHP... it wouldn't matter. And you wouldn't need SOAP or known WSDL. The core system would be simpler and concerned with just web-page functions... and (using Grails) a scant few lines for context sensitivity to what the controller renders (XML, HTML, Ajax, JSON, etc.) ...meaning you can develop supporting systems each orthogonal to the data source system.
Think of it as meta-Aspect Oriented Programming if that makes you feel better about it. But, really, it's all about using REST and the web for what they are good at and leveraging the power of the browser as a broker platform. I've heard it called Browser As A Broker (BAAB) and also Enterprise Service Browser (ESB). I think I'll call it... simple and to the point.
2007-11-15
The Fallacies of Distributed Computing
I'm working a SOAP heavy project right now so I thought I'd look up the 8 Fallacies of Distributed Computing. These are 8 assumptions people often make in designing network based systems such as a SOA or ESB that simply aren't true.
The following is NOT true:
1. The network is reliable.
2. Latency is zero.
3. Bandwidth is infinite.
4. The network is secure.
5. Topology doesn't change.
6. There is one administrator.
7. Transport cost is zero.
8. The network is homogeneous.
Designs should allow for the network to drop in and out, run slowly, take a while to move data around, change with out notice, or deal with multiple operating systems, langauges, or data representations. How often to we just think about the 'best case' scenario and fail to build in allowances for problems?
The following is NOT true:
1. The network is reliable.
2. Latency is zero.
3. Bandwidth is infinite.
4. The network is secure.
5. Topology doesn't change.
6. There is one administrator.
7. Transport cost is zero.
8. The network is homogeneous.
Designs should allow for the network to drop in and out, run slowly, take a while to move data around, change with out notice, or deal with multiple operating systems, langauges, or data representations. How often to we just think about the 'best case' scenario and fail to build in allowances for problems?
2007-11-07
Grails XFire Plugin
Had a little trouble with the XFire Plugin for Grails. I found this thread of posts on
nabble which clears things up. I attached the thread to the appropriate bug. Other than that I noticed that java.util.Date Is turned into a string. To fix this I created DTO (Data Transport Object) with XMLGregorianCalendar instead. This works find for DTO but could cause a minor headache if I have to expose domain classes directly through a SOAP service. Other than that the XFire plugin handles everything I need it to so far.
XFire is apparently on the verge of getting replaced with CXF which is an Apache incubator project. I was able to work through an CXF service myself using the JSR-181 annotations (that's the Java Web Services meta data specification). Configuring CXF inside a Spring container was the usual Spring XML-er-ific mess that you run into when doing Spring work without a tool kit.
Integrating the CXF Spring config with Grails worked up until I hit a class incompatability between Groovy 1.1 and CXF somewhere down in the XML parsers. I caught just enough to see that it was a class version problem around the DATETIME type where Groovy had one version and CXF had another. That was enough for me to decide to stick with the XFire plugin. I don't want to be in the business of building my own versions of anything that I didn't write.
I figure if the XFire plugin is that simple to set up then it will probably be just that simple to "port" my services to CXF later. Grails does a pretty good job of letting you switch between DWR, Prototype, and YUI when you are working in Ajax... so why not have multiple SOAP plugins that swap out just as easily?
nabble which clears things up. I attached the thread to the appropriate bug. Other than that I noticed that java.util.Date Is turned into a string. To fix this I created DTO (Data Transport Object) with XMLGregorianCalendar instead. This works find for DTO but could cause a minor headache if I have to expose domain classes directly through a SOAP service. Other than that the XFire plugin handles everything I need it to so far.
XFire is apparently on the verge of getting replaced with CXF which is an Apache incubator project. I was able to work through an CXF service myself using the JSR-181 annotations (that's the Java Web Services meta data specification). Configuring CXF inside a Spring container was the usual Spring XML-er-ific mess that you run into when doing Spring work without a tool kit.
Integrating the CXF Spring config with Grails worked up until I hit a class incompatability between Groovy 1.1 and CXF somewhere down in the XML parsers. I caught just enough to see that it was a class version problem around the DATETIME type where Groovy had one version and CXF had another. That was enough for me to decide to stick with the XFire plugin. I don't want to be in the business of building my own versions of anything that I didn't write.
I figure if the XFire plugin is that simple to set up then it will probably be just that simple to "port" my services to CXF later. Grails does a pretty good job of letting you switch between DWR, Prototype, and YUI when you are working in Ajax... so why not have multiple SOAP plugins that swap out just as easily?
2007-07-22
NFJS 2007: RESTful Loosely Typed SOAP services
I just got back from No Fluff, Just Stuff 2007 (NFJS) and I went there with my document centric design ideas and came back after words with an idea that is far more powerful. RESTful Loosely Typed SOAP services.
Okay, I'll admit it... it would be hard to pull off a truly RESTful SOAP service but we nearly have all the components. It is much easier to pull off a Loosely Typed SOAP service and that is where the real power is.
There is quite a bit of support for a Loosely Typed SOAP service. Simply put SOAP services use XML documents and not structured data types defined in their WSDL. The cost is using strategy patterns to tear apart your documents. Since you can get any number of document versions you need any number of strategies to unmarshal them.
The benefit is that the marshaling and unmarshaling of data is done by strategy patterns that can be swapped out. One service end point can service multiple document process versions. Viola instant upgrade path that is also backward compatable.
The RESTful-ness is achieved by providing a set of "fetch" documents that would fetch things in an easy to understand way... the fetches would be polymorphic too. This is not quite RESTful since the restful ideal would be to be able to specify unique URI to get each item... but it is closer to the ideal than strongly typed SOAP.
I need to play with this more and write some examples.
Okay, I'll admit it... it would be hard to pull off a truly RESTful SOAP service but we nearly have all the components. It is much easier to pull off a Loosely Typed SOAP service and that is where the real power is.
There is quite a bit of support for a Loosely Typed SOAP service. Simply put SOAP services use XML documents and not structured data types defined in their WSDL. The cost is using strategy patterns to tear apart your documents. Since you can get any number of document versions you need any number of strategies to unmarshal them.
The benefit is that the marshaling and unmarshaling of data is done by strategy patterns that can be swapped out. One service end point can service multiple document process versions. Viola instant upgrade path that is also backward compatable.
The RESTful-ness is achieved by providing a set of "fetch" documents that would fetch things in an easy to understand way... the fetches would be polymorphic too. This is not quite RESTful since the restful ideal would be to be able to specify unique URI to get each item... but it is closer to the ideal than strongly typed SOAP.
I need to play with this more and write some examples.
2007-07-03
JAAS + Liferay + Woe
The problem:
I've written several EJB3 soap services that need to be secured by the PortalRealm security domain. When someone is logged into the portlet they can use the soap services... not logged in? no soap for you.
The woe:
No ClassLoaders found for: com.liferay.portal.security.jaas.PortalLoginModule
Which seems innocuous enough until you realize what would be entailed in fixing the class loader problem. I would need to either make my project a direct extension of Liferay or I would need to alter Liferay to extend a custom security module.
Neither solution is good. It would be better if Liferay used a common container managed security system. Perhaps my solution is to somehow combine the realms.
I've written several EJB3 soap services that need to be secured by the PortalRealm security domain. When someone is logged into the portlet they can use the soap services... not logged in? no soap for you.
The woe:
No ClassLoaders found for: com.liferay.portal.security.jaas.PortalLoginModule
Which seems innocuous enough until you realize what would be entailed in fixing the class loader problem. I would need to either make my project a direct extension of Liferay or I would need to alter Liferay to extend a custom security module.
Neither solution is good. It would be better if Liferay used a common container managed security system. Perhaps my solution is to somehow combine the realms.
2007-06-29
return;
Personally I think that leaving a return statement at the end of a method whether you need one or not lets everyone know you really did mean to end the method there.
In other words, "Yes kids, I did mean to return there, no I didn't nod off and forget to finish the method."
/**
* assign an interview to a person
*
* @param personId
* @param interviewName
*/
@Oneway
@WebMethod(operationName="assign")
public void assign(
@WebParam(name = "personId") String personId,
@WebParam(name = "interviewName") String interviewName
){
InterviewEngine.assign(em, personId, interviewName);
return;
}
In other words, "Yes kids, I did mean to return there, no I didn't nod off and forget to finish the method."
2007-05-29
A year with Java 5 EE
I've spent the last year with Java 5 Enterprise Edition betas and I'm going to talk about my experiences with the Java environment as a relative newcomer to the Java landscape. My background is in C/C++ System V programming on Linux, Solaris, and Irix systems. It has been a hard year but one that I'm thankful for. I've learned a lot about how Service Oriented Architectures go together, why they work, and why they fail.
Subscribe to:
Posts (Atom)